Analysis: Dual Core technology

Posted on 27 May 2005 at 11:02

Application benchmarks
The reason Intel will continue to produce new high clock speed, single-core parts is shown by the results from our application benchmarks (see left). These are based on real-world applications, which haven't been designed from the ground up with parallel execution in mind or perform tasks that simply don't lend themselves to threading. As a result, the scores are well below that of the higher-clocked single-core EE part overall.

So is dual core worth it?
Absolutely, unequivocally, yes. We don't want to get too evangelical about it, but the advent of true multiprocessing on the desktop - and Intel's explicit acknowledgement that it has processors in the works with more than two cores (its engineers have mentioned 16- and 32-way multi-core at
press conferences) - is a massive leap forward for computing. The reason it hasn't happened before is down to understandable reticence in the face of the budget sheets: the massive cost and problems of changing the way developers work. But Intel has seen the writing on the wall and realised
it must bite the bullet and bear the cost in order that computing power can increase in the long term. Once the big technical challenges to software engineering have been overcome, the door opens to almost
unlimited increases in computing performance.

The roadmap
The Intel processor roadmap is almost entirely, but not completely, devoted to dual-core and multi-core processors. Variants of the same cores will be used in new processors with both single-, dual- and possibly multi-core versions. Thus, the EE and first Pentium D processor cores are
basically 5xx-series Pentium 4s, based on a 90nm fabrication process. The next generation of parts will be based on the core now known as Cedar Mill. This will be the first based on a 65nm fabrication process, with 2MB of Level 2 cache. A pair of these basic cores will form the next
generation of desktop dual-core processors known as Presler, while a single-core variant of Cedar Mill will be released, probably under the Pentium 4 name and almost certainly clocked higher than the dual-core part.

The pitfalls of multithreading
Some computing tasks lend themselves extremely well to multithreading, and it's easy to speed them up with this approach. A good example is the common need to generate thumbnail images from a folder full of JPEG photos.

The application programmer can multithread this process so that, for each image in the folder, a separate independent thread of execution launches to load, decode and eventually display the image in the preview pane.

Up to a point, the more of these threads you have running in parallel, the quicker all the images will be displayed. Multithreading works well here, because the loading, decoding and display of each image isn't dependent on the loading, decoding and display of any other. But now think about what happens if our programmer wants to go to town with their multithreading. If they want to multithread the subprocess of reading the image file from disk and doing the fairly complex calculations
needed to display that image onscreen, they run into problems. You can't simply start two threads, one to read an image from disk and one to decode it. The thread dedicated to decoding calculations will sit around and not be able to do anything until the thread dedicated to reading the image has
made the data ready and can pass that data along. There's no benefit to parallelising the operation in this way, and in fact it may be slower than doing everything serially because of thread-tracking overheads.