The invisible wall and the (re)birth of parallel programming
In 2003 processor manufacturers hit the wall, it was clear that you simply cannot produce a processor much faster at reasonable costs. Intel first delayed its planned introduction of a 4GHz chip until 2005, and then in fall 2004 it officially abandoned its 4GHz plans entirely. The solution was the multicore processor and today most servers and even workstations are already running multicore processors but allmost no applications take advantage of the technique.
The free lunch is over, Dr. Dobb’s Journal stated in 2005, continuing:
Chip designers are under so much pressure to deliver ever-faster CPUs that they’ll risk changing the meaning of your program, and possibly break it, in order to make it run faster
The key to performance improvement and the survival in a multicore enviroment is simply to write programs that naturally scale up to multiple processors. Unfortunately, it is still very hard to write parallel algorithms that actually take advantage of such architectures, and it’s very hard to write concurrent code that scales dynamically (without recompilation) as more parallelism becomes available in the hardware. Parallel programming has been around for quite some time, just not the in modern meaning of the word. In the old days, parallel programming where simply math based operations parallelized over a number of computers, not cores.
Some rendering, encoding and math operations has already adopted the parallel programming technique over multiple cores, this is because scaling these operations over multiple cores is fairly easy in relation to some other types - such as modern applications reading data from external source.
For example; when an application call a database the operation becomes really hard to scale. For these types of operations we should start looking at async and threading instead of the usual sequential database calls - this way we can apply parallel operations to threads instead, which is much easier. Here is an example of this in the C# language trough the .NET Framework.
By parallelizing threads we can also, for example, make loops which normally are sequential operations very effective. These operations would in any language be similar to math calculations in gain of speed where each core reduces the load by 2 (In a perfect scenario that is).
So, evaluate your need for multicore processing applications, find out how your active and/or new solutions can implement it using its current language and/or framework, do this today and you can sleep well assured you’ll still be having your free lunch every day of the week.
More on this topic later, bye for now.
Libraries:
Microsoft Research has developed a .NET library to help exploit multi-cores chip, it called the Parallel FX Library.
OpenMP is a parallel programming library intended for the C language even if its parallelization is intended for multiprocessor environments it has the potential for multicore processing.
Learn more:
http://en.wikipedia.org/wiki/Parallel_computing
http://en.wikipedia.org/wiki/Parallel_programming_model
/ itcommie
Just a shout out from a friendly tech-savvy underpaid and overworking workingclass communists in great need of a permanent vacation.
Nice writing, will continue to read this Blog.
//fellowminded Guy in Götebooorg
You write very well.