Time to think about parallel Smalltalk stuff
Matej Kosik
kosik at fiit.stuba.sk
Wed Jan 19 16:58:55 UTC 2005
goran.krampe at bluefish.se wrote:
> Hi folks!
>
> John M McIntosh <johnmci at smalltalkconsulting.com> wrote:
> [SNIP]
>
>>think interesting things would happen. An easier solution as Tim points
>>out is to run 2 or 5 or 1000 images and distribute/share data via
>>sockets or even shared memory. I recall once hearing about a Gemstone
>>solution that used shared memory, to enable the sharing of mostly
>>static data 100MB+ across lots of images. That reduced the overall
>>footprint on the server by lots.
>
>
> GemStone has a VM plus a whole bunch of other processes running in a
> shared-memory-pages-scheme with a transaction model keeping it all in
> synch.
>
> The net effect is that multiple VMs share (through transactional
> replication) "an image" or what is often referred to as an object
> memory. This means there is no "automatic" parallellism in actual
> *computation* going on - I mean, you still have to turn your Smalltalk
> code into multiple processes/threads - which your post also explained,
> just wanted to stress it once more. But at least a multitude of VMs can
> run (each on its own CPU and possibly own box) sharing the same object
> space in a coordinated fashion.
>
> This is of course also what Magma/GOODS etc can give you - a shared
> transactional memory.
>
> Given my limited knowledge in the area it seems that the semantics of
> message passing would have to be changed in order to get "automatic full
> scale" parallellism. Typically each object would execute in its own
> Process and messages would be asynchronous. I also assume these lines of
> thought is what SqueakELib
> (http://map1.squeakfoundation.org/sm/packagebyname/squeakelib,
> www.erights.org), Croquet in some way and also Tweak is experimenting
> with.
Concerning E I have come to the following conclusion:
"E objects do not migrate (for security reasons). It makes it
unscalable. Also the existence of ''vat''-s is awful. It does not seem
to be suitable for fine-grained parallel computation because E's
constructs for asynchronous message passing are not powerful enough in
order for the programmer to be able to express everything solely by
means of them. Furthermore, the computation inside the ''vat''-s happens
in so called ''turns''. These turns cannot execute concurrently because
inside each turn programmers usually do normal call/return-s and thus
they would need to use additional synchronization mechanisms on the
shared mutable data.
E seems to be a good platform for creating loosly coupled (information)
systems."
(my personal opinion)
>
>
> regards, Göran
--
skype: matej_kosik
icq: 300133844
http://altair.dcs.elf.stuba.sk/wiki/Main/MatejKosik
phone: (421) 910-993-245
-=x=-
Skontrolované antivírovým programom NOD32
More information about the Squeak-dev
mailing list
|