Re: Compiler support for multicore architectures

kamal <kamalpr@hp.com>
Sun, 23 Nov 2008 23:47:55 -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)
Re: Compiler support for multicore architectures scooter.phd@gmail.com (scooter.phd@gmail.com) (2008-11-30)
| List of all articles for this month |

From: kamal <kamalpr@hp.com>
Newsgroups: comp.compilers
Date: Sun, 23 Nov 2008 23:47:55 -0800 (PST)
Organization: Compilers Central
References: 08-11-086 08-11-108
Keywords: architecture
Posted-Date: 24 Nov 2008 17:59:17 EST

> ...
> void fun(int i,int j)
> {
>
> int a = work1(i,j);
> int b = work2(i,j);
>
> return a + b;
>
> }
>
> After procedure body analysis if it is found that work1 and work2 are
> re-entrant or pure calls then compiler can make the calls to work1 and
> work2 to be threaded i.e. it can introduce additional thread calling
> APIs in the intermediate code.


This can yield some benefit, but the best performance improvement
obtained so far has been in loops, not inter-procedure calls. It
actually depends on the structure of the program as to what will yield
best results and that has histtorically been loops. Parallel
constructs that have been proposed so far have focussed more on loops
than on procedure calls.


> This can actually be called as auto-multithreading.


If dusty deck programs were written with pure rentrant functions in
mind, then they would have gone one step ahead and made it multi-
threaded. Point is that input to the compiler won't be as amenable to
parallelization as you make it out to be.


regards
-kamal


Post a followup to this message

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