[Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today?
Hi all I found this email really interesting. Especially the concurrent aspects. Clearly some nice research projects in perspective. Also the immutability bit supports would be great. Stef Begin forwarded message:
From: Antony Blakey <antony.blakey@internode.on.net> Date: March 18, 2009 2:50:47 AM CEST To: dfinlayson@usgs.gov, VWNC NC <vwnc@cs.uiuc.edu> Subject: Re: [vwnc] Would you start a new Smalltalk project today?
I am a commercial user of VW.
I've recently replaced my VW/GLORP/Postgresql app with one built in Ruby/CouchDB. I moved to Ruby because the documentation/learning material is superior to VW, because of the number of third party components, which is partly an issue of VW not being Open Source, because of tools such as Rails, Sinatra and Merb (which I still prefer over Seaside), and because I needed to focus on sustainable technology transfer into a market that won't accept VW. Tangentially I wanted to (subjectively) quantify the productivity improvement due to Smalltalk relative to another dynamic language (as opposed to Java in Eclipse).
My experience with Ruby is that the language itself is just too much of a hack, and this was especially brought home to me when I started doing Scala and Clojure, and that emphasized for me the beauty of Smalltalk and Lisp/Scheme.
I'm going back to Smalltak for new commercial development, partly because of this, but also because a) the Squeak community is getting a real injection of energy with Cog and Pharo (which itself pushes Squeak) and b) I'm getting a good feeling about the way the Cincom team is changing VW - not only what they're doing, but there seems to be a much clearer vision and approach that when I first encountered it.
I'm also building a commercial application in Scala and Clojure. Both are great languages, especially for highly concurrent apps, and the library support is huge because they seamlessly use Java. If this were the "good old days"(TM) I'm sure someone would be working on decent concurrency support for Smalltalk. Using multiple images is one approach, but not one that I like - it seems (IMHO) to be a reaction to the lack of resources to do something better. Most of the Erlang/ Scala/Clojure goodness could be layered into Smalltalk if someone had the will to do so, but I think Cincom would have to do that for it to get the wide support it would need to have a dependable future.
One benefit that a JVM language has, as opposed to Smalltalk, is that both the underlying performance improves, and the available libraries increase and improve independently of the language. Clojure and Scala don't need effort per se to improve. Oh for a Smalltalk running on the JVM in a high performance manner, with JVM object model integration. I think there is no other way to solve this problem for Smalltalk.
I really miss programming in an image despite the pain of the Object/ Subject problem. I don't think it's *always* more productive than Scala or Clojure (esp for concurrency) but it's more *consistently* productive.
Smalltalk's decline has not been terminal, implementations are improving albeit more slowly than one would like, and as long as it's the right tool for the job then you should use it.
On 18/03/2009, at 8:03 AM, David Finlayson wrote:
Clojure has some great ideas but you need to know Lisp and Emacs.
Both Scala and Clojure have good and improving support in (to varying degrees) IntelliJ, Eclipse, and NetBeans - no Emacs/Slime/VIM required. I use Clojure and Scala in IntelliJ, and I've done so in Eclipse as well.
2. No Smalltalk I've used has a decent GUI. Squeak is an abomination, down the road Pharo may be good, but not today and VW looks like it hasn't been updated since the NT days. Although everyone hates Java cross-platform desktop apps, it is interesting to compare a VW app (say Bottom Feeder) to a Java app of similar design (http://www.rssowl.org/overview). In my opinion the Java version fits in a lot better than the VW version (particularly on the Mac).
For VW, my LinkuisticsUI bundle in the public Store improves the situation somewhat on OSX for VW 7.6. Cincom are also making improvements to the OSX UI for 7.7.
Closure and Scala have Swing integration. Scala has very good SWT bindings. All three IDEs have GUI builders.
Maybe you should consider a Web UI - checkout tools such as Capuccino and efforts like bespin.
Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787
A reasonable man adapts himself to suit his environment. An unreasonable man persists in attempting to adapt his environment to suit himself. Therefore, all progress depends on the unreasonable man. -- George Bernard Shaw
_______________________________________________ vwnc mailing list vwnc@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
2009/3/18 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi all
I found this email really interesting. Especially the concurrent aspects. Clearly some nice research projects in perspective. Also the immutability bit supports would be great.
I hear the magic word 'concurrency' .. :) With green threading model we have a kind of concurrency on a language level.. except that its not scaling on to multiple native threads. There were a lot of discussion around native threading support and everyone agrees that less sharing means less problems.
From this point, running separate object memory per native thread seem most perspective way. Running single object memory on multiple native threads opens a can of worms. And the complexity of VM implementation will be overwhelming.
Stef
Begin forwarded message:
From: Antony Blakey <antony.blakey@internode.on.net> Date: March 18, 2009 2:50:47 AM CEST To: dfinlayson@usgs.gov, VWNC NC <vwnc@cs.uiuc.edu> Subject: Re: [vwnc] Would you start a new Smalltalk project today?
I am a commercial user of VW.
I've recently replaced my VW/GLORP/Postgresql app with one built in Ruby/CouchDB. I moved to Ruby because the documentation/learning material is superior to VW, because of the number of third party components, which is partly an issue of VW not being Open Source, because of tools such as Rails, Sinatra and Merb (which I still prefer over Seaside), and because I needed to focus on sustainable technology transfer into a market that won't accept VW. Tangentially I wanted to (subjectively) quantify the productivity improvement due to Smalltalk relative to another dynamic language (as opposed to Java in Eclipse).
My experience with Ruby is that the language itself is just too much of a hack, and this was especially brought home to me when I started doing Scala and Clojure, and that emphasized for me the beauty of Smalltalk and Lisp/Scheme.
I'm going back to Smalltak for new commercial development, partly because of this, but also because a) the Squeak community is getting a real injection of energy with Cog and Pharo (which itself pushes Squeak) and b) I'm getting a good feeling about the way the Cincom team is changing VW - not only what they're doing, but there seems to be a much clearer vision and approach that when I first encountered it.
I'm also building a commercial application in Scala and Clojure. Both are great languages, especially for highly concurrent apps, and the library support is huge because they seamlessly use Java. If this were the "good old days"(TM) I'm sure someone would be working on decent concurrency support for Smalltalk. Using multiple images is one approach, but not one that I like - it seems (IMHO) to be a reaction to the lack of resources to do something better. Most of the Erlang/ Scala/Clojure goodness could be layered into Smalltalk if someone had the will to do so, but I think Cincom would have to do that for it to get the wide support it would need to have a dependable future.
One benefit that a JVM language has, as opposed to Smalltalk, is that both the underlying performance improves, and the available libraries increase and improve independently of the language. Clojure and Scala don't need effort per se to improve. Oh for a Smalltalk running on the JVM in a high performance manner, with JVM object model integration. I think there is no other way to solve this problem for Smalltalk.
I really miss programming in an image despite the pain of the Object/ Subject problem. I don't think it's *always* more productive than Scala or Clojure (esp for concurrency) but it's more *consistently* productive.
Smalltalk's decline has not been terminal, implementations are improving albeit more slowly than one would like, and as long as it's the right tool for the job then you should use it.
On 18/03/2009, at 8:03 AM, David Finlayson wrote:
Clojure has some great ideas but you need to know Lisp and Emacs.
Both Scala and Clojure have good and improving support in (to varying degrees) IntelliJ, Eclipse, and NetBeans - no Emacs/Slime/VIM required. I use Clojure and Scala in IntelliJ, and I've done so in Eclipse as well.
2. No Smalltalk I've used has a decent GUI. Squeak is an abomination, down the road Pharo may be good, but not today and VW looks like it hasn't been updated since the NT days. Although everyone hates Java cross-platform desktop apps, it is interesting to compare a VW app (say Bottom Feeder) to a Java app of similar design (http://www.rssowl.org/overview). In my opinion the Java version fits in a lot better than the VW version (particularly on the Mac).
For VW, my LinkuisticsUI bundle in the public Store improves the situation somewhat on OSX for VW 7.6. Cincom are also making improvements to the OSX UI for 7.7.
Closure and Scala have Swing integration. Scala has very good SWT bindings. All three IDEs have GUI builders.
Maybe you should consider a Web UI - checkout tools such as Capuccino and efforts like bespin.
Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787
A reasonable man adapts himself to suit his environment. An unreasonable man persists in attempting to adapt his environment to suit himself. Therefore, all progress depends on the unreasonable man. Â -- George Bernard Shaw
_______________________________________________ vwnc mailing list vwnc@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
_______________________________________________ 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.
On 18/03/2009, at 10:46 PM, Igor Stasenko wrote:
I hear the magic word 'concurrency' .. :) With green threading model we have a kind of concurrency on a language level.. except that its not scaling on to multiple native threads.
The Erlang/Scala/Clojure concurrency models are applicable to a green threads model. Concurrency is difficult even with green threads.
There were a lot of discussion around native threading support and everyone agrees that less sharing means less problems.
Which is what such concurrency models provide. I suggest gaining some familiarity with Erlang/Scala/Clojure to protect against Smalltalk- insularity.
From this point, running separate object memory per native thread seem most perspective way.
That ties you to only doing large grained concurrency. What if I want thousands of threads, automatically distributed over the available hardware? Are you assuming that concurrency is limited to the number of running images, and each image is strictly single threaded? Concurrency is useful at many different levels of granularity. Using multiple images requires you to use one method for dealing with per- image concurrency (and currently those mechanisms aren't great) and another when considering multiple threads. And what about the tools to make debugging, profiling, deployment, management etc work over these multi-image systems? That might be more work than just biting the bullet and providing scalable concurrency within the image.
Running single object memory on multiple native threads opens a can of worms. And the complexity of VM implementation will be overwhelming.
Not neccessarily. There may well be legacy issues related to specific VMs and images, but the problem itself is not overwhelming. If it were you wouldn't have the JVM or CLR. This argument is exactly what I meant when I wrote:
If this were the "good old days"(TM) I'm sure someone would be working on decent concurrency support for Smalltalk. Using multiple images is one approach, but not one that I like - it seems (IMHO) to be a reaction to the lack of resources to do something better.
I would prefer to tackle this problem and do something worthy of Smalltalk's oft-proclaimed awesomeness. Instead we pretend that the multi-image model is actually a good and principled decision - but it's not, it's surrender. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away. -- Antoine de Saint-Exupery
2009/3/18 Antony Blakey <antony.blakey@gmail.com>:
On 18/03/2009, at 10:46 PM, Igor Stasenko wrote:
I hear the magic word 'concurrency' .. :) With green threading model we have a kind of concurrency on a language level.. except that its not scaling on to multiple native threads.
The Erlang/Scala/Clojure concurrency models are applicable to a green threads model. Concurrency is difficult even with green threads.
Its not too difficult, i'd say. It is completely different from single threaded approach, so different, that to exploit its benefits you have to deeply rewrite your application(s). And smalltalk is not alone with this problem - many other imperative languages offer nothing in this regard and devs not in a position to get a full grasp of concurrency - they have to reinvent their own wheel first.
There were a lot of discussion around native threading support and everyone agrees that less sharing means less problems.
Which is what such concurrency models provide. I suggest gaining some familiarity with Erlang/Scala/Clojure to protect against Smalltalk- insularity. Yes, i familiar with couple of those. But the problem is, that their employ own concurrency models, which can't be applied directly/blindly to smalltalk. There is always a lot of different nuances who bury the whole idea in the end :)
From this point, running separate object memory per native thread seem most perspective way.
That ties you to only doing large grained concurrency. What if I want thousands of threads, automatically distributed over the available hardware? Are you assuming that concurrency is limited to the number of running images, and each image is strictly single threaded?
In fact you need about 2 * number of cores native threads to have a fully loaded workstation. There is no need to allocate separate native thread for each smalltalk process. All you need is a scheduler which distributing the load between fixed set of native threads.
Concurrency is useful at many different levels of granularity. Using multiple images requires you to use one method for dealing with per- image concurrency (and currently those mechanisms aren't great) and another when considering multiple threads. And what about the tools to make debugging, profiling, deployment, management etc work over these multi-image systems? That might be more work than just biting the bullet and providing scalable concurrency within the image.
You right, but look at bright side: once you implement a remote debugging tool , you can use it for any image located anywhere. And remote debugging is a must for any development environment which claims to be mature one :)
Running single object memory on multiple native threads opens a can of worms. And the complexity of VM implementation will be overwhelming.
Not neccessarily. There may well be legacy issues related to specific VMs and images, but the problem itself is not overwhelming. If it were you wouldn't have the JVM or CLR.
This argument is exactly what I meant when I wrote:
If this were the "good old days"(TM) I'm sure someone would be working on decent concurrency support for Smalltalk. Using multiple images is one approach, but not one that I like - it seems (IMHO) to be a reaction to the lack of resources to do something better.
I would prefer to tackle this problem and do something worthy of Smalltalk's oft-proclaimed awesomeness. Instead we pretend that the multi-image model is actually a good and principled decision - but it's not, it's surrender.
If you familiar with Squeak codebase, there are little applications who tend to care about concurrency. Introducing a native concurrency is pointless without reshaping everything in Squeak from down to up, otherwise you will have no real gains. Having a VM which supports concurrency (GC, foreign calls e.t.c) is about 20% of overall job or less. I don't see how such huge amount of work could be done on a free-time basis. To make it possible, you need a team of dedicated people hired to do the job. So, it is a surrender - but objective one. If someone invest enough money to smalltalk systems it can easily match the JVM/CLR mates.
Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787
In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away. Â -- Antoine de Saint-Exupery
_______________________________________________ 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.
On Thu, Mar 19, 2009 at 1:16 AM, Igor Stasenko <siguctua@gmail.com> wrote:
2009/3/18 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi all
I found this email really interesting. Especially the concurrent aspects. Clearly some nice research projects in perspective. Also the immutability bit supports would be great.
I hear the magic word 'concurrency' .. :) With green threading model we have a kind of concurrency on a language level.. except that its not scaling on to multiple native threads. There were a lot of discussion around native threading support and everyone agrees that less sharing means less problems. From this point, running separate object memory per native thread seem most perspective way. Running single object memory on multiple native threads opens a can of worms. And the complexity of VM implementation will be overwhelming.
If you want to use multiple CPU cores, I believe that ST/X and Gemstone both do this. I haven't tried though. Smalltalk/X: http://www.exept.de/ Gemstone: http://seaside.gemstone.com/ Gulik. -- http://gulik.pbwiki.com/
On Thu, Mar 19, 2009 at 10:02 AM, Michael van der Gulik <mikevdg@gmail.com>wrote:
If you want to use multiple CPU cores, I believe that ST/X and Gemstone both do this. I haven't tried though.
Smalltalk/X: http://www.exept.de/ Gemstone: http://seaside.gemstone.com/
I'm sorry, I lied. Smalltalk/X can *not* use multiple cores. I tried it on a dual-core system; only one core was used :-(. So now it seems that Gemstone is the only multi-core capable Smalltalk VM :-(. Gulik. -- http://gulik.pbwiki.com/
On 20/03/2009, at 1:30 PM, Michael van der Gulik wrote:
So now it seems that Gemstone is the only multi-core capable Smalltalk VM :-(.
And maybe this: http://etoileos.com/ ? Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Plurality is not to be assumed without necessity -- William of Ockham (ca. 1285-1349)
indeed may be we should not have lost our time with squeak and participate to invent really a new smalltalk :) Stef On Mar 20, 2009, at 4:09 AM, Antony Blakey wrote:
On 20/03/2009, at 1:30 PM, Michael van der Gulik wrote:
So now it seems that Gemstone is the only multi-core capable Smalltalk VM :-(.
And maybe this: http://etoileos.com/ ?
Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787
Plurality is not to be assumed without necessity -- William of Ockham (ca. 1285-1349)
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
of course it would be great to be able to have JSmalltalk too. On Mar 20, 2009, at 9:59 AM, Stéphane Ducasse wrote:
indeed may be we should not have lost our time with squeak and participate to invent really a new smalltalk :)
Stef
On Mar 20, 2009, at 4:09 AM, Antony Blakey wrote:
On 20/03/2009, at 1:30 PM, Michael van der Gulik wrote:
So now it seems that Gemstone is the only multi-core capable Smalltalk VM :-(.
And maybe this: http://etoileos.com/ ?
Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787
Plurality is not to be assumed without necessity -- William of Ockham (ca. 1285-1349)
_______________________________________________ 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
Michael van der Gulik wrote:
On Thu, Mar 19, 2009 at 10:02 AM, Michael van der Gulik <mikevdg@gmail.com <mailto:mikevdg@gmail.com>> wrote:
If you want to use multiple CPU cores, I believe that ST/X and Gemstone both do this. I haven't tried though.
Smalltalk/X: http://www.exept.de/ Gemstone: http://seaside.gemstone.com/
I'm sorry, I lied.
Smalltalk/X can /not/ use multiple cores. I tried it on a dual-core system; only one core was used :-(.
So now it seems that Gemstone is the only multi-core capable Smalltalk VM :-(.
AFAIK Gemstone isn't multi-core capable as well. You can just run multiple gems and they share the same persistent memory. Which is similar but different. Philippe
Philippe Marschall pravi:
Michael van der Gulik wrote:
So now it seems that Gemstone is the only multi-core capable Smalltalk VM :-(.
AFAIK Gemstone isn't multi-core capable as well. You can just run multiple gems and they share the same persistent memory. Which is similar but different.
Well, Gemstone can for sure be considered as multi-core capable. Every gem runs on its own process and therefore can run on its own CPU core. All gems then share a Shared Memory Cache. So, a typical multi-core scenario. Best regards Janko -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
On Sat, Mar 21, 2009 at 8:38 AM, Janko Mivšek <janko.mivsek@eranova.si>wrote:
Philippe Marschall pravi:
Michael van der Gulik wrote:
So now it seems that Gemstone is the only multi-core capable Smalltalk VM :-(.
AFAIK Gemstone isn't multi-core capable as well. You can just run multiple gems and they share the same persistent memory. Which is similar but different.
Well, Gemstone can for sure be considered as multi-core capable. Every gem runs on its own process and therefore can run on its own CPU core. All gems then share a Shared Memory Cache. So, a typical multi-core scenario.
By multi-core, I mean that the following code would spread CPU usage over at least two cores of a CPU or computer for a while:
| sum1 sum2 | sum1 := 0. sum2 := 0. [ 1 to: 10000000 do: [ :i | sum1 := sum1 + 1 ] ] fork. [ 1 to: 10000000 do: [ :i | sum2 := sum2 + 1 ] ] fork. (I didn't try the above so there might be obvious bugs) If a VM can't distribute the load for the above over two or more CPU cores, I consider its multi-core capabilities a hack. No offense intended to the Hydra VM. I'm feeling a bit disheartened by the fact that there aren't any Smalltalk VMs, commercial or not, that can do fine-grained parallelism. Gulik. -- http://gulik.pbwiki.com/
Michael van der Gulik wrote:
I'm feeling a bit disheartened by the fact that there aren't any Smalltalk VMs, commercial or not, that can do fine-grained parallelism.
How about Huemul? I think I read it maps Smalltalk Processes onto POSIX threads. And uses Exupery extensively, but that I think is beside the point. regards, Göran
How about Huemul? I think I read it maps Smalltalk Processes onto POSIX threads. And uses Exupery extensively, but that I think is beside the point.
SmalltalkMT seems to be multithreaded: http://www.objectconnect.com/ Lukas -- Lukas Renggli http://www.lukas-renggli.ch
2009/3/22 Michael van der Gulik <mikevdg@gmail.com>:
On Sat, Mar 21, 2009 at 8:38 AM, Janko Mivšek <janko.mivsek@eranova.si> wrote:
Philippe Marschall pravi:
Michael van der Gulik wrote:
So now it seems that Gemstone is the only multi-core capable Smalltalk VM :-(.
AFAIK Gemstone isn't multi-core capable as well. You can just run multiple gems and they share the same persistent memory. Which is similar but different.
Well, Gemstone can for sure be considered as multi-core capable. Every gem runs on its own process and therefore can run on its own CPU core. All gems then share a Shared Memory Cache. So, a typical multi-core scenario.
By multi-core, I mean that the following code would spread CPU usage over at least two cores of a CPU or computer for a while:
| sum1 sum2 |
sum1 := 0. sum2 := 0.
[ 1 to: 10000000 do: [ :i | sum1 := sum1 + 1 ] ] fork.
[ 1 to: 10000000 do: [ :i | sum2 := sum2 + 1 ] ] fork.
(I didn't try the above so there might be obvious bugs)
If a VM can't distribute the load for the above over two or more CPU cores, I consider its multi-core capabilities a hack. No offense intended to the Hydra VM.
Michael, that's would be too ideal to be true, especially for smalltalk. Consider the following: | array sum1 sum2 | sum1 := 0. sum2 := 0. array := Array new: 10. [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ]. This code reveals the following problems: - concurrent access to same object - a heavy memory allocation during running 3 processes, which at some point should cause GC. While first is more or less on the hands of developer (write a proper code to avoid such things), but second is a problem that you need to solve to be able to collect garbage in real time , when there are multiple threads producing it. Another problem, which will force you to rewrite many things in smalltalk code base, is problems with concurrent access to complex collections such as ordered collections, streams & dictionaries: | dict | dict := Dictionary new. [ 10000 timesRepeat: [ dict at: (1000000 random) put: 1 ]] fork. [ 10000 timesRepeat: [ dict at: (1000000 random) put: 1 ]] fork. at some point dictionary would require rehashing, but there are another thread which constantly putting new values in it. Obviously, access to dictionary should be synchronized to avoid conflicts. And synchronized access to collection(s) ( semaphore critical: [] ) makes them really slow, which scales very poorly on multiple cores. The code above will take more time to complete comparing to same code when running in single native thread (green threading model), because you don't have to deal with synchronization.
I'm feeling a bit disheartened by the fact that there aren't any Smalltalk VMs, commercial or not, that can do fine-grained parallelism.
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.
2009/3/22 Igor Stasenko <siguctua@gmail.com>:
2009/3/22 Michael van der Gulik <mikevdg@gmail.com>:
On Sat, Mar 21, 2009 at 8:38 AM, Janko Mivšek <janko.mivsek@eranova.si> wrote:
Philippe Marschall pravi:
Michael van der Gulik wrote:
So now it seems that Gemstone is the only multi-core capable Smalltalk VM :-(.
AFAIK Gemstone isn't multi-core capable as well. You can just run multiple gems and they share the same persistent memory. Which is similar but different.
Well, Gemstone can for sure be considered as multi-core capable. Every gem runs on its own process and therefore can run on its own CPU core. All gems then share a Shared Memory Cache. So, a typical multi-core scenario.
By multi-core, I mean that the following code would spread CPU usage over at least two cores of a CPU or computer for a while:
| sum1 sum2 |
sum1 := 0. sum2 := 0.
[ 1 to: 10000000 do: [ :i | sum1 := sum1 + 1 ] ] fork.
[ 1 to: 10000000 do: [ :i | sum2 := sum2 + 1 ] ] fork.
(I didn't try the above so there might be obvious bugs)
If a VM can't distribute the load for the above over two or more CPU cores, I consider its multi-core capabilities a hack. No offense intended to the Hydra VM.
Michael, that's would be too ideal to be true, especially for smalltalk.
Consider the following:
| array sum1 sum2 |
sum1 := 0. sum2 := 0. array := Array new: 10.
[ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ].
This code reveals the following problems: - concurrent access to same object - a heavy memory allocation during running 3 processes, which at some point should cause GC. While first is more or less on the hands of developer (write a proper code to avoid such things), but second is a problem that you need to solve to be able to collect garbage in real time , when there are multiple threads producing it.
Another problem, which will force you to rewrite many things in smalltalk code base, is problems with concurrent access to complex collections such as ordered collections, streams & dictionaries: | dict | dict := Dictionary new. [ 10000 timesRepeat: [ dict at: (1000000 random) put: 1 ]] fork. [ 10000 timesRepeat: [ dict at: (1000000 random) put: 1 ]] fork.
at some point dictionary would require rehashing, but there are another thread which constantly putting new values in it. Obviously, access to dictionary should be synchronized to avoid conflicts. And synchronized access to collection(s) ( semaphore critical: [] ) makes them really slow, which scales very poorly on multiple cores. The code above will take more time to complete comparing to same code when running in single native thread (green threading model), because you don't have to deal with synchronization.
Sorry, my fault. You need to sync in both cases (even with green threads). But what strikes me, that there are a lot of code, which never cares about it, for instance see Symbol class>> intern: and in some magical fashion it works w/o problems in green threading.. i'm not sure it will continue running when you enable multiple native threads. There is another problem, that squeak processes is cheap (few bytes in object memory), while allocating new native thread consumes considerable amount of memory & address space. So, if you map Processes to native threads, you will lose the ability in having millions of them, instead you will be limited to thousands.
I'm feeling a bit disheartened by the fact that there aren't any Smalltalk VMs, commercial or not, that can do fine-grained parallelism.
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.
-- Best regards, Igor Stasenko AKA sig.
On 22/03/2009, at 9:48 PM, Igor Stasenko wrote:
Sorry, my fault. You need to sync in both cases (even with green threads).
Green threads make some underlying implementation details easier, but at the language level the difference they make is determined by the interleaving guarantees they provide, and the extent to which the user can take advantage of those guarantees e.g. the yield-point model. IMO the solution to concurrency is not to simply add native threads - it also requires a more functional type of programming, and that can be largely provided by immutable data structures and more powerful abstractions, such as those provided in Clojure. I'm not suggesting adding native threads to Squeak. Squeak is quite a minefield as it is. I think it's time for a new model of Smalltalk that includes native threads from the get-go, and is a rethinking of the Smalltalk tradition, in the same way that Clojure is a rethinking of the Lisp tradition. The parallels between Lisp and Smalltalk, in terms of their paradigmatic roles, market issues, and communities, is quite striking. Why should these two powerhouses of beautiful programming not *both* be reborn.
There is another problem, that squeak processes is cheap (few bytes in object memory), while allocating new native thread consumes considerable amount of memory & address space. So, if you map Processes to native threads, you will lose the ability in having millions of them, instead you will be limited to thousands.
You don't need a 1:1 mapping. You can use a native thread pool to execute lightweight threads. Erlang manages with huge numbers of language level processes. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. -- Thomas Jefferson
On Mar 22, 2009, at 12:49 PM, Antony Blakey wrote:
On 22/03/2009, at 9:48 PM, Igor Stasenko wrote:
Sorry, my fault. You need to sync in both cases (even with green threads).
Green threads make some underlying implementation details easier, but at the language level the difference they make is determined by the interleaving guarantees they provide, and the extent to which the user can take advantage of those guarantees e.g. the yield-point model.
IMO the solution to concurrency is not to simply add native threads - it also requires a more functional type of programming, and that can be largely provided by immutable data structures and more powerful abstractions, such as those provided in Clojure.
can you illustrate that point? 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) - I was wondering if the object that you put such immutable data structure should also be immutable
I'm not suggesting adding native threads to Squeak. Squeak is quite a minefield as it is. I think it's time for a new model of Smalltalk that includes native threads from the get-go, and is a rethinking of the Smalltalk tradition, in the same way that Clojure is a rethinking of the Lisp tradition. The parallels between Lisp and Smalltalk, in terms of their paradigmatic roles, market issues, and communities, is quite striking. Why should these two powerhouses of beautiful programming not *both* be reborn.
Can you tell a word on clojure? Stef
There is another problem, that squeak processes is cheap (few bytes in object memory), while allocating new native thread consumes considerable amount of memory & address space. So, if you map Processes to native threads, you will lose the ability in having millions of them, instead you will be limited to thousands.
You don't need a 1:1 mapping. You can use a native thread pool to execute lightweight threads. Erlang manages with huge numbers of language level processes.
Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787
It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. -- Thomas Jefferson
_______________________________________________ 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 12:32 AM, Stéphane Ducasse wrote:
Green threads make some underlying implementation details easier, but at the language level the difference they make is determined by the interleaving guarantees they provide, and the extent to which the user can take advantage of those guarantees e.g. the yield-point model.
IMO the solution to concurrency is not to simply add native threads - it also requires a more functional type of programming, and that can be largely provided by immutable data structures and more powerful abstractions, such as those provided in Clojure.
can you illustrate that point?
Immutable data makes concurrency easier because you avoid concurrent modification and eliminate synchronisation issues. Clojure adds data types with specific concurrency semantics. Here's some exposition: http://clojure.org/concurrent_programming
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.
- 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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 23/03/2009, at 6:51 PM, Stéphane Ducasse wrote:
but do they guarante identity preservation I guess not.
Identity is obviously more important in OO than e.g. functional or function-based programming such as Lisp. This is the sort of thing I had in mind when I said that Smalltalk and immutability are less obviously a good fit than immutability and lisp-like languages such as Clojure. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Nothing is really work unless you would rather be doing something else. -- J. M. Barre
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
2009/3/23 Antony Blakey <antony.blakey@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, Mar 23, 2009 at 12:49 AM, Antony Blakey <antony.blakey@gmail.com>wrote:
On 22/03/2009, at 9:48 PM, Igor Stasenko wrote:
Sorry, my fault. You need to sync in both cases (even with green threads).
Green threads make some underlying implementation details easier, but at the language level the difference they make is determined by the interleaving guarantees they provide, and the extent to which the user can take advantage of those guarantees e.g. the yield-point model.
Anybody who relies on the behaviour of the scheduler deserves to be forced to program in BASIC. Semaphores work; use them.
IMO the solution to concurrency is not to simply add native threads - it also requires a more functional type of programming, and that can be largely provided by immutable data structures and more powerful abstractions, such as those provided in Clojure.
I'm not suggesting adding native threads to Squeak. Squeak is quite a minefield as it is. I think it's time for a new model of Smalltalk that includes native threads from the get-go, and is a rethinking of the Smalltalk tradition, in the same way that Clojure is a rethinking of the Lisp tradition. The parallels between Lisp and Smalltalk, in terms of their paradigmatic roles, market issues, and communities, is quite striking. Why should these two powerhouses of beautiful programming not *both* be reborn.
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.
There is another problem, that squeak processes is cheap (few bytes in object memory), while allocating new native thread consumes considerable amount of memory & address space. So, if you map Processes to native threads, you will lose the ability in having millions of them, instead you will be limited to thousands.
You don't need a 1:1 mapping. You can use a native thread pool to execute lightweight threads. Erlang manages with huge numbers of language level processes.
I agree here. Gulik. -- http://gulik.pbwiki.com/
On 23/03/2009, at 7:37 AM, Michael van der Gulik wrote:
Anybody who relies on the behaviour of the scheduler deserves to be forced to program in BASIC. Semaphores work; use them.
And they work with native threads, which was my point. A more pedantic answer to your response is that you take advantage of the scheduler all the time when considering priorities and atomicity, but I agree with the intent of your statement.
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. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 There is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than the creation of a new order of things... Whenever his enemies have the ability to attack the innovator, they do so with the passion of partisans, while the others defend him sluggishly, So that the innovator and his party alike are vulnerable. -- Niccolo Machiavelli, 1513, The Prince.
Semaphores and Mutexes are the lower level tools. **Critical sections** implemented in terms of blocks are the fantastic part. 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. Bill --- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Antony Blakey Sent: Sunday, March 22, 2009 5:40 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today? On 23/03/2009, at 7:37 AM, Michael van der Gulik wrote:
Anybody who relies on the behaviour of the scheduler deserves to be forced to program in BASIC. Semaphores work; use them.
And they work with native threads, which was my point. A more pedantic answer to your response is that you take advantage of the scheduler all the time when considering priorities and atomicity, but I agree with the intent of your statement.
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. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 There is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than the creation of a new order of things... Whenever his enemies have the ability to attack the innovator, they do so with the passion of partisans, while the others defend him sluggishly, So that the innovator and his party alike are vulnerable. -- Niccolo Machiavelli, 1513, The Prince. _______________________________________________ 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 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
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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Igor Stasenko <siguctua@gmail.com> wrote:
| array sum1 sum2 | sum1 := 0. sum2 := 0. array := Array new: 10. [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ].
Something I came across leately: Threads are evil - http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
On 3/26/09, Markus Fritsche <fritsche.markus@gmx.net> wrote:
Igor Stasenko <siguctua@gmail.com> wrote:
| array sum1 sum2 | sum1 := 0. sum2 := 0. array := Array new: 10. [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ].
Something I came across leately: Threads are evil - http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
They're not evil, just mischievous. I find it a fairly unimpressive article that recites what any decent programmer already knows about parallel programming. "This scenario is bleak for computer vendors: their next generation of machines will become widely known as the ones on which many programs crash." heh. True. Gulik. -- http://gulik.pbwiki.com/
2009/3/25 Michael van der Gulik <mikevdg@gmail.com>:
On 3/26/09, Markus Fritsche <fritsche.markus@gmx.net> wrote:
Igor Stasenko <siguctua@gmail.com> wrote:
| array sum1 sum2 | sum1 := 0. sum2 := 0. array := Array new: 10. [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ].
Something I came across leately: Threads are evil - http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
They're not evil, just mischievous.
I find it a fairly unimpressive article that recites what any decent programmer already knows about parallel programming.
"This scenario is bleak for computer vendors: their next generation of machines will become widely known as the ones on which many programs crash."
heh. True.
hehe -- To offer a third analogy, a folk definition of insanity is to do the same thing over and over again and to expect the results to be different. By this definition, we in fact require that programmers of multithreaded systems be insane. Were they sane, they could not understand their programs. -- a spin loop is very good illustration of it: self locked whileTrue:[ self wait ] :)
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.
To call threaded code incomprehensible is to ignore many appropriate uses of them. The presumption is that software is thrown together and then made to work, rather than engineered to work correctly from the bottom up. Rather than focusing to exclusion on the non-determinism of threading, the author should also consider the independence of the individual threads; threads that do one thing and do it well can be far simpler than code that chops lengthy processes into small chunks that can be executed in sequence. At the risk of sounding prematurely curmudgeonly, I have used both approaches over time (using slicing when threads were not available to me). I would much rather face an over-protected (hence deadlocking) multi-threaded program than try to sort out a single-threaded switch statement from hell that tries to do the same job. Of course, I come at this with a Smalltalk bias, where finding the deadlock is often as simple as following a stack trace to an offending critical section. Dirty writes are a bear in any language, but my general approach is "don't make that mistake." It works for me. Bill --- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael van der Gulik Sent: Wednesday, March 25, 2009 4:39 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk?project today? On 3/26/09, Markus Fritsche <fritsche.markus@gmx.net> wrote:
Igor Stasenko <siguctua@gmail.com> wrote:
| array sum1 sum2 | sum1 := 0. sum2 := 0. array := Array new: 10. [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ].
Something I came across leately: Threads are evil - http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
They're not evil, just mischievous. I find it a fairly unimpressive article that recites what any decent programmer already knows about parallel programming. "This scenario is bleak for computer vendors: their next generation of machines will become widely known as the ones on which many programs crash." heh. True. 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
2009/3/26 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
To call threaded code incomprehensible is to ignore many appropriate uses of them. Â The presumption is that software is thrown together and then made to work, rather than engineered to work correctly from the bottom up. Â Rather than focusing to exclusion on the non-determinism of threading, the author should also consider the independence of the individual threads; threads that do one thing and do it well can be far simpler than code that chops lengthy processes into small chunks that can be executed in sequence.
At the risk of sounding prematurely curmudgeonly, I have used both approaches over time (using slicing when threads were not available to me). Â I would much rather face an over-protected (hence deadlocking) multi-threaded program than try to sort out a single-threaded switch statement from hell that tries to do the same job. Â Of course, I come at this with a Smalltalk bias, where finding the deadlock is often as simple as following a stack trace to an offending critical section. Â Dirty writes are a bear in any language, but my general approach is "don't make that mistake." Â It works for me.
Been there did that.. i especially run to a problem with deadlocking, ended up with coding a classes which enforcing the right order of entering the critical sections i.e. you can't enter the critical section B, if you previously not entered into critical section A. This works, of course, but not an elegant neither scalable.. because it leads to the point where you can simply have a single global critical section to be protected from all contention cases :)
Bill
--- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael van der Gulik Sent: Wednesday, March 25, 2009 4:39 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk?project today?
On 3/26/09, Markus Fritsche <fritsche.markus@gmx.net> wrote:
Igor Stasenko <siguctua@gmail.com> wrote:
| array sum1 sum2 | sum1 := 0. sum2 := 0. array := Array new: 10. [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ].
Something I came across leately: Threads are evil - http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
They're not evil, just mischievous.
I find it a fairly unimpressive article that recites what any decent programmer already knows about parallel programming.
"This scenario is bleak for computer vendors: their next generation of machines will become widely known as the ones on which many programs crash."
heh. True.
Gulik.
_______________________________________________ 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
-- Best regards, Igor Stasenko AKA sig.
Sig, That's an interesting view of it, but I generally see it differently. "Good" threads are independent. They do things that are either truly separate tasks, or work on something lengthy and "report back" when it is finished. Being heavily rooted in engineering mechanics and having become something of an amateur grease monkey (hopefully one who knows his limits), I often visualize threads as gears with the stack pointer as a timing mark near the edge. The critical sections come into play only when the teeth might collide. It is a flawed analogy, but keeps me grounded. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Wednesday, March 25, 2009 7:33 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk?project today? 2009/3/26 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
To call threaded code incomprehensible is to ignore many appropriate uses of them. Â The presumption is that software is thrown together and then made to work, rather than engineered to work correctly from the bottom up. Â Rather than focusing to exclusion on the non-determinism of threading, the author should also consider the independence of the individual threads; threads that do one thing and do it well can be far simpler than code that chops lengthy processes into small chunks that can be executed in sequence.
At the risk of sounding prematurely curmudgeonly, I have used both approaches over time (using slicing when threads were not available to me). Â I would much rather face an over-protected (hence deadlocking) multi-threaded program than try to sort out a single-threaded switch statement from hell that tries to do the same job. Â Of course, I come at this with a Smalltalk bias, where finding the deadlock is often as simple as following a stack trace to an offending critical section. Â Dirty writes are a bear in any language, but my general approach is "don't make that mistake." Â It works for me.
Been there did that.. i especially run to a problem with deadlocking, ended up with coding a classes which enforcing the right order of entering the critical sections i.e. you can't enter the critical section B, if you previously not entered into critical section A. This works, of course, but not an elegant neither scalable.. because it leads to the point where you can simply have a single global critical section to be protected from all contention cases :)
Bill
--- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael van der Gulik Sent: Wednesday, March 25, 2009 4:39 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk?project today?
On 3/26/09, Markus Fritsche <fritsche.markus@gmx.net> wrote:
Igor Stasenko <siguctua@gmail.com> wrote:
| array sum1 sum2 | sum1 := 0. sum2 := 0. array := Array new: 10. [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ].
Something I came across leately: Threads are evil - http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
They're not evil, just mischievous.
I find it a fairly unimpressive article that recites what any decent programmer already knows about parallel programming.
"This scenario is bleak for computer vendors: their next generation of machines will become widely known as the ones on which many programs crash."
heh. True.
Gulik.
_______________________________________________ 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
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, First a general note: various people have contacted me about the format of my email messages. I share your irritation at the illeffects of decisions beyond my control. First they foisted Group(Un)wise on us, and now LookOut! has the job. I could use a different account, but that causes problems of its own. Anyway, the length of this lead me to try a suggestion that came my way recently: ditch Word as LookOut!'s editor. I swear I tried that early on and did away with it due to something not working correctly (surely not); we'll see. Back to our regularly scheduled program... Perhaps just my ignorance showing, I see two problematic sides to concurrency. The first is a big deal: getting an image to use multiple processors. The second involves calls to external libraries, where we need to be able to ensure that Pharo is not brought to its knees by a library that blocks for a long time. A final piece of the puzzle is multiple Process instances, but the troublesome aspects of that (I think) fall into the first two categories. In terms of multiple processors/cores, I have no brilliant answers. Andreas floated an idea that made a lot of sense to me. I do not recall the details, but it struck me as being a lot like having multiple system dictionaries to compartmentalize the object memory, simultaneously providing a natural decomposition of the image for the GC. If his idea is nonsense, he fooled me :) External libraries demand an easy way to use OS threads. Dolphin provides "overlapped calls" that block the calling Process but not the entire image. The usual caveats of thread safety apply, but "any" function can be so marked and will be called on separate OS thread. IIRC, they have enhanced the mechanism to lazily choose an OS thread per Process, and to use the thread for all future overlapped calls on that Process. They started out with a thread pool with no memory, but many libraries have thread affinities that can cause problems in the that case. As an example, OpenSSL stores error information in thread local storage, and one obtains it by a separate function call on the same thread. At the time that I wrote my interface for Dolphin, I ended up making a DLL that put a façade around the various functions of interest (there were only a few) to make the call and then check for error data as one atomic operation. Then Dolphin could changes threads on me at will, and all was fine. That hack might not be necessary in the current and future versions of Dolphin. I should raise one flag about the email you forwarded: I smell a troll. Actually, it might not be a troll so much as someone who has bought into the idea that external components are a panacea. In my experience, there are some external libraries that are extremely helpful, but most are simply trash. The more "cool" the interface technology, the worse the software. Many C-callable libraries seem to do what the advertise; most are incomplete junk. I am sad to report that the vast majority of COM components are buggy non-sense with all manner of undocumented dependencies between the various methods. I will also freely admit that Dolphin's ability to dip into that pool of slime has saved my skin several times. At a minimum, I think we should provide an answer to Dolphin's overlapped calls. The rest can come as inspiration strikes regarding how to do things properly. Bill --- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Wednesday, March 18, 2009 4:17 AM To: Pharo Development Subject: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today? Hi all I found this email really interesting. Especially the concurrent aspects. Clearly some nice research projects in perspective. Also the immutability bit supports would be great. Stef Begin forwarded message:
From: Antony Blakey <antony.blakey@internode.on.net> Date: March 18, 2009 2:50:47 AM CEST To: dfinlayson@usgs.gov, VWNC NC <vwnc@cs.uiuc.edu> Subject: Re: [vwnc] Would you start a new Smalltalk project today?
I am a commercial user of VW.
I've recently replaced my VW/GLORP/Postgresql app with one built in Ruby/CouchDB. I moved to Ruby because the documentation/learning material is superior to VW, because of the number of third party components, which is partly an issue of VW not being Open Source, because of tools such as Rails, Sinatra and Merb (which I still prefer over Seaside), and because I needed to focus on sustainable technology transfer into a market that won't accept VW. Tangentially I wanted to (subjectively) quantify the productivity improvement due to Smalltalk relative to another dynamic language (as opposed to Java in Eclipse).
My experience with Ruby is that the language itself is just too much of a hack, and this was especially brought home to me when I started doing Scala and Clojure, and that emphasized for me the beauty of Smalltalk and Lisp/Scheme.
I'm going back to Smalltak for new commercial development, partly because of this, but also because a) the Squeak community is getting a real injection of energy with Cog and Pharo (which itself pushes Squeak) and b) I'm getting a good feeling about the way the Cincom team is changing VW - not only what they're doing, but there seems to be a much clearer vision and approach that when I first encountered it.
I'm also building a commercial application in Scala and Clojure. Both are great languages, especially for highly concurrent apps, and the library support is huge because they seamlessly use Java. If this were the "good old days"(TM) I'm sure someone would be working on decent concurrency support for Smalltalk. Using multiple images is one approach, but not one that I like - it seems (IMHO) to be a reaction to the lack of resources to do something better. Most of the Erlang/ Scala/Clojure goodness could be layered into Smalltalk if someone had the will to do so, but I think Cincom would have to do that for it to get the wide support it would need to have a dependable future.
One benefit that a JVM language has, as opposed to Smalltalk, is that both the underlying performance improves, and the available libraries increase and improve independently of the language. Clojure and Scala don't need effort per se to improve. Oh for a Smalltalk running on the JVM in a high performance manner, with JVM object model integration. I think there is no other way to solve this problem for Smalltalk.
I really miss programming in an image despite the pain of the Object/ Subject problem. I don't think it's *always* more productive than Scala or Clojure (esp for concurrency) but it's more *consistently* productive.
Smalltalk's decline has not been terminal, implementations are improving albeit more slowly than one would like, and as long as it's the right tool for the job then you should use it.
On 18/03/2009, at 8:03 AM, David Finlayson wrote:
Clojure has some great ideas but you need to know Lisp and Emacs.
Both Scala and Clojure have good and improving support in (to varying degrees) IntelliJ, Eclipse, and NetBeans - no Emacs/Slime/VIM required. I use Clojure and Scala in IntelliJ, and I've done so in Eclipse as well.
2. No Smalltalk I've used has a decent GUI. Squeak is an abomination, down the road Pharo may be good, but not today and VW looks like it hasn't been updated since the NT days. Although everyone hates Java cross-platform desktop apps, it is interesting to compare a VW app (say Bottom Feeder) to a Java app of similar design (http://www.rssowl.org/overview). In my opinion the Java version fits in a lot better than the VW version (particularly on the Mac).
For VW, my LinkuisticsUI bundle in the public Store improves the situation somewhat on OSX for VW 7.6. Cincom are also making improvements to the OSX UI for 7.7.
Closure and Scala have Swing integration. Scala has very good SWT bindings. All three IDEs have GUI builders.
Maybe you should consider a Web UI - checkout tools such as Capuccino and efforts like bespin.
Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787
A reasonable man adapts himself to suit his environment. An unreasonable man persists in attempting to adapt his environment to suit himself. Therefore, all progress depends on the unreasonable man. -- George Bernard Shaw
_______________________________________________ vwnc mailing list vwnc@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 18/03/2009, at 11:43 PM, Schwab,Wilhelm K wrote:
I should raise one flag about the email you forwarded: I smell a troll.
http://linkuistics.com/?page_id=56 http://www.cincomsmalltalk.com/userblogs/antony/blogView
Actually, it might not be a troll so much as someone who has bought into the idea that external components are a panacea. In my experience, there are some external libraries that are extremely helpful, but most are simply trash. The more "cool" the interface technology, the worse the software. Many C-callable libraries seem to do what the advertise; most are incomplete junk. I am sad to report that the vast majority of COM components are buggy non-sense with all manner of undocumented dependencies between the various methods. I will also freely admit that Dolphin's ability to dip into that pool of slime has saved my skin several times.
There are many good Java libraries, which is what I was talking about, but in any case you need to see the email that I was responding to. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Nothing is really work unless you would rather be doing something else. -- J. M. Barre
participants (10)
-
Antony Blakey -
Göran Krampe -
Igor Stasenko -
Janko Mivšek -
Lukas Renggli -
Markus Fritsche -
Michael van der Gulik -
Philippe Marschall -
Schwab,Wilhelm K -
Stéphane Ducasse