future CPUs [LWN.net]

future CPUs

Posted Aug 24, 2007 21:04 UTC (Fri) by landley (subscriber, #6789)
In reply to: future CPUs by Cato
Parent article: Linus Torvalds talks future of Linux (apc)

> The average Windows PC needs at least one core for 'admin' - running
> antivirus, content-based firewall, anti-spyware, and general overhead.
> This leaves the other core(s) to do real work.

Someone else pointed out this kind of background task causes problems
when it's I/O intensive rather than CPU, but I'll grant the point. I
have a dual core laptop right now.

The assumption I was challenging is that "scaling beyond 8 cores" is
likely to be remotely important to anybody in our lifetimes. SMP was
available back in 1982 (Anybody remember MP/M, the multiprocessing sequel
to CP/M?). OS/2 3.0 did SMP just fine in 1992. This is not something
new, and predictions of huge demand for it aren't new either. What's
always prevent it from becoming interesting is that programming to take
advantage of it is the difficulty to reward ratio in programming for it.
(I have spent two weeks trying to track down a race condition in
multithreaded OS/2 code interacting with the multithreaded desktop
through a third party library. There's a reason I don't bother with
threads anymore.)

> Linux is not as bad but there's still some overhead, e.g. Beagle type
> file indexing, etc.

Mono is a bad idea, gnome is a bad idea, beagle is mono plus gnome. Not
going there.

But again, "some processes are horribly inefficiently written resource
hogs" doesn't quite translate to "systems will be able to keep more than
8 processors busy real soon now".

> And now that the web is becoming far more video based, and video is
> moving to HDTV ultimately as bandwidth improves (e.g. serving video
> within the home), even Joe Average will have far more reason to tie up
> multiple cores.

Video exercises the 3D accelerator, not the processor.

> The real answer is that programmers will need to learn how to write
> threaded code even for tasks that are most obviously done sequentially.

Woah, Deja Vu. (That statement sounds exactly like Team OS/2, circa
1992...)

Programmers don't "need" to do anything. Sturgeon's law applies to the
thundering horde of ex-MCSE types out there, and the bottom 98% will not
be able to debug a multi-threaded race condition in my lifetime. They're
writing visual basic, cut-and-pasting javascript, and they think C++ is
better than C due to the ability to declare things private from their
co-workers.

Sure, the solution isn't to make hardware that does things people want it
to do, the solution is to force all the people to change to take
advantage of the hardware.

I'm not holding my breath.

(Log in to post comments)

future CPUs

Posted Aug 30, 2007 10:38 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

No, MP/M wasn't a multiprocessor operating system, it was only a multiprocessing operating system. Today all operating systems are multiprocessing and we take it for granted, it just means that they appear (through time-slicing) to run more than one process aka program at a time. MP/M's ancestor, CP/M was able to run just one program at a time. You could run the text editor, then save your changes and exit, and run the compiler, then the linker, then test the resulting program, see if you'd fixed the bug you were working on, and restart the text editor to continue programming. Digital Research added multiprocessing to create MP/M which they hoped would sell as a multi-user system, two or more people connected to terminals, effectively time-sharing a single CPU with MP/M. Instead people bought it so that at last they could run more than one program at once, a huge time saving.

OS/2 was eventually available in an (expensive) SMP capable version, but only in the mid-1990s, when Windows NT was already SMP, and work to make Linux SMP capable had begun. The first successful SMP version of OS/2 (Warp Advanced Server) wasn't released until 1996, by which time there were many more NT and Linux systems on multi-processor machines.

As to your main thesis, that it's irrelevant how to scale to large numbers of CPU cores, well, the trouble is that Moore's law isn't running out of steam, but it no longer delivers faster CPU cores, just more transistors to make them out of. The obvious way forward is to add more cores and parallelize the software. I acknowledge that this is very hard, but it's no use just saying "that's hard, I won't do it".

future CPUs

Posted Aug 30, 2007 23:46 UTC (Thu) by Nelson (subscriber, #21712) [Link]

What's so bad about Mono?

While it might not be Java or .Net/Mono, technologies like those are exactly how we exploit more parallelism. It's fairly easy to write thread safe code in both. Writing good parallel algorithms is a different matter, but for a lot of common applications there are real advantages just parallelizing certain tasks, just UI response is often a win, for example. (Being an OS/2er I guess you might not have minded the single input queue, you ever search in the help tool and see the whole UI freeze until it was done?) Sure, java and mono are not as fast as assembly... It's been clear as day for decades that parallelism is going to be the future, whether or not you ever want to admit it, it's the only possible way to continue to improve performance at the same rates.