Danny and I were invited to a session given by Intel in San Francisco during the Intel Developers Forum happening this week at the Moscone Center. While I cannot currently comment on the exact nature of that session as some of it was under NDA, I did make a couple of observations that were interesting. I'm sure the roadmap stuff is off-limits here, but some other things are probably OK (he said while glancing over his shoulder)... however if asked, I'll deny ever saying this ;-)...
The talks were rather dry, but I've come to expect that from Intel. Multi-core was the hot button topic. They kept re-iterating that Moore's Law was still a long way from finally hitting the wall. So how are they doubling the transistor count? Simple, double the number of CPU cores on the die. This tells me that CPUs themselves have probably reached the top as far as their complexity. Part of this is because of power consumption. As the oxide layers get thinner and thinner, the amount of current leakage increases. Strained insulator technology has helped mitigate this somewhat, but it is still getting worse. So by doubling the number of CPUs on the die, they can now better manage power because whole CPU cores can be shutdown to save power.
Other things of note were the 64bit items. They had an independent industry analyst get up and do a spiel that basically threw a whole bucket of cold water on the 64bit stuff and concentrated on the fact that multi-core is the hot item of the year. He touted the fact that with multi-core, the cost of mult-core systems can now become a common reality for the consumer market. Unlike 64bit that requires a complete rebuild of the applications (sans the whole 64bit .NET issue, in which .NET was only given a cursory glance), multi-core can benefit existing applications that already take advantage of multi-threading and multi-cpu. They kept touting video transcoding, gaming, collaboration, VOIP as applications that can immediately see the benefits of multi-core systems being ubiquitous.
As for the 64bit stuff, the Intel folks actually said that they have seen many cases where 64bit applications were actually slower than their 32bit counterparts! They attributed this to overburdened caches and overall code-bloat, especially in pointer intensive applications. They also stated that the advantages of 64bit was mainly increased memory addressability and not some mythical boost in performance. Sure, for memory intensive applications (read SQL database servers, video transcoding servers, etc..), the increased memory address space can lead to better overall performance, but that is not where the vast majority of applications spent their time. In fact they are pushing multi-core along with better multi-threaded applications as being the path to performance, irrespective of “bitness.”
Opteron, the chip from AMD, was mentioned several times, but AMD, the company, was only mentioned once, by the analyst dude. The Athlon 64 and Athlon 64FX chips were never mentioned, I suppose because they are the mainstream competitor to the new EM64T stuff from Intel. Actually, Danny and I were quite surprised that they even acknowledged that AMD even existed. They did this mainly to head off those obvious questions that are bound to come up. In fact they said that is why they mentioned it.
What does this mean for Delphi and Borland? Well, first of all, it certainly gives us more ammunition with which to go to management with proposals to schedule time for a alternative memory managers that better take advantage of these newer architectures. As for 64bit, we are still looking at the market as for when the best time to jump in would be. Clearly it is coming.. how fast and how soon... well... even Intel can't predict that. The talk from the analyst dude was quite interesting from a market trend point of view. It was what he didn't say that was most interesting. He didn't tell folks to jump right now on the 64bit bandwagon, but rather jump on the multi-core, multi-threaded bandwagon! In fact he played the whole “rebuild your application for 64bit” as a negative.