Parallel programming
One of the major challenges related to the evolution towards the multi-core is in the programming. Making 2 cores function isn’t always easy and 4 even more difficult. So what about 8, 16 or more? Now is the time to research, conceive and test solutions.STM
This is what Intel is doing with transactional memory, which they are already testing via STM (software transactional memory), a new beta compiler based on the classic Intel compiler and which allows developers to start playing with new possibilities.
In a way, this transactional memory is based on a type of policing which assures the integrity of data when several cores/threads function at the same time. A current problem is that a core can, for example, access a memory zone before another core has written the correct value or a core can overwrite a value before it has been read. This causes randomness in results and numerous bugs. The solution is to lock the CPU in sensitive functions in order that another core/thread cannot interfere. This prevents the CPU from taking advantage of all of its cores and the impact is detrimental to performances.
Transactional memory allows to block only those sensitive memory zones by transforming functions into atomic ones. The processor can go ahead and execute other tasks and the only constraint being "don’t touch my data". The advantage is obvious and this type of evolution has been awaited for some time. In other words, thank you Intel ! Note that Nvidia has integrated the same possibility to the GeForce 8600 (it wasn’t in the GeForce 8800), given that programming with CUDA suffers from the same constraints.
Ct
The second point presented by Intel was Ct. This involves C/C++ extensions which enable the developer to put into place parallel operations while keeping an "in series" view in mind. Therefore, this permits a simpler use of parallel architectures, mainly via new operators and new types of data structures. This code is then processed (via a runtime) to be adapted to intended CPU architecture before being sent to a classic compiler. The aim is to have a code capable of being used with different types of processors.
Exo
The last point, Exo (for accelerator exoskeleton) is related to all types of accelerators. Of course, we can envision Larrabee and 3D, but once again this will involve special development for the Larrabee for which developers aren’t yet ready.
Exo consists not of going through a driver and/or API to use an accelerator but simply including the code directly destined for it into the rest of the code. The compiler is in charge of dividing the code between the CPU and accelerator. Once again, this is something that will simplify development and enable better use of accelerators and thus be better offered to developers as a multimedia unit.
The current model on the left and Exo on the right.Ct and Exo roughly correspond to what Nvidia is doing with CUDA. The only difference is that Intel remedies the problems in a general way and not for some specific use. This is therefore a bigger task, all the more so that compatibility must be assured.
