future CPUs [LWN.net]

future CPUs

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

Death of x86 predicted, film at 11. :)

Sorry, not holding my breath. Until we've got software that can benefit
from even 8 cores, who cares? SMP scalability was a huge advantage of
Sparc and Solaris, and they've just taken the market by storm, haven't
they?

As far as I can tell, Intel is going to SMP on a chip because they can't
figure out a better use for the enormous transitor budgets each die shrink
gives 'em (they've already got megabytes of on-chip L2 cache), not because
there's a huge demand to throw yet more mips at general desktop tasks
(word processing, email, web browsing, quicken, turbotax, the occasional
spreadsheet containing a grocery list...).

How is your average laptop going to keep these cores busy? Go back to
software rendering for 3D acceleration? (The ubiquity of existing 3D
coprocessors aside, isn't that about as much a question of memory bus
bandwidth as processor performance, so putting the graphics processor
physically close to the graphics frame buffer actually makes sense
architecturally? And this helps battery life how?)

(Log in to post comments)

future CPUs

Posted Aug 24, 2007 6:05 UTC (Fri) by Cato (subscriber, #7643) [Link]

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.

Linux is not as bad but there's still some overhead, e.g. Beagle type file indexing, etc. 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.

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

future CPUs

Posted Aug 24, 2007 7:41 UTC (Fri) by Los__D (subscriber, #15263) [Link]

Most of these background tasks are more I/O intensive than CPU intensive, as far as I can tell...

If I'm right, then more cores wont really help much in this regard

future CPUs

Posted Aug 24, 2007 21:04 UTC (Fri) by landley (subscriber, #6789) [Link]

> 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.

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.

future CPUs

Posted Aug 25, 2007 17:45 UTC (Sat) by oak (subscriber, #2786) [Link]

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

Why? For most tasks one of the system cores on a newish machine should be
fast enough. I don't want DummyApp to keep my whole machine sluggish, it's
better that it runs only on a single core. This saves battery &
electricity (& the world) as the other cores can sleep.

I'd rather programmers spend their time learning to profile and optimize
their code properly than how to create multi-threaded messes. Learning
properly meaning "choose your algorithms / data structures with
care", "premature optimization is root of all evil" etc...

future CPUs

Posted Sep 7, 2007 11:50 UTC (Fri) by Cato (subscriber, #7643) [Link]

Multi-threading is needed because CPUs won't stop at 2 cores - expect 8, 16 and 32 core CPUs (Sun is getting there already with Niagara). Admittedly many tasks won't need multiple cores, but video is an increasingly important datatype that can really use this sort of power. And of course there will be apps invented in next 20 years that we can't imagine (who anticipated Youtube 20 years ago?), perhaps using grid technology with complex local rendering to provide medical advice.