[Pharo-project] Explicit control of Parallel execution in Smalltalk ? (was Counting Messages as a Proxy for Average Execution Time in Pharo)

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Apr 29 02:18:40 CEST 2011


2011/4/29 Stefan Marr <pharo at stefan-marr.de>:
>
> On 29 Apr 2011, at 01:07, Nicolas Cellier wrote:
>>>> However, as I understand it, it's entirely up to user to write code
>>>> exploiting parallel Process explicitly right ?
>>> Sure, you have to do: n times: [ [ 1 expensiveComputation. ] fork ].
>>>
>>> I don't belief in holy grails or silver bullets.
>>> Automatic parallelization is something nice for the kids, like Santa Clause or the Easter Bunny...
>>
>> Unless your hobby is oriented toward functional languages maybe...
>> But I just know enough of it to now shut up ;)
> Would be nice, but that is also a fairy tale.
>
> The best we have today, in terms of being 'easily' automatically scheduleable are data-flow/stream languages. Things like StreamIT or Lucid have interesting properties, but well, its still a search for the holly grail.
>
> Best regards
> Stefan
>

Interestingly, I was thinking of Xtreams as an obvious Smalltalk test
case for parallelism.
But of course choosing manually an optimal multi-Process
implementation is far from easy...
Reading http://cag.lcs.mit.edu/commit/papers/06/gordon-asplos06-slides.pdf
reinforce my feeling that it shall not be optimized manually, and that
user shall not design/assign Process directly. I don't know what the
right abstraction would be in Smalltalk though such that a VM could do
it, and neither do I understand how StreamIT solves the optimization,
but thanks for these interesting clues.

Nicolas

>
> --
> Stefan Marr
> Software Languages Lab
> Vrije Universiteit Brussel
> Pleinlaan 2 / B-1050 Brussels / Belgium
> http://soft.vub.ac.be/~smarr
> Phone: +32 2 629 2974
> Fax:   +32 2 629 3525
>
>
>



More information about the Pharo-project mailing list