Questions on Squeak's threading architecture -- why can't Squeak
do SMP yet?
Ed Boyce
edboyce at bu.edu
Wed Aug 4 12:43:53 UTC 2004
/delurk
Hi Squeak devs:
I have a few questions about Squeak VM architecture, and I
apologize for the newbie sounding nature of some of them; I have spent a
fair amount of time browsing the Swiki and the System Browser, and tried
searching the dev list with google, only to find small snippets relating
to my questions about multithreading in the VM. My motivation has to do
with wanting to share physical simulations and visualizations over
distributed hardware with Croquet when available, but my questions about
scalability seem to be more Squeak VM related.
What is stopping Squeak from doing SMP? (or Async MP for that matter?)
The Squeak VM classes seem to be pretty finely threaded, and
increasingly modularized. I understand some of the potential risks to
stability when you tell a computer try to walk and chew gum at the same
time, but some threads (and processes for that matter) should be
parallizable when they have no data interdependencies. Why can't one
make a copy of the OS/platform specific guts of the Squeak bytecode
interpreter or JIT compiler object for each physical processor (maybe
make it live in the processor cache since it isn't THAT big) and have
the scheduler serve threads (or whole processes if they're independent
enough) to available processors using a priority scheme of one's choice
(which, this being Squeak, should be able to be changed out or altered
on the fly if available hardware or loads change during execution).
Of course, locks are necessary around structures whose shared
memory components may be in flux when another object tries to
interrogate it. But Squeak's message-passed requests are more polite
than conventional function calls to object methods, and this can
facilitate a more polite "be with you in a few microseconds" response if
something is locked than a simple fail. Of course, not all classes and
methods and SqueakVM threads are suitable for forking into OS and
processor threads. Those that are or aren't can be tagged with one bit
(maybe call it "isSMPThreadable").
Has this been tried and failed? Another question: Has anyone tried
to port Squeak to IBM Power5 processors (under Linux or anything else)?
What are the broad engineering challenges in the way if I want to run a
computationally intensive simulation object (e.g. large N molecular
dynamics simulation with Squeak object hooks) on, say 32 processors of
my IBM p690, and let that object communicate the jist of its state (by
passing messages over IP) to clients which do the final (not so
computationally intensive) final rendering. I know that the
client-server bit is exactly what the Croquet team is working on. But
one can't involve high performance computing in the mix if threads can't
be distributed over multi processors. And that part seems to rest with
the Squeak VM architecture. (Please point out any misconceptions in any
of the above).
Anyone who has used a pervasively threaded microkernel operating
system, such as BeOS and QNX, understands the substantial power for
users and their programs of multithreading on multiprocessors done
right. There are clearly lots of parallels to be drawn here between
Squeak and various OS architectures.
I have more questions, but that is a start. Thank you in advance to
anyone who can shed light on these topics and/or point me to some
definitive reading on them.
Best Regards,
Ed Boyce
---------------------------------------------------
Ed Boyce
Boston University Center for Computational Science
EOT-PACI Program -- http://www.eot.org
(413) 245-3997
edboyce at bu.edu
More information about the Squeak-dev
mailing list
|