2009/3/22 Michael van der Gulik <mikevdg@gmail.com>:
Argh. Stupid GMail sent it prematurely.
On Mon, Mar 23, 2009 at 10:45 AM, Michael van der Gulik <mikevdg@gmail.com> wrote:
If, for example, you were trying to allocate an array of arrays concurrently, then I would write (using my namespaces :-) ):
array := Concurrent.Collections.Array new: 1000000000. " We ignore the cost of making this array to begin with :-) " array withIndexdo: [ :each :i | Â Â Â " each will always be nil. " Â Â Â array at: i put: (Array new: 10). ].
Concurrent.Collections.Array>>withIndexDo: aBlock     | nThreads sema |    nThreads := 1000. " Pull this from a system setting or something. "    sema := Semaphore withSignals: 0-nThreads. " Needs implementing: signal it -1000 times (or -999 or -1001? Unsure) "    1 to: nThreads do: [ :i |        [ (nThreads*i) to: (nThreads*i - 1) do: [ :j            aBlock value: (self at: j) value: j ]
        sema signal.         ] fork ].
   sema wait.    ^ self.
Again, it probably won't just run without some bug fixing. And it won't work on non-closure Squeak anyway.
Now consider the overhead of creating a fork vs the actual useful code which is running within a block. I presume, this code will run 10x times slower on a single core processor, comparing to one w/o forks. So, you will need to have 10 cores to match the computation time with single core processor. I think its not wise to introduce parallelism on such low levels (in Concurrent.Collections.Array>>withIndexDo:). Its like hammering nails with microscope :) That's why i'm saying its too good to be true. Introducing parallelism at such low levels will be a waste. I leaning toward island model. This is a middle point between no sharing, like in Hydra and sharing everything, like in what you proposing.
Gulik.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.