Time to think about parallel Smalltalk stuff
Michael Latta
lattam at mac.com
Wed Jan 19 02:16:09 UTC 2005
Jecel,
Thanks for jumping in. The reference was interesting. In particular
it unifies why I like APL and Smalltalk. What I like about APL is the
ability to operate on a large number of items as a unit. I like
similar constructs in Smalltalk (collect:, select:, etc). The C/Java
languages still make me deal with each item individually. While the
difference in syntax is annoying because of the wordiness of Java, the
conceptual difference has an amazing ability to drain productivity. I
think it ties back to the studies that programmers got the same number
of lines coded in any language. I can produce the same number of
conceptual operations per unit time, and in APL/Smalltalk that produces
more results than in C/Java because I only deal with one conceptual
operation to manipulate a whole structure.
If we approach collections using future proxies we can get a lot of
concurrency. For example collect/select/detect would result in a proxy
that binds the input collection to the operator (block). This use of
proxies will also require copy on modify semantics or a radical head
rewiring for the programmer. I am not sure which I would vote for at
this time. The do: proxy would do the same with binding a collection
to a block. The result would be proxies holding onto proxies onto
proxies. These chains could then be linear or not as you chose. The
result would be pipelined chains of operations that could be used to
efficiently fill CPU pipelines.
Michael
On Jan 18, 2005, at 12:22 PM, Jecel Assumpcao Jr wrote:
> Tim Rowledge wrote on Tue, 18 Jan 2005 16:21:46 -0800
>> You're all thinking much to small - or maybe too big, depending. I
>> think for _massive_ parallelism we want to be able to schedule each
>> method invocation to any available compute resource. Prims would
>> potentially be parallelisable as well in some cases.
>> Forget all this crap about "one cpu for garbage collection and another
>> for running the interpreter" - I'm talking 100, a 1000 a million cpus.
>
> Like this?
>
> http://www.merlintec.com:8080/hardware/19
>
>> The current sort of VM would be utterly pointless in such a world.
>
> Yes, though a step in that direction with just a small number of CPUs
> is
> also interesting. That is why I call my current hardware "Plurion". We
> have to walk before we run, right?
>
>> Quite possibly the current sort of Smalltalk would be useless.
>
> No, but it would be nice to program in a more APL-like (Fscript-like?)
> style instead of the Fortran/C one that people are used to.
>
> Michael Latta mentioned my tinySelf 1 work
> (http://www.lsi.usp.br/~jecel/tiny.html#rel1) where the idea was to see
> how well a large amount of code written in a very sequential style
> could
> be parallelized. Sadly this was interrupted by another project before
> it
> was debugged enough to run anything more than trivial expressions. It
> was probably some simple bug - contexts would sometimes come back to
> life after having been returned from. If I had used a more OO
> programming style (less explicit queue manipulations) it would have
> taken me about two hours for fix this. As it was, it probably would
> have
> taken me two days.
>
> While the trivial expressions did have a parallelism of four or five, I
> believe that real applications would have reached several dozens or
> more. The idea of treating each object as a complete computer that
> talks
> to others over some network can get us very far.
>
> -- Jecel
>
More information about the Squeak-dev
mailing list
|