|[4 earlier articles]|
|Re: Compiler support for multicore architectures email@example.com (Walter Banks) (2008-11-19)|
|Re: Compiler support for multicore architectures firstname.lastname@example.org (toby) (2008-11-20)|
|Re: Compiler support for multicore architectures email@example.com (Jatin Bhateja) (2008-11-21)|
|Re: Compiler support for multicore architectures firstname.lastname@example.org (kamal) (2008-11-23)|
|Re: Compiler support for multicore architectures email@example.com (Ira Baxter) (2008-11-28)|
|Re: Compiler support for multicore architectures firstname.lastname@example.org (Ray Dillinger) (2008-11-28)|
|Re: Compiler support for multicore architectures email@example.com (firstname.lastname@example.org) (2008-11-30)|
|Date:||Sun, 30 Nov 2008 19:00:38 -0800 (PST)|
|Posted-Date:||01 Dec 2008 07:01:25 EST|
On Nov 18, 3: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 ?
We had a nice little workshop of about 150 people or so who showed up
for "Bridging Multicore's Programmability Gap" at Supercomputing '08
I'm going to be controversial by venturing out and saying that there's
not a lot of "compiler support" for symmetric multicore processors.
Given that C/C++ are the dominant languages and that APIs are the
general means for exploiting new features, there's not a lot to be
done in compiler support for multicore. Oh, sure, there's OpenMP and
autovectorization and polyhedral loop representation, but, overall,
automatic parallelization is still the Holy Grail of compilers.
Consequently, my personal and not so humble opinion is that you'll see
interesting support in new languages (Chapel, X-10) and their
Return to the
Search the comp.compilers archives again.