The postulation of Douglas Engelbart back in 1965 that the complexity of computers would double every 24 months has held true ever since he said it. Although it was originally Engelbart's theory, it was carried to the press by Gordon Moore back in April of 1965, and has thus been famously attributed to him as “Moore's Law“. This means we've seen exponential advances in computing power over the past four decades:
(Handy chart of Moore's law from Wikipedia)
But is this coming to an end? We've reached the limit of easy performance gains by making the traces smaller and increasing the clock speed in order to get better performance. Things are getting so close together that principles of RF come into play as neighboring traces on the teeny chip act like broadcast and receiving antennas, and further miniturization is tough without having the chip go nuts. Instead of one faster core, the big chip makers are resorting to multiple cores, but this has been met with mixed reviews. Performance reports of the Core Duo processors are coming in at about 35% faster than their single-core cousins, laughing in the face of Intel's claim of a 68% performance gain. Being curious, I wanted to experiment a bit further to see what all the fuss was about, so I got a groovy Sony SZ-120 whose Core Duo processor runs at 1.8 GHz. I could then easily compare it to the single-core 1.8 GHz Centrino machine I have been using for the past two years.
The Sony SZ-120 on the left, and the Dell D600 on the right both run the processor at 1.8 GHz.
After a little testing I found that Moore's law is in fact still alive and well, but it is now up to us, the programmers, to bring to pass the next wave of performance gains. Let me explain.
I set up both laptops to perform the processor-intensive task of compressing video. I deliberately chose an older compression engine that operates just single-threaded, the Tsunami MPEG encoder. With each machine running one instance of TMPGEnc compressing the exact same video, the Dell took 90 minutes to complete, and the Sony 65 minutes. So the Sony was 38% faster, which is in keeping with the kinds of performance gains recorded by others who have reviewed Core Duo machines. But what about running multiple instances of the same thing? With the Dell running two instances it took about twice as long, completing the task in 178 minutes. And with three if I would have let it complete would have been around 267 minutes (but I got impatient and ended it early). No big surprises there. To do twice or three times the work took twice or three times the amount of time.
The wonderful thing was that on the Core Duo machine running two instances completed in only 68 minutes instead of 65. So it can do twice the amount of work in pretty much the same amount of time if there are multiple threads involved. As expected running three instances took only about 50% longer than two, at 106 minutes total. So here's the breakdown:
|
Instances |
| 1 |
2 |
3 |
| Dell single-core |
90 |
178 |
267 (estimated) |
| Sony duo-core |
65 |
68 |
106 |
| % faster |
38.5% |
161.8% |
151.9% |
Minutes to complete the same compression task 1, 2, or 3 times
Major portions of the various speed tests reviewers have used are apparently single-threaded, and as such fetched the same bleak performance gains seen in the single instance column of my chart. But if the code the reviewers used threw more threads then we would see the kinds of performance gains Intel has promised. Here's one great review from Tech Report that goes the distance to analyze performance with multi-threaded applications.
Moral of the story for us as programmers: if performance matters then we need to make better use of .NET's System.Threading and Java's java.lang.Thread classes in order to get the best possible response out of our applications.