Re: Compiler support for multicore architectures

m.helvensteijn@gmail.com
Wed, 19 Nov 2008 00:50:12 -0800 (PST)

          From comp.compilers

Related articles
Compiler support for multicore architectures gauravgautam123@gmail.com (gaurav) (2008-11-18)
Re: Compiler support for multicore architectures kamalpr@hp.com (kamal) (2008-11-18)
Re: Compiler support for multicore architectures ian@airs.com (Ian Lance Taylor) (2008-11-18)
Re: Compiler support for multicore architectures m.helvensteijn@gmail.com (2008-11-19)
Re: Compiler support for multicore architectures walter@bytecraft.com (Walter Banks) (2008-11-19)
Re: Compiler support for multicore architectures toby@telegraphics.com.au (toby) (2008-11-20)
Re: Compiler support for multicore architectures jatin.bhateja@gmail.com (Jatin Bhateja) (2008-11-21)
Re: Compiler support for multicore architectures kamalpr@hp.com (kamal) (2008-11-23)
Re: Compiler support for multicore architectures idbaxter@semdesigns.com (Ira Baxter) (2008-11-28)
Re: Compiler support for multicore architectures bear@sonic.net (Ray Dillinger) (2008-11-28)
[1 later articles]
| List of all articles for this month |

From: m.helvensteijn@gmail.com
Newsgroups: comp.compilers
Date: Wed, 19 Nov 2008 00:50:12 -0800 (PST)
Organization: Compilers Central
References: 08-11-086
Keywords: parallel
Posted-Date: 19 Nov 2008 19:52:46 EST

On Nov 18, 10:27 pm, gaurav <gauravgautam...@gmail.com> wrote:


> There has been a lot of discussions going on about compiler support
> for multicore architectures.
>
> I have a few basic questions.
>
> What different things can a compiler do to make mutithreaded programs
> run better on multicore? Isnt it much depends on the threading
> library , OS and the programmar instead on compiler ?
>
> It will be great to have your thoughts on this.


You're right that a lot of this is up to the programming language and
the programmer. But a lot of sequential code can in fact be (partly)
parallelized. If I sort one big list, and then another, couldn't they
have been sorted concurrently? Also, a lot of loops do not need to be
executed in their original order if their iterations are not dependent
on each other. If programmers have no choice but to use (for example)
for-loops, because the language didn't provide an inherently
concurrent 'forall-loop', the compiler may be able to transform one
into a forall-loop by static analysis of the code.


Those were just a few examples. The trick is finding out which
transformations preserve the semantics of the program. That is, for
all possible program input, the output in the transformed version
should be the same as in the original.


I know people are working on much more sophisticated tools for this
job that may eventually become part of modern compilers.


--
Michiel Helvensteijn



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.