Discussion:
[Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today?
(too old to reply)
Stéphane Ducasse
2009-03-18 09:17:02 UTC
Permalink
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
From: Antony Blakey <antony.blakey at internode.on.net>
Date: March 18, 2009 2:50:47 AM CEST
To: dfinlayson at usgs.gov, VWNC NC <vwnc at 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.
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 at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Igor Stasenko
2009-03-18 12:16:54 UTC
Permalink
Post by Stéphane Ducasse
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.
Post by Stéphane Ducasse
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.
Post by Stéphane Ducasse
Stef
From: Antony Blakey <antony.blakey at internode.on.net>
Date: March 18, 2009 2:50:47 AM CEST
To: dfinlayson at usgs.gov, VWNC NC <vwnc at 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.
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 at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
Best regards,
Igor Stasenko AKA sig.
Antony Blakey
2009-03-18 12:52:41 UTC
Permalink
Post by Igor Stasenko
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.
Post by Igor Stasenko
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.
Post by Igor Stasenko
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.
Post by Igor Stasenko
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.
Post by Igor Stasenko
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
Igor Stasenko
2009-03-18 20:02:01 UTC
Permalink
Post by Antony Blakey
Post by Igor Stasenko
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.
Post by Antony Blakey
Post by Igor Stasenko
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 :)
Post by Antony Blakey
Post by Igor Stasenko
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.
Post by Antony Blakey
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 :)
Post by Antony Blakey
Post by Igor Stasenko
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.
Post by Igor Stasenko
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.
Post by Antony Blakey
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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
Best regards,
Igor Stasenko AKA sig.
Michael van der Gulik
2009-03-18 21:02:51 UTC
Permalink
Post by Igor Stasenko
Post by Stéphane Ducasse
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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090319/b791936d/attachment.html>
Michael van der Gulik
2009-03-20 03:00:33 UTC
Permalink
On Thu, Mar 19, 2009 at 10:02 AM, Michael van der Gulik
Post by Michael van der Gulik
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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090320/813a497a/attachment.html>
Antony Blakey
2009-03-20 03:09:24 UTC
Permalink
Post by Michael van der Gulik
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)
Stéphane Ducasse
2009-03-20 08:59:10 UTC
Permalink
indeed may be we should not have lost our time with squeak and
participate to invent
really a new smalltalk :)

Stef
Post by Antony Blakey
Post by Michael van der Gulik
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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse
2009-03-20 09:26:25 UTC
Permalink
of course it would be great to be able to have JSmalltalk too.
Post by Stéphane Ducasse
indeed may be we should not have lost our time with squeak and
participate to invent
really a new smalltalk :)
Stef
Post by Antony Blakey
Post by Michael van der Gulik
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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Philippe Marschall
2009-03-20 18:34:57 UTC
Permalink
Post by Michael van der Gulik
On Thu, Mar 19, 2009 at 10:02 AM, Michael van der Gulik
<mikevdg at gmail.com
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
Janko Mivšek
2009-03-20 19:38:12 UTC
Permalink
Post by Philippe Marschall
Post by Michael van der Gulik
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
Michael van der Gulik
2009-03-22 02:10:58 UTC
Permalink
Post by Janko Mivšek
Post by Philippe Marschall
Post by Michael van der Gulik
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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090322/bb24b443/attachment.html>
Göran Krampe
2009-03-22 07:30:19 UTC
Permalink
Post by Michael van der Gulik
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
Lukas Renggli
2009-03-22 08:03:13 UTC
Permalink
Post by Göran Krampe
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
Igor Stasenko
2009-03-22 11:00:51 UTC
Permalink
On Sat, Mar 21, 2009 at 8:38 AM, Janko Miv?ek <janko.mivsek at eranova.si>
Post by Janko Mivšek
Post by Philippe Marschall
Post by Michael van der Gulik
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
| 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.
--
http://gulik.pbwiki.com/
_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
Best regards,
Igor Stasenko AKA sig.
Igor Stasenko
2009-03-22 11:18:21 UTC
Permalink
Post by Igor Stasenko
On Sat, Mar 21, 2009 at 8:38 AM, Janko Miv?ek <janko.mivsek at eranova.si>
Post by Janko Mivšek
Post by Philippe Marschall
Post by Michael van der Gulik
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
| 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.
| 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) ].
- 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
| 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.
Post by Igor Stasenko
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/
_______________________________________________
Pharo-project mailing list
Pharo-project at 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.
Antony Blakey
2009-03-22 11:49:43 UTC
Permalink
Post by Igor Stasenko
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.
Post by Igor Stasenko
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
Stéphane Ducasse
2009-03-22 14:02:56 UTC
Permalink
Post by Antony Blakey
Post by Igor Stasenko
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
Post by Antony Blakey
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
Post by Antony Blakey
Post by Igor Stasenko
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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Antony Blakey
2009-03-22 22:35:07 UTC
Permalink
Post by Stéphane Ducasse
Post by Antony Blakey
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
Post by Stéphane Ducasse
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.
Post by Stéphane Ducasse
- 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
Stéphane Ducasse
2009-03-23 08:21:17 UTC
Permalink
Post by Antony Blakey
Here's some exposition: http://clojure.org/concurrent_programming
I will reread it then
Post by Antony Blakey
Post by Stéphane Ducasse
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.
Post by Antony Blakey
Post by Stéphane Ducasse
- 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Antony Blakey
2009-03-23 09:07:50 UTC
Permalink
Post by Stéphane Ducasse
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
Antony Blakey
2009-03-22 23:15:11 UTC
Permalink
Post by Stéphane Ducasse
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
Igor Stasenko
2009-03-23 00:03:59 UTC
Permalink
Post by Antony Blakey
Post by Stéphane Ducasse
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. :)
Post by Antony Blakey
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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
Best regards,
Igor Stasenko AKA sig.
Stéphane Ducasse
2009-03-23 08:28:46 UTC
Permalink
I had the impression that this was the direction newspeak was going.
Post by Antony Blakey
Post by Stéphane Ducasse
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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Michael van der Gulik
2009-03-22 21:07:24 UTC
Permalink
Post by Antony Blakey
Post by Igor Stasenko
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.
Post by Antony Blakey
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.
Post by Antony Blakey
Post by Igor Stasenko
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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090323/65bf6a72/attachment.html>
Antony Blakey
2009-03-22 22:39:42 UTC
Permalink
Post by Michael van der Gulik
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.
Post by Michael van der Gulik
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.
Schwab,Wilhelm K
2009-03-22 23:06:39 UTC
Permalink
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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Antony Blakey
Sent: Sunday, March 22, 2009 5:40 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today?
Post by Michael van der Gulik
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.
Post by Michael van der Gulik
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.
Antony Blakey
2009-03-22 23:13:57 UTC
Permalink
Post by Schwab,Wilhelm K
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.
Post by Schwab,Wilhelm K
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
Schwab,Wilhelm K
2009-03-23 00:48:45 UTC
Permalink
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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Antony Blakey
Sent: Sunday, March 22, 2009 6:14 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today?
Post by Schwab,Wilhelm K
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.
Post by Schwab,Wilhelm K
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
Markus Fritsche
2009-03-25 21:12:19 UTC
Permalink
Post by Igor Stasenko
| 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
Michael van der Gulik
2009-03-25 21:39:22 UTC
Permalink
Post by Markus Fritsche
Post by Igor Stasenko
| 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/
Igor Stasenko
2009-03-25 23:02:42 UTC
Permalink
Post by Michael van der Gulik
Post by Markus Fritsche
Post by Igor Stasenko
| 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 ]
:)
Post by Michael van der Gulik
Gulik.
--
http://gulik.pbwiki.com/
_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
Best regards,
Igor Stasenko AKA sig.
Schwab,Wilhelm K
2009-03-25 23:03:42 UTC
Permalink
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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Michael van der Gulik
Sent: Wednesday, March 25, 2009 4:39 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk?project today?
Post by Markus Fritsche
Post by Igor Stasenko
| 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/
Igor Stasenko
2009-03-26 00:32:45 UTC
Permalink
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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Michael van der Gulik
Sent: Wednesday, March 25, 2009 4:39 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk?project today?
Post by Markus Fritsche
Post by Igor Stasenko
| 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
Best regards,
Igor Stasenko AKA sig.
Schwab,Wilhelm K
2009-03-26 14:21:34 UTC
Permalink
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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Igor Stasenko
Sent: Wednesday, March 25, 2009 7:33 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk?project today?
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 at lists.gforge.inria.fr
[mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of
Michael van der Gulik
Sent: Wednesday, March 25, 2009 4:39 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk?project today?
Post by Markus Fritsche
Post by Igor Stasenko
| 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
Best regards,
Igor Stasenko AKA sig.

Schwab,Wilhelm K
2009-03-18 13:13:15 UTC
Permalink
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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at 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
From: Antony Blakey <antony.blakey at internode.on.net>
Date: March 18, 2009 2:50:47 AM CEST
To: dfinlayson at usgs.gov, VWNC NC <vwnc at 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.
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 at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Antony Blakey
2009-03-18 13:30:31 UTC
Permalink
Post by Schwab,Wilhelm K
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
Post by Schwab,Wilhelm K
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
Dale Henrichs
2009-03-18 21:44:19 UTC
Permalink
----- "Michael van der Gulik" <mikevdg at 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/
|
| Gulik.

GemStone allows you to spread the work across multiple machines as well as multiple cores on a single machine.

State is shared on transaction boundaries, which has its advantages and disadvantages...

Dale
Continue reading on narkive:
Loading...