2011/4/29 Stefan Marr <[email protected]>: > > 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 > > >
