[Pharo-project] Concurrent programming (was: Would you start a new Smalltalk project today?)
On Mon, Mar 23, 2009 at 11:39 AM, Antony Blakey <antony.blakey@gmail.com>wrote:
On 23/03/2009, at 7:37 AM, Michael van der Gulik wrote:
Smalltalk, the language rather than the implementation, already has fantastic support for concurrency. Smalltalkers just don't know how to use it. We don't need to rethink the model, we just need to learn to use what we have.
Mutexes and semaphores are hardly 'fantastic'. The state of the art in support for concurrency is way beyond what Smalltalk provides - locking is both primitive and generally not scalable.
Semaphores _are_ fantastic!! Lock-free algorithms are even cooler. The language lends itself to building up higher abstractions. Take for example Collection and all its subclasses; they're screaming out to have parallelised versions made: c := ConcurrentOrderedCollection new. c do: [ :each | ...this part gets executed in parallel...]. The caveat here is that you need to be careful about side-effects. This is just one example. I have some more rudimentary ideas at: http://gulik.pbwiki.com/Parallel+processing. Oh, and sorry to the Pharo guys for keeping this going. Let us know if you don't want threads like this on your list. Gulik. -- http://gulik.pbwiki.com/
2009/3/23 Michael van der Gulik <mikevdg@gmail.com>:
On Mon, Mar 23, 2009 at 11:39 AM, Antony Blakey <antony.blakey@gmail.com> wrote:
On 23/03/2009, at 7:37 AM, Michael van der Gulik wrote:
Smalltalk, the language rather than the implementation, already has fantastic support for concurrency. Smalltalkers just don't know how to use it. We don't need to rethink the model, we just need to learn to use what we have.
Mutexes and semaphores are hardly 'fantastic'. The state of the art in support for concurrency is way beyond what Smalltalk provides - locking is both primitive and generally not scalable.
Semaphores _are_ fantastic!! Lock-free algorithms are even cooler.
The difference between lock-free and semaphores is HUGE. Try to write a simulation which models a bunch of rocks rollong from the top of mountain, sometimes colliding with each other and breaking apart on smaller pieces. Now, let say each thread computing a single rock position in space. To detect a collision , you have to check/predict the trajectory where it intersects with another rock. A naive implementation would be to scan all rocks trajectories/positions and find those which colliding with concrete rock which single thread simulating. Now, inevitably you have to use a some collection 'Rocks', and scan it each time when you need to test for collisions. Since there are dozens of rocks, each requires to perform very same test. But remember, sometimes rocks are breaking apart, which means you need to add a new object(s) to Rocks collection, while removing old one. Because of that you HAVE to protect access to collection with semaphore. This means, that for 1000 access requests to this collection (including: scan, add, remove), only single can be fullfilled at a single point of time. Semaphores are fantastic in making such simulation run billion years on supercomputers. :)
The language lends itself to building up higher abstractions. Take for example Collection and all its subclasses; they're screaming out to have parallelised versions made:
c := ConcurrentOrderedCollection new. c do: [ :each | ...this part gets executed in parallel...].
The caveat here is that you need to be careful about side-effects.
This is just one example. I have some more rudimentary ideas at: http://gulik.pbwiki.com/Parallel+processing.
Oh, and sorry to the Pharo guys for keeping this going. Let us know if you don't want threads like this on your list.
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.
Rich Hickey the creater of Clojure (functional Lisp) has done a bunch of nice videos on the language here is one he did on concurrency that is really very good: http://blip.tv/file/812787 At the end, he introduces an ant colony simulation that has similar concurrency problems to your rock falling simulation. It is all done with immutable persistent data structures and transaction memory. I think it is the most exciting new programing language development of the past few years. I wound up watching many of his videos. Smalltalk could do this stuff well.
do you know pointers that explain the interplay between transactional memory and concurrency/immutable structure. On Mar 23, 2009, at 7:54 AM, David Finlayson wrote:
Rich Hickey the creater of Clojure (functional Lisp) has done a bunch of nice videos on the language here is one he did on concurrency that is really very good:
At the end, he introduces an ant colony simulation that has similar concurrency problems to your rock falling simulation. It is all done with immutable persistent data structures and transaction memory. I think it is the most exciting new programing language development of the past few years. I wound up watching many of his videos.
Smalltalk could do this stuff well.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 23/03/2009, at 7:05 PM, Stéphane Ducasse wrote:
do you know pointers that explain the interplay between transactional memory and concurrency/immutable structure.
There are many papers on STM that describe the benefits wrt concurrency. Wikipedia has a good explanation http://en.wikipedia.org/wiki/Software_transactional_memory with many subsequent links. The relative weight of the pros and cons vary depending both on the STM implementation (e.g. Clojure uses MVCC) and the language into which STM is embedded. Immutability makes a big difference by reducing contention granularity. Clojure has the additional benefit of explicitly identifying the points are which conflict can occur e.g. Refs. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 It is no measure of health to be well adjusted to a profoundly sick society. -- Jiddu Krishnamurti
Michael there is no problem. discussion is also good. Dogma or trolling would be boring :) On Mar 23, 2009, at 12:42 AM, Michael van der Gulik wrote:
On Mon, Mar 23, 2009 at 11:39 AM, Antony Blakey <antony.blakey@gmail.com
wrote:
On 23/03/2009, at 7:37 AM, Michael van der Gulik wrote:
Smalltalk, the language rather than the implementation, already has fantastic support for concurrency. Smalltalkers just don't know how to use it. We don't need to rethink the model, we just need to learn to use what we have.
Mutexes and semaphores are hardly 'fantastic'. The state of the art in support for concurrency is way beyond what Smalltalk provides - locking is both primitive and generally not scalable.
Semaphores _are_ fantastic!! Lock-free algorithms are even cooler.
The language lends itself to building up higher abstractions. Take for example Collection and all its subclasses; they're screaming out to have parallelised versions made:
c := ConcurrentOrderedCollection new. c do: [ :each | ...this part gets executed in parallel...].
The caveat here is that you need to be careful about side-effects.
This is just one example. I have some more rudimentary ideas at: http://gulik.pbwiki.com/Parallel+processing.
Oh, and sorry to the Pharo guys for keeping this going. Let us know if you don't want threads like this on your list.
Gulik.
-- http://gulik.pbwiki.com/ _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thanks Michael and Antony about this discussion. cheers, Alexandre On 23 Mar 2009, at 09:30, Stéphane Ducasse wrote:
Michael there is no problem. discussion is also good. Dogma or trolling would be boring :)
On Mar 23, 2009, at 12:42 AM, Michael van der Gulik wrote:
On Mon, Mar 23, 2009 at 11:39 AM, Antony Blakey <antony.blakey@gmail.com
wrote:
On 23/03/2009, at 7:37 AM, Michael van der Gulik wrote:
Smalltalk, the language rather than the implementation, already has fantastic support for concurrency. Smalltalkers just don't know how to use it. We don't need to rethink the model, we just need to learn to use what we have.
Mutexes and semaphores are hardly 'fantastic'. The state of the art in support for concurrency is way beyond what Smalltalk provides - locking is both primitive and generally not scalable.
Semaphores _are_ fantastic!! Lock-free algorithms are even cooler.
The language lends itself to building up higher abstractions. Take for example Collection and all its subclasses; they're screaming out to have parallelised versions made:
c := ConcurrentOrderedCollection new. c do: [ :each | ...this part gets executed in parallel...].
The caveat here is that you need to be careful about side-effects.
This is just one example. I have some more rudimentary ideas at: http://gulik.pbwiki.com/Parallel+processing.
Oh, and sorry to the Pharo guys for keeping this going. Let us know if you don't want threads like this on your list.
Gulik.
-- http://gulik.pbwiki.com/ _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (6)
-
Alexandre Bergel -
Antony Blakey -
David Finlayson -
Igor Stasenko -
Michael van der Gulik -
Stéphane Ducasse