[Pharo-project] Explicit control of Parallel execution in Smalltalk ? (was Counting Messages as a Proxy for Average Execution Time in Pharo)
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
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...
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.
> Stefan Marr
> Software Languages Lab
> Vrije Universiteit Brussel
> Pleinlaan 2 / B-1050 Brussels / Belgium
> Phone: +32 2 629 2974
> Fax: +32 2 629 3525
More information about the Pharo-project