Re: Compiler support for multicore architectures

> ...
> 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

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