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