Is multi-threading a dead end?
Parallel problems plague programmers.
One curious feature in Intel's new Santa Rosa platform is the Dynamic Acceleration of single cores in the mobile CPUs. That is, if you have two cores in a CPU, and one of them gets busy, it automatically "overclocks" for a performance boost.
Likewise, if the other core is just lazing around doing nothing, it can be put into a low-power sleep state. Graham Tucker at Intel Australia says the transitions are very fast, and measured in micro-seconds after a certain utilisation threshold has been reached - BIOS support is required of course.
I've been thinking about this feature, which will make it into desktop and server processors as well soon. First, it'd be interesting to test it and trigger it via software somehow. Maybe it's possible to turbo up both cores in the processor at the same time even?
The other question that occurred to me was... "why is Intel doing this?" Intel has always been big on parallelism and multi-processing, but just because you can implement that in hardware doesn't mean things will go faster.
Writing multi-threaded applications is notoriously difficult, and I suspect that the dynamic acceleration of cores is something of a fix for that. Speeding up single-threaded apps probably gives a more readily apparent improvement in user experience than Intel would like to admit.
More on this once I get to the bottom of the issue.
PC World is New Zealand’s top selling computing and technology magazine.
Comments
Having cores doing specific tasks would be Asymmetric Multiprocessing in a sense, but it's possible that a modern implementation that is more free than for instance DEC's VMS stuff would work better.
Haskell homepage for those who are interested. It's easy to understand and learn, but the trouble is, you'll never want to touch languages like C/C++ after :)
Posted by: Juha | May 30, 2007 6:37 PM
It's not impossibly difficult to write parallel code. It's apparently extremely easy to write parallel code which will run much more slowly than single threaded code. :)
Some scientific problems respond well to parallel code. But it seems that effective code isn't all that simple to create. Massively parallel computers are still being built to be used on such problems. But they aren't mass produced.
Two, four, eight cored processors are not going to do 2, 4, 8 times the work of a single processor. Ever. Sharing the work evenly could take up more processor time than the prospective gains.
One possible simple minded parallelism which wouldn't be too difficult to implement, and would have quite good speed gains is to have one core dedicated to running the OS; the other to run applications. With some OSs, the OS CPU might be the most heavily loaded, and "slow" but at least "work" could be run a bit quicker. :D Perhaps this is what Intel is looking to.
Posted by: Graham Lees | May 30, 2007 4:55 PM
I understand that writing programs in functional languages, like Haskell, could significantly speed up the transition to multi-threaded programs. Functional languages allow programmers to tell the computer what they want to calculate, rather than specifying in excessive detail how to calculate it. This allows the multi-threading problem to be solved once only (in the compiler), rather than forcing every programmer to master new techniques. (Of course, functional programming itself will be a new technique for many programmers, but then again, millions of future programmers haven't learnt any language at all, yet.)
Tim
()(
Posted by: tjm1983 | May 30, 2007 4:50 PM