Design Article
Multicore technologies and software challenges
Rajagopal Nagarajan
1/5/2010 7:06 PM EST
In recent times, there has been a perceptible slow down in the Moore's Law. Moore's Law says that the number of transistors will double in every 18 months. Well, transistor count is doubling, but performance is not keeping in pace. Performance kept pace till 2002 due to technologies like pipelining, caching and superscalar designs. After that however, the gap has started becoming visible as the returns from these technologies began to yield diminishing returns1.
Fig 1: Gap between performance and number of transistors (Courtesy: Embedded Systems Design).
For example, between 1993 and 1999, CPU speeds increased 10 fold. The first 1GHz CPU was released in 2000 but, in last 9 years, it has gone up only to 3.3 GHz, a growth that is considerably slower than the previous six years2.
Power is another driver. Power consumed is related to frequency and increasing frequency makes a huge drain on the power. The challenges of designing appropriate heat syncs, airflows in servers and desktops become pronounced as frequency increases. Another impact is the high opex costs of datacenters due to higher costs in air conditioning and cooling systems and there is pressure to reduce opex costs of enterprises and service providers. This is referred to as 'Power wall'.
Having exploited many optimization techniques and hit the power wall, semiconductor companies are now packing more cores in the processor, instead of increasing the speed of the processors. First versions of multicore processors supported a technology called Hyper threading. This allowed two or more thread contexts but they shared the same cache and external bus. The first real multicore processor was Intel Dual core Pentium processor, released in 2005.
Recent products from Intel sport quad cores. New ATOM cores and Cortex A9 cores support multiple cores and are aimed at smartphones and netbook markets. The leader in multicore is Tilera which has processors that support up to 64 cores. There are predictions that the processors will support 100's of cores in near future3.
The onus of improving performance has now moved from hardware to software and the big question is whether the software world prepared for it?
|
|
|
|
|
ramesh_nr
1/7/2010 1:42 AM EST
Raj, Nice and informative article.
Cheers,
N.R. Ramesh.
Sign in to Reply
tomahawkins
1/7/2010 11:13 AM EST
Good article. I'm glad to see some references to functional programing.
The Haskell community (a pure functional language) is actively pursing concurent language design and multi-core compilation. Haskell supports a handful of concurrency models including STM [1], an elegant new paradigm for concurrent programming that does not rely on locks and semaphores.
One the embedded side, we use a Haskell DSL called Atom [2], which has semantics similar to STM, but for hard realtime applications. Though Atom is only applicable to single processor systems at the moment, we are investigating ways to compile Atom for multiple processors -- or rather multiple vehicle ECUs, as in our case.
-Tom
[1] http://www.haskell.org/haskellwiki/Software_transactional_memory
[2] http://hackage.haskell.org/package/atom
Sign in to Reply
CaseyW
1/8/2010 11:58 AM EST
Thanks for contributing this article; I think it does a good job summarizing some of the key approaches for programming multicore processors.
You mentioned that functional languages can be ideal for distributed computing over multiple cores due to lack of side effects, but can pose a sharp learning curve for developers. I wanted to add that dataflow languages like LabVIEW not only share many similarities with these functional languages (code can be automatically mapped to multiple cores), but they can also reduce the learning curve for developers and intuitively represent parallel algorithms. Therefore, for many embedded developers the work to learn a new language may be justified in the ease of parallel programming that dataflow brings.
Sign in to Reply
KjellKod
4/5/2010 10:41 AM EDT
It was a nice article but I think it simplified and made huge assumptions that are not true. First I think it should have made a stronger distinction between parallel and concurrent. In this article the context (in my opinion) is mixed.
"Rajagopal Nagarajan Wrote:
Desktop applications like spreadsheets, word processors or editors are not amenable for multi threading"
I completely disagree. Dealing with user events, saving, loading, inserting and manipulating images, spell checking, translation etc, etc. are all examples when these programs commonly do use threads to achieve concurrency. And MUST do so or no one would use that software.
As more cores come into the picture and each CPU load/core probably will decrease I belive the average user will be less tolerant of annoying wait times - thereby providing a great incentive for using good concurrency software design. Removing the bottlenecks and remove wait time ... or that software just won't get purchased.
Sign in to Reply
abufrejoval
4/6/2010 12:28 PM EDT
When I try to describe the effects of the "Moore Gap" I use the term "core explosion", because it's a better fit to the dramatic effects we are seeing. Looking at the GPU designs today and the 48-core CPUs in the labs, I think "multicore" is a little soft. "Polycore" is just Greek rather than Latin, but somehow sounds like the kilocores are coming with the megacores somewhere behind.
But I did supercomputers 20 years ago and the programming challenges were similar: How to trick imperative programms/programmers into doing functional work?
Then I went into business for a while and what did I find? There are more people writing programs in a functional language than any other: Excel!
Spreadsheet formula language *is* functional. Actually with very few enhancements (and the elimination of functions with side-effects) spreadsheets may be better equipped to deal with polycores than any other I know. And most people work with spreadsheets quite intuitively...
Sign in to Reply
UDAYone
7/8/2010 6:59 AM EDT
Rajagopal, thanks for a very good article, well presented. It is good to see a full cycle turning along, as it reminds me of our time working on parallel computing at C-DAC among founding members. There was a paradigm shift then, and now back to one. These challenges were met successfully by C-DAC members, proud to be one of them. I want to mention parallel programming language Occam, which we used very successfully for MIMD paradigm, then SIMD can be seen as a simpler, inclusive paradigm. Occam is based on rigorous proven concept called Communicating Sequential Processes, developed by famous CAR (Tony) Hoare at Oxford. The Occam can be considered, as its constructs are simple and profound and it worked when C-DAC pioneered a lot of parallel computing projects successfully. I would like to know your thoughts in the current context and also about any work in this direction worldwide.
Thanks
Uday
Sign in to Reply
MINDTREE WIRELESS PVT LTD
1/4/2011 12:55 AM EST
A very good article for a biginner to Multicore programming. Very well presented.
-Paniraj
Sign in to Reply