Leveraging Multicore CPU's
Leveraging Multicore CPU's
High on many developer's and development manager's minds
these days is being able to utilize multicore CPU's that have become ubiquitous
in today's computers.
It comes down to concurrency - a challenge that computer
science has been grappling with for decades with limited and modest
success. An "easy" way to get
concurrency on modern hardware is to run multiple applications, in which the
operating system will generally assign each to a different core. But to address our problems with concurrency
then requires us to break our problems into multiple cooperating applications,
or to facilitate using more traditional concurrency mechanisms within a single
app, providing it can multithread.
Regardless, either approach requires thinking, planning and changes in
how we address the problem we are trying to solve. Most languages and
applications require upfront planning for concurrency to achieve it, or rework
and rearrangement of existing applications.
I have experienced traditional mechanisms for
concurrency, both back in grad school, teaching use of them in VisualWorks advanced
courses back in the 90's, and some application development. VisualWorks has green threads - non native Smalltalk
processes, essentially for simulated concurrency - think of time sharing of the
CPU by these processes. Some mechanisms
available in VisualWorks are semaphores, processes, promises (a kind of "future")
and sharedQueue.
Working with concurrency, you quickly learn two things: first, just as in Smalltalk and in developing
applications, keeping things simple is a big advantage. Keeping things simple like using a
sharedQueue and producer/consumer processes is an understandable and intuitive
model that can help simplify the approach.
The second thing is that as the power of using concurrency grows
linearly, the difficulty grows exponentially.
Very non-obvious and difficult to diagnose bugs can arise even in
relatively simple applications. (I'm talking about concurrency in general - the
simplicity of Smalltalk is an advantage with these complexities).
So, given that preamble, what can we do that will provide
developers something of value for leveraging multicore?
First it may be that we provide multiple things that address
this over time, but from an initial and
product management point of view, I would like to provide developers
·
Something "Smalltalk simple"
A simple mechanism that is simple, effective, and
high level
·
Avoids most of the traditional problems and
difficulties if possible
Minimize contention, locking, ability to deadlock
·
Is flexible enough to be the basis for more
sophisticated solutions as situations warrant
So basically I'm shooting for maximum gain with minimum
pain.
We have something basic working internally as an experiment
now at Cincom. A couple of engineers
did some work out of pure interest (hats off to those individual, thanks!) and
put this together so that we have a basis for experimentation and discussion.
As the points note, I hope that this will be the basis for
something simple, effective and easy to use when a simple solution is needed,
but is flexible enough to be the basis for more sophisticated solutions, as
situations warrant.
We will see .... Exciting times ahead!
- Arden
Comments
two gorillas walk into a bar -concurrently
[] November 5, 2008 2:56:03.729
there are two 800 pound gorilla's knocking at the vm door
both gorillas have had enormous resources poured into making them multi-threaded
both gorillas have finally woken up to dynamic languages
-neither are magic solutions to the multicore problem by any means, and invokedynamic does not necessarily a smalltalk capable vm make -but in my ignorance, i struggle to see how any of the existing smalltalks will be able to utilise multicores as effectively as a smalltalk on a dynamic language friendly CLR/DLR or JVM
perhaps something purpose built for concurrent smalltalk (a la erlang's beam) would cut it -but i don't think that qualifies as "minimum pain".
as a foolish, non smalltalker, who wasn't there -it is very easy for me to say "object studio jumped the wrong way" -but i do say it, and multicore is another reason to say it
i figure that a cincom smalltalk on the jvm or dlr would not cannibalise the visualworks business, could break a new market for smalltalk, could be done cheaply (as it would not have to be a substitute for visualworks), but is the only realistic way to get serious about concurrency
Re: Leveraging Multicore CPU's
[ James Robertson] November 5, 2008 6:57:50.914
Comment by James Robertson
Cincom Smalltalk on either would be 30% to 50% slower. That's not the way to "get serious", IMHO.
so divide by 2 then multiple by 4 cores -"seriously"
[Pete F] November 6, 2008 6:58:55.364
1. or by 16 cores, or 32...
2. 50% is good enough for me, but if that figure comes from the testing you initially did, it probably can't be compared with what DLR can already do, and what Java 7 will do
3. ..and they are just going to get faster -they won't stop coming (like the terminator)
[ramble on]
4. but maybe 50% of visualworks performance is too fast -i imagine you would want to offer an upgrade path from a .net or jvm smalltalk to "the real thing"
5. it seems to me that you could re-use your libraries, and provide a smalltalk on both vm's *that didn't use (or didn't surface) the java/.net frameworks* -such a thing would thus be platform independent (ok, you might leave the gui, platform specific -or do a hopscotch over it)
6. so you would have three platforms, jvm, clr -and, of course, visualworks. And which one of those would be your development environment? (duh -the one you don't have to write)
7. and you would still have something to sell (because you aren't throwing away all the cincom content of the product) . You would be in different (but complimentary) market to VW.
8. and if you really want speed -take Dave Thomas's advice and hide away those poor turtles at the bottom. Having done so, provide a native implementation for them (heresey i know -but i am a fool who doesn't know better)
Having questioned it, the nice thing about the direction you took with ObjectStudio, is that your clr/jvm implementation *can start quite crappy* (maybe just as a silverlight client for webvelocity)
so what are you waiting for?
(while you are at it -can we have it running newspeak too)
Pete F
Re: Leveraging Multicore CPU's
[ James Robertson] November 6, 2008 8:39:11.259
Comment by James Robertson
There are fairly large scale issues with this approach. Leaving performance aside (and dynamic performance on both does suck) - there's the library issue. Java and .NET have their own libraries for things like WS*, network connectivity, etc, etc. So does Cincom Smalltalk. A rational port would remove our libraries, map to the underlying ones, and build some level of compatibility sugar. That's not a small job - and at the end of the day, it gives Cincom very little value to sell.