March 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today?

by StÃ©phane Ducasse

I had the impression that this was the direction newspeak was going. On Mar 23, 2009, at 12:15 AM, Antony Blakey wrote: > > On 23/03/2009, at 12:32 AM, StÃ©phane Ducasse wrote: > >> can you illustrate that point? > > It might be that Smalltalk and wide-spread immutability and > fundamentally incompatible. The problem is that Smalltalk's model has > Objects whose state changes in response to messages. Such state change > breaks immutability. But if objects are immutable, then the problem is > that after any mutation operation within a method, subsequent sends > need to be not to self, but to the newly mutated object. This problem > cascades, with the effective self needing to change potentially after > every send. Maybe the solution is to enable that to happen seamlessly > e.g. 'self' changes as the object mutates (because the object isn't > actually mutating). Objects do make immutability-based concurrency > more 'interesting'. > > It's important to note that Clojure is a rethinking of Lisp, and the > end result is not Common Lisp + concurrency + Java interop. I suspect > that a rethinking of Smalltalk would be similarly different than what > we now know. This doesn't surprise me - out assumptions about > concurrency, or the lack of it, and general inexperience with taming > true concurrency, is a significant context the design of most existing > languages, with notable exceptions such as CSP/Occam. > > Maybe the appropriate concurrency model for Smalltalk IS an ultra- > lightweight fine-grained copy-on-write multiple image model, with that > being the *only* threading abstraction. If you could control the > separation e.g. share some objects with well defined concurrency > semantics like Clojure such STM/Refs/Agents etc, then that might be > the best fit. OTOH a shared-nothing model would give you CSP/Erlang. > The implementation challenges are very different, and I must admit I > don't know enough about Hydra to know if that project has solved this > issue. > > Antony Blakey > ------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > He who would make his own liberty secure, must guard even his enemy > from repression. > -- Thomas Paine > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 23, 2009

[Pharo-project] HowToContribute wiki page

by Serge Stinckwich

Hi, i'm currently reading this page : http://code.google.com/p/pharo/wiki/HowToContribute and it's not really clear when someone do not need to make a modification to several packages ... I guess you have to publish to modified package to PharoInbox also. Best regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

March 23, 2009

Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today?

by StÃ©phane Ducasse

> Here's some exposition: http://clojure.org/concurrent_programming I will reread it then > > >> Another question I would love to have immutability bit for pharo. >> Now if you have immutable collection then I imagine that >> - you should copy them when you want to modify them (functional) > > That happens automatically. Modification operations are functional > > e.g. f(data) -> data' > > data' is a different object than data, which remains unchanged. > Efficiently implementing this is the key, but it's been done. but do they guarante identity preservation I guess not. > > >> - I was wondering if the object that you put such immutable data >> structure should >> also be immutable > > Not necessarily - in the case of Clojure you might put a Ref/Var/Atom/ > Agent into an immutable structure, and those objects have their own > concurrency semantics as described in the link above. > > Antony Blakey > ------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > Borrow money from pessimists - they don't expect it back. > -- Steven Wright > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 23, 2009

Re: [Pharo-project] Software update

by StÃ©phane Ducasse

The update stream only includes update for the image pharo-core for the pharo-dev you should use the universe browser. We do not maintain tools that are build on top of pharo and let their maintainers act as they wish. Stef On Mar 23, 2009, at 12:24 AM, Mariano Martinez Peck wrote: > Hi guys. I am quite confused with software updates. > > When you do right button -> system -> software update, what is > updated? just the core ? > > For example, tools like OB how must be updated ? > > Thanks, > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 23, 2009

Re: [Pharo-project] Concurrent programming (was: Would you start a new Smalltalk project today?)

by David Finlayson

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.

March 23, 2009

Re: [Pharo-project] Concurrent programming (was: Would you start a new Smalltalk project today?)

by Michael van der Gulik

On Mon, Mar 23, 2009 at 2:21 PM, Michael van der Gulik <mikevdg(a)gmail.com>wrote: > > > On Mon, Mar 23, 2009 at 12:34 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: > >> >> 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. >> > > 10 times slower? Sounds like a made-up number to me... > > " Using 101 threads: " > c := ConcurrentArray new: 1000001. > Time millisecondsToRun: [c withIndexDo: [ :each :i | c at: i put: i > asString. ]]. > 5711 > 5626 > 6074 > > " Using 11 threads: " > c := ConcurrentArray new: 1000001. > Time millisecondsToRun: [c withIndexDo: [ :each :i | c at: i put: i > asString. ]]. > 3086 > 3406 > 3256 > > " Using 1 thread: " > d := Array new: 1000001. > Time millisecondsToRun: [d withIndexDo: [ :each :i | d at: i put: i > asString]]. > 2426 > 2610 > 2599 > > My implementation is 1/2 to 1/3 the speed of the single-threaded Array. If > the blocks did more work, then the overhead would be lower and some benefit > would be gained from using multiple cores. > > I don't have a good idea of where the overhead is going - maybe it's being > lost in the block copying that is needed to work around Squeak's > deficiencies? Or maybe it's waiting for the scheduler to do its stuff? > > Implementation attached, MIT license if you're picky. > > I just tried it on VisualWorks as well. I removed the block copying and renamed the method to "keysDo:" (I never thought of an array like that before... keys and values). d := Array new: 1000001. Time millisecondsToRun: [d keysDo: [ :i | d at: i put: i printString]]. 1180 982 1008 " Using 101 threads " c := ConcurrentArray new: 1000001. Time millisecondsToRun: [c keysDo: [ :i | c at: i put: i printString. ]]. 1072 1120 962 At this stage, I'm suspicous about the results :-). Gulik. -- http://gulik.pbwiki.com/

March 23, 2009

Re: [Pharo-project] Concurrent programming (was: Would you start a new Smalltalk project today?)

by Michael van der Gulik

On Mon, Mar 23, 2009 at 12:34 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > 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. > 10 times slower? Sounds like a made-up number to me... " Using 101 threads: " c := ConcurrentArray new: 1000001. Time millisecondsToRun: [c withIndexDo: [ :each :i | c at: i put: i asString. ]]. 5711 5626 6074 " Using 11 threads: " c := ConcurrentArray new: 1000001. Time millisecondsToRun: [c withIndexDo: [ :each :i | c at: i put: i asString. ]]. 3086 3406 3256 " Using 1 thread: " d := Array new: 1000001. Time millisecondsToRun: [d withIndexDo: [ :each :i | d at: i put: i asString]]. 2426 2610 2599 My implementation is 1/2 to 1/3 the speed of the single-threaded Array. If the blocks did more work, then the overhead would be lower and some benefit would be gained from using multiple cores. I don't have a good idea of where the overhead is going - maybe it's being lost in the block copying that is needed to work around Squeak's deficiencies? Or maybe it's waiting for the scheduler to do its stuff? Implementation attached, MIT license if you're picky. Gulik. -- http://gulik.pbwiki.com/

March 23, 2009

Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today?

by Schwab,Wilhelm K

Ensure execution of releasing the lock is about as slick as it gets. You might want to have another look. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Antony Blakey Sent: Sunday, March 22, 2009 6:14 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today? On 23/03/2009, at 9:36 AM, Schwab,Wilhelm K wrote: > Semaphores and Mutexes are the lower level tools. **Critical > sections** implemented in terms of blocks are the fantastic part. I don't regard critical sections as particularly fantastic. > The little that I know about functional languages and their > immutable data structures suggests that a LOT of copying occurs. > That has to be expensive in terms of scheduling and memory footprint. A lot less than you might think, but this reminds me of the arguments people make against Smalltalk and Lisp. Old radicals become the new conservatives. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The greatest challenge to any thinker is stating the problem in a way that will allow a solution -- Bertrand Russell _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 23, 2009

Re: [Pharo-project] Concurrent programming (was: Would you start a new Smalltalk project today?)

by Igor Stasenko

2009/3/23 Michael van der Gulik <mikevdg(a)gmail.com>: > > > On Mon, Mar 23, 2009 at 11:39 AM, Antony Blakey <antony.blakey(a)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. > > > -- > http://gulik.pbwiki.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 23, 2009

Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today?

by Igor Stasenko

2009/3/23 Antony Blakey <antony.blakey(a)gmail.com>: > > On 23/03/2009, at 12:32 AM, StÃ©phane Ducasse wrote: > >> can you illustrate that point? > > It might be that Smalltalk and wide-spread immutability and > fundamentally incompatible. The problem is that Smalltalk's model has > Objects whose state changes in response to messages. Such state change > breaks immutability. But if objects are immutable, then the problem is > that after any mutation operation within a method, subsequent sends > need to be not to self, but to the newly mutated object. This problem > cascades, with the effective self needing to change potentially after > every send. Maybe the solution is to enable that to happen seamlessly > e.g. 'self' changes as the object mutates (because the object isn't > actually mutating). Objects do make immutability-based concurrency > more 'interesting'. > > It's important to note that Clojure is a rethinking of Lisp, and the > end result is not Common Lisp + concurrency + Java interop. I suspect > that a rethinking of Smalltalk would be similarly different than what > we now know. This doesn't surprise me - out assumptions about > concurrency, or the lack of it, and general inexperience with taming > true concurrency, is a significant context the design of most existing > languages, with notable exceptions such as CSP/Occam. > > Maybe the appropriate concurrency model for Smalltalk IS an ultra- > lightweight fine-grained copy-on-write multiple image model, with that > being the *only* threading abstraction. If you could control the > separation e.g. share some objects with well defined concurrency > semantics like Clojure such STM/Refs/Agents etc, then that might be > the best fit. OTOH a shared-nothing model would give you CSP/Erlang. > The implementation challenges are very different, and I must admit I > don't know enough about Hydra to know if that project has solved this > issue. > Hydra simply runs separate object memories in separate native threads. This is clearly share nothing approach. The only win comparing to running multiple OS processes is the ability to establish a fast communication between them, as well, as in future, relax the 'share-nothing' relation towards partial sharing(islands/vats/micro-images). This i think would be best way to go, which would require minimal changes to language side. It is also good, because it is quite incremental i.e. you don't have to rewrite the whole smalltalk from scratch. -------- Now about other replies in topic by different people: Antony right: mutexes, semaphores, critical sections - this is simply doesn't scales! Forget about it! Leave these constructs to java & C/C++ , they are existing for more than 10 years in operating systems and their limitations are well known :) immutability - at a large scale, like automatic copy-on-write magic IMO would be a waste. And besides, smalltalk is one of the languages who says NO to magic. That's why i like it so much. :) > Antony Blakey > ------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > He who would make his own liberty secure, must guard even his enemy > from repression. > Â -- Thomas Paine > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 23, 2009