May 8, 2005
Both AMD and Intel now have dual core CPUs on the market, in the form of the Athlon 64 X2 and the Pentium 4 D series. They may be expensive now, but I fully expect dual core architectures to trickle down to the rest of the lineup within the next two years.
I've mentioned before that I'm a big fan of the Athlon 64 series because it compiles code so much faster* than the equivalent Pentium 4. This advantage naturally extends to the dual core Athlon 64 X2 as you can see in these multitasking compilation benchmarks:
The Athlon 64 benefits more than the Pentium 4 from the dual core design because it has a superior architecture-- specifically, an on-die memory controller-- and because it had no special threading support prior to the dual core update. Intel primed the market for better threading support with Hyperthreading, and we're now poised to reap the benefits with the true dual core designs.
Dual core designs are fantastic from a technology standpoint, but as a software developer, it's a scary trend. If the only way we can increase speed is through extra parallelism (aka threading), our coding and debugging burden just went through the roof. See Threading, Concurrency, and the most powerful psychokinetic explosive in the Universe for my take on that. The challenge of increasing speed starts to shift from the hardware to the software:
But how will users benefit from multiple cores? Will the apps run faster just because there a now 2 processors on a single chip? I guess not really. There are benefits for the OS that may relate to improved performance. But the app itself? Well, you can run multiple instances easier and better for one. But what about a single app? A single threaded (client) app that has been designed with a single processor and a single thread of execution in mind, will not benefit and therefore users will not benefit from multiple processors or multiple cores.
And it gets worse. Check out this interview with Hector Ruiz, the CEO of AMD:
IW: What lies beyond dual-core for AMD?
HR: It's hard to tell right now beyond four cores. The probability of having a four-core product is very high. There's a lot of work going on with our engineering teams and with our customers to figure out where we go beyond that. There are two or three options that look pretty attractive. We'll be narrowing down our choices.
IW: It is interesting that you did not say that four-core is a certainty. Are you looking at different ways of improving performance other than doubling the number of cores?
HR: At the end of the day, for us, it's going to be what our customers want. Making transistors is pretty trivial. We can make hundreds of millions of transistors. Figuring out what the hell to do with those transistors is the challenge. One could choose, for example, to have heterogeneous cores. You could have two cores that are different instead of the same. That opens up a completely different array of possibilities.
Once two cores become standard, you can expect four cores to follow in short order. One day, you won't be able to throw money at your hardware to make your app run faster. You'll have no choice but to pour that money into parallelizing the algorithms inside your app, which is a far more difficult proposition.
* It's also significantly faster in games, not that I play those.
Posted by Jeff Atwood
Good post... You know, my boss used to say: "I won't give you a faster development machine - just make the application faster, so it will also run faster on older user systems..." I think he has a good point there. Up to now it was very cheap to increase performance of an application - just install newer hardware, but in the end, as we are seeing now, that "trick" won't work any more. So, yes it is up to us, software developers, to increase performance further.
Recently I had to look at the performance of a .Net application, that was too slow - in the end the app was rewritten as Win32 and the performance gain was so enormous, that that effort confirmed voices I have been hearing from developers that are not accepting the .Net platform and still prefer to develop for Win32. Looking at the system requirements MS has set up as "recommended" for Longhorn makes me wonder if that will delay the market from moving from XP to Longhorn when it becomes available...
So, you don't play those darned games, huh? Are you looking forward to Battlefield 2 or something? Lots of folks in my area stomped away from Battlefield 1942...and I still love the game. I played the crap out of it.
Dual core CPUs are going to be awesome. I'm an Athlon fan (for the gaming reason) and will remain one. I don't have an Athlon 64...but will hopefully by the end of the year. :)
but this A64 3400+ is SO much faster
Yeah, it's dramatically faster for compiling. The compiler just loves the on-die memory controller.
"I won't give you a faster development machine - just make the application faster, so it will also run faster on older user systems..."
If you give devs really fast machines, there is the danger of developing apps that only run well on fast machines. Something to watch out for.
Recently I had to look at the performance of a .Net application, that was too slow
Of course there are sometimes valid reasons to write things in unmanaged C++. I don't expect IIS to be managed code any time soon, for example. Still, you can write a slow app using assembly language, too.
but in the end, as we are seeing now, that "trick" won't work any more
Well, it still works-- for now. But in the next few years we will see the point of diminishing returns for pure hardware CPU speed increases. There are still other ways to increase performance with hardware; things like solid state hard drives and hybridized memory/disk drives which are only now becoming viable. For a disk bound application the performance implications of 4gb of main memory, or a 10gb solid state drive, are huge.
What is needed to solve the problem of maximizing
the effective use of multi-core processors is an automatic parallelization and optimization tool
which can rewrite single core processor code in a form suited for a given multi-core processor.
This tool may use artificial intelligence techniques such as neural networks and genetic programming.
Heh - it was a relatively direct consequence of your earlier blog entry that I got an Athlon 64 laptop rather than a Pentium 4 one (it's a development machine). I'd thought a 3GHz P4 was quick, but this A64 3400+ is SO much faster....so, thanks for that :-)
Although I am an Athlon 64 fan, I have to say that I am very happy with my new computer at work. It's a dual processor 3.2 GHz Intel Xeon machine with 2 gigs of Ram.
If it wasn't for the pervasive presence of Dell at a lot of businesses, us AMD users might get some more love.