[LLVMdev] Re: idea 10

["?=Valery A.Khamenya=?koi8-r?Q?"]

Hello Se'bastien,

> I'm not sure to correctly understand what you mean, but I interpret it 
> as LLVM deciding where the code should be executed, like some 
> load-balancing strategy.

in this particular example it was really like that.
However I've tried to emphasize as well, that a decision 
"where to execute" is strongly connected with
LLVM optimizations, which become either 
applicable or not applicable depending on result of 
the decision. 

> In this perspective, I think this should be 
> left up to the higher-level language, or event to the application 
> developer: I don't think incorporating load balancing strategies 
> directly into LLVM would be interesting, because strategies are high 
> level patterns.

1. strategy of balancing does not completely belong to application.

2. even being no LLVMdeveloper, I do like minimalist approach to LLVM design "throw out everything, what might be thrown away", but "don't throw more!" :) -- How could you express in LLVM "optimization for remote call" if "remote" doesn't fit to LLVM?..

> To me this appears more as an algorithmic design issue, this function 
> could be rewritten in "continuation passing style", and each 
> continuation could be distributed by a load-balancing strategy to the 
> computers sharing CPU resources. Using mechanisms such as "futures" (as 
> in Mozart) allows to do this easily...

1. It looks like you mean here, that one *must* change the 
code of Fib function in order to control the 
parallelization, right?

2. do you propose to ignore languages not supporting "continuation passing style"? 


> but I don't think these features 
> belong to the set of languages low level primitives and constructs.

if you don't pollute Fib. function with explicit 
optimizations and use language like C, then what kind 
of level should bring "parallel optimization" 
to your Fib. code?.. 

don't forget, I'd like to parallelize any parallelizable 
code, like in this Fib. example, written in C

> I personally don't think that automating the conversion of an algorithm 
> from non-distributed to distributed execution can be done at a low 
> level, mainly because it involves many high-level constructs. 

well, don't kill me, but I don't share your religion in this point :)

More practically: let's use Fib example to get it parallelized 
in terms of LLVM. The example is simple enough!

> On the 
> other hand, I have heard of languages that try to implement primitives 
> for easy distributed computing, like the "Unified Parallel C" (see 
> http://www.gwu.edu/~upc/documentation.html and 
> http://ludo.humanoidz.org/doc/report-en.pdf), which may help to figure 
> out what kind of primitives would be useful for adding distributing 
> computing support into LLVM.

i agree. (and thank you for the nice links)

> Maybe you were thinking of something similar to UPC primitives 
> added to LLVM ?

rather "yes".