The Quest for More Processing Power, Part One: "Is the single core CPU doomed?"
by Johan De Gelas on February 8, 2005 4:00 PM EST- Posted in
- CPUs
Conclusion
Prescott was built to adapt to the typical problems that made it hard to run x86 programs quickly: branches, dependencies, lots of memory and ADD operations. However, in order to do so, complex logic was used, which increased leakage power quickly. The wire delay problem and dependency problem were only solved by sacrificing a lot of energy. The combination of LVS double-pumped ALUs, tons of new features and 64 bit together created an avalanche of leaking logic. The result is an innovative architecture crushed into a thermal wall.
But the Prescott failure, the exploding leakage power and wire delay don't mean automatically that the single core CPUs have no future. Power leakage can be contained by introducing high-K materials and SOI. Wire delay has been solved by using repeaters - at the cost of some extra power - and Cu interconnects. Dual core is not a magical solution that is going to solve all the problems that Prescott and other modern CPU face.
The Prescott failure only tells us that right now, the ultra deep pipelined CPU is not the best solution. Intel went too quickly, too deep, and although many ingenious tricks were implemented to make the Prescott a real powerhouse, all those tricks together backfired with high leakage and dynamic power loss.
In the next article, we investigate what dual core technology can really bring us, besides a lot of hype, "paradigm shift" slogans everywhere and "much smoother system" claims.
References
[1] An In-Depth Look at Computer Performance Growth
CHALMERS UNIVERSITY OF TECHNOLOGY, Department of Computer Engineering, Göteborg 2004
http://www.ce.chalmers.se/~warg/papers/performancegrowth_tr-2004-9.pdf
[2] Intel Whitefield uncovered, The Register
http://www.theregister.co.uk/2004/05/01/intel_whitefield_uncovered/
[3] Implementing Power Management IP forDynamic and Static Power Reduction in Configurable Microprocessors using the Galaxy Design Platform at 130nm
Dan Hillman, Virtual Silicon
John Wei, Tensilica
http://www.tensilica.com/hillman_slides.pdf
[4] Leakage Power Modelling and Leakage Power Modelling and Minimization
Massoud Pedram
University of Southern California , Dept. of EE-Systems
http://atrak.usc.edu/~massoud/Papers/pedram-tutorial-iccad04.pdf
[5] Gigascale Integration-Challenges and Opportunities
By Shekhar Borkar
Intel Fellow, Director, Circuit Research
http://www.intel.com/research/mrl/research/circuit.htm
http://www.intel.com/cd/ids/developer/asmo-na/eng/strategy/182440.htm?page=1
[6] SUN Niagra Demo
http://www.sun.com/aboutsun/media/presskits/networkcomputing05q1/
[7] LVS Technology for the Intel® Pentium® 4 Processor on 90nm Technology
http://www.intel.com/technology/itj/2004/volume08issue01/art04_lvs_technology/p01_abstract.htm
Other Sources:
- Intel Silicon Innovation To Shape Direction Of The Digital World
Multi-Core Processors, FALL IDF 2004
http://www.intel.com/pressroom/archive/releases/20040907corp.htm - Pentium 4 processor at 4.7 GHz, FALL IDF 2002
http://www.intel.com/pressroom/archive/releases/20020909corp.htm - Intel Developer Forum, Spring 2002
Louis Burns Keynote, Netburst architecture scales up to 10 GHz.
http://www.intel.com/pressroom/archive/speeches/burns20020227.htm - The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software
By Herb Sutter
http://www.gotw.ca/publications/concurrency-ddj.htm - Illinois researchers create world's fastest transistor ... again
http://www.news.uiuc.edu/scitips/03/1106feng.html
Facebook
Twitter
RSS
65 Comments
View All Comments
WhoBeDaPlaya - Thursday, February 10, 2005 - link
Ain't no way you can get those repeaters out of there - that's already the optimum solution for driving the large load (interconnect). It probably equalizes the stage effort required (you can work out the math and find that for multi-stage logic, the optimal config is that each stage has the exact same effort level). Eg. instead of driving an interconnect with a "unit" inverter, it might be more feasible to drive it with a chain of them, each with different fan in/out. Repeater insertion is tricky and (as far as I know) can't readily be automated.Interconnects are getting to tbe point where traversal of a die diagonally can take multiple clock cycles. Some folks are suggesting that a pipelined approach could be extended to interconnects, esp. clock trees. But the most fun problem (for me at least :P) is the handling of inductance extraction - how in the h*ll do you model it accurately? High-speed digital design == Analog design. Long live analog / mixed-signal VLSI designers :P
fitten - Thursday, February 10, 2005 - link
[quote]Well-written multicore-aware code should have the number of cores as a _variable_, so you just set it to 1 on a uniprocessor platform.[/quote]Sometimes parallel algorithms aren't very good for serial execution. In these cases, you may actually have one algorithm for multiple processors and another algorithm for a single processor.
[quote]So, if Intel were to use less repeaters the heat output could be lowered significantly. [/quote]
Well... I'm sure the Intel engineers didn't just up-and-say one day, "Hey, I know something cool to do... let's put some more repeaters into the core." I'm sure there's a reason for them being in there. It would probably take a bit of redesign to get the repeaters out. (I'm pretty sure this is what you meant, but I just wanted to clarify that stuff like repeaters aren't just put into a CPU for no reason. Things like repeaters are put in because there wasn't a more viable solution to some signalling problem that's there.)
sphinx - Thursday, February 10, 2005 - link
So, the reason for the Prescott's shortcomings is the use of too many repeaters as shown in the image of the Itanium 2. If I remember correctly, the article said that the repeaters were using too much power as well. So, if Intel were to use less repeaters the heat output could be lowered significantly.AtaStrumf - Thursday, February 10, 2005 - link
Nice article and pretty easy to understand as well. I'm happy to hear that there may still be hope for controlling the power leakage, because without it I just can't see anybody getting beyond 65 nm, since even 65 nm will, without improvements, leak almost 3 times as much power as 90nm does now.Anxiously waiting for E0 A64 to see what AMD has managed to cook up.
mickyb - Wednesday, February 9, 2005 - link
There are plenty of multi-threaded apps out there. I am not sure pure single threaded apps exist any more outside of "Hello World" and some old Cobol/FORTRAN ports that are on floppy.Quake and UT have been multi-threaded for a while. Quake was multi-threaded when I had a dual Pentium pro. There were even benchmarks. The benefits seen with hyper-threading also show that many apps are multi-threaded. The performance gain was negligible due to the graphics drivers and OpenGL/DirectX not being thread optimized. I am sure that has been worked out by now.
Multi-threading is not all about making use of multiple CPUs. There are many conditions where a program would be stopped dead in its tracks waiting for a response from some outside program or hardware device. You can solve this with events, multi-process, multi-threading, call-backs, etc. Goal wise, they are related. In the Winders world, threading is the method of choice.
I really can't believe there are still arguments going on about programs not being multi-threaded. This is not that much of an issue any more. Even if your apps is not threaded, the OS is and it can run on one CPU while your app runs on the other. Or if you have 2 apps, then they can run on different CPUs.
With all that said, I agree with the thought that creating performance for all applications is better served using a faster single core CPU than dual CPUs. I think this way because when you have a unit of work to be done (even with multiple threads), it is more likely to be done quicker with a single CPU that is capable of the same computing power as 2 CPUs. I single unit of work will ultimately be smaller than a thread in all cases. The smallest is the instruction set.
Now...with that said, if the limiting factor is technology and they cannot obtain the equivalent performance of a dual core with a single core, then it makes since to go dual core to obtain it, especially with the power leakage. I like the thinking behind dual core on a laptop, but am skeptical about the part that says turning the CPU off and on rapidly to keep it cool and efficient. It will probably work if it isn't turned on and off too quickly, but heat spreads pretty quickly. You wouldn't even get past POST without a heat-sink and that silicon insulator keeps everything pretty cozy.
NegativeEntropy - Wednesday, February 9, 2005 - link
Johan, another excellent article, I'm looking forward to part 2.Evan Lieb - Wednesday, February 9, 2005 - link
It's pretty much impossible to get a "newbie" explanation of CPU architectures without a least a basic understanding of how CPUs work. Rand's suggestions were quite good, you should start there if you're overwhelmed by Johan's explanations IceWindius. It also wouldn't hurt to start with Anand's CPU articles from last year.Rand - Wednesday, February 9, 2005 - link
"I wish someone like Arstechinca would make something really built ground up like CPU's for morons so I could start understanding this stuff better."You may want to read parts 1-5 of "The Secrets of High Performance CPUs"
http://www.aceshardware.com/list.jsp?id=4
A bit outdayed now, as it was written in 99' if I recall correctly but it's still broadly relevant and a nice series of articles if your looking to get a better understanding of microprocessors without being drowned in the technical side of things.
ArsTechnica also has some good articles with a newbie friendly slant.
There are some excellent articles at RealWorldTech as well, but their definitely written for engineers rather then the average person.
Unfortunately most of the more noteable books like those by Hennessy & Patterson assume you've already some knowledge of computer architectures.
stephenbrooks - Wednesday, February 9, 2005 - link
#46, Well-written multicore-aware code should have the number of cores as a _variable_, so you just set it to 1 on a uniprocessor platform. I also think there already exists a multithreaded version of one of the big engines (Quake, UT?) that apparently does not lose any performance on a single core either.But I agree with the main thrust of your post, which is "Buy AMD".
Noli - Wednesday, February 9, 2005 - link
Not to belittle dual core development and I know there are a lot of people who run technical programs that will benefit from dual core on this site, but when I spend a small fortune on a pc, the primary driver is being able to play the most advanced games in the world. Unfortunately, I don't feel multi-threaded game code is going to get written for a longggggg time (what's the point of reducing potential customers?). How long till a very large percentage of users have dual cores? End of 2006 at the very earliest? So it's really a just a theoretical interest till then for me...