MultiCore Vs MultiThreaded. Do we need new languages??

MultiCore Vs MultiThreaded. Do we need new languages??

Do you think lack of automated parallelization is the main distinction between parallel programming and multicore programming?

What -if any- are the other main differences?

Do we really need a new PLto exploitthe capabilities offered by multi core?

Also, what are the challenges programmers will really face when programming for multicore?

Does programming in multi core pose new security threats? Are there new potential vulnerabilities brought by the use of many core?



4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Ah, this is a treasure-trove of interesting questions, intertwined. Let me start by parsing them into smaller bites:

  • Defining terms: what are "parallel programming" and "multicore programming", and how are they related?

By coincidence, this forum recently posted Parallel Programing Glossary of Technical Terms, so I turned to that ...hmm, neither term is explicitly defined. Wikipedia likewise dodges the question, by redirecting to "parallel computing", but that is not a bad starting point.
There's a nice set of pictures here: Introduction to Parallel Computing, including the definition "parallel computing is the simultaneous use of multiple compute
resources to solve a computational problem". Let's say that "parallel programming" is the set of techniques to realize that simultaneous use. If the target platform is a multicore system, then there is a subset of parallel programming techniques suitable to that platform. "Multicore" really refers to a particular, and now normal, chip architecture; I recommend thinking of the task of coding for them as "parallel programming".

  • Where does automated parallelization fit in here?

From auto-parallel switches (long available in many compilers), to significant multi-year research projects on implicit techniques (for example, The Illinois Implicitly Parallel Architectures Group), automatic parallelization has served as a holy grail, and the quest continues. Personally, I'm not optimistic in the near term -- the problem is very hard, and there is little evidence of impending breakthrough.
As others have pointed out, the problem is compounded by the implied requirement to take serial code and make it run, somehow, concurrently. This approach is the precise opposite of how science traditionally works -- normally, you take a hard problem, and reduce it to a simpler one, at least to start (think of those early physics classes where you ignored friction, or models of flow and turbulence, or models of protein folding, etc). The autoparallel crowd starts with a hard problem (find reliable hueristics to discover concurrency) and makes it harder (do this on serial designs). Care to wager on the outcome?

There are more questions here -- new parallel languages? biggest challenges? unintended security leaks? I'll be getting to those next time.

On the subject of parallel languages, current and near term future practice provides useful options which a new language must improve upon to be considered "needed:"
Fortran 2008:

Not that existence of current useful options will deter those who deem new languages necessary, at least in furtherance of academic goals.


Wow, what a great set of questions! I expect you will get as many different opinions as you get responses....

I'll give my $.02 on just one question for now...

> Do we really need a new PL to exploit the capabillities offered by multi core?

I believe we do. After many years of trying to force existing languages to easily and efficiently parallelize an existing algorithm, I can honestly say that it can be very difficult to re-write the algorithm intoparallel tasksand debug the new program. Existing languages and tools are still too difficult for average programmers to program for multi-core. We need to be designing for parallel from the start instead of trying to parallelize a serial program. A new programming language that enablesthe natural expression of parallel tasks in a scalable mannerANDaddresses the data issues will enable a much wider set of programmers to utilize multi-core.Are we willing to have a small subset of programmers writing parallel programs while the remainder continue to write serial programs??? I am not naive and am well aware that getting a new language designed/accepted/adopted will not be easy and will taketime.However, I believe we have to have new language(s).


Leave a Comment

Please sign in to add a comment. Not a member? Join today