[ANN] Hydra VM (multithreaded squeak VM) showing first results

Hello everyone,
i would like to make anyone know, what i have done during December in
a collaboration with Andreas, for creating a VM, which can run
multiple squeak images in separate native threads, running in
parallel.

Hydra VM is codename, which we have choose to call this project :)

Currently, i had refactored enough code in Interpreter/Plugins and
win32 platform-specific code to be able to load and run multiple
images in same process.

There is much to be done left, but i think, at the moment, there is
enough support in VM to write tests and experiment, without much risk
of crashes.
If you run single image, and don't start second or more, it's stable!
(i'm sitting in VM, editing code during the day, saving image e.t.c. -
about 8 hours or so, and no crashes ).
Of course, expect crashes, when you run new image. :)
But there is nuances: since i'm too lazy to look for a stripped down
image with limited number of facilities, i'm using stock image to run
in second thread.
Of course, this is very risky , because it's trying to use everything
(display/input) and this leads to crash.
So, currently, to prevent that, i changed
snapshot:andQuit:embedded: method to simply don't go past tests, which
are running at starting image (there is a ways to detect if you
running as main interpreter or not).

I'm going to make further changes to ensure, that VM will not crash,
even when trying to run stock images which may think that they are
interactive.
Meanwhile, to one, who might have interest, you can download and start
playing with it.
Sorry, it's currently running on win32 platform only.
If there any interest in porting to other platforms i would glad to help.

Lately, i have done implementing channels , a framework for fast and
cheap inter-image communication.
If you load a HydraVM package, there is already some code, which using them:

#transcript channel, used by HydraTranscript class , as a simple way
to see what other image doing, by redirecting all transcript output to
main, interactive, image.

#doIt channel - a channel, which listen non-interactive image, where
you can send doits.

You can download VMMaker and HydraVM from here:
MCHttpRepository
        location: 'http://jabberwocky.croquetproject.org:8889/HydraVM'
        user: ''
        password: ''

And platform source code, for building it, from here:
http://squeakvm.org/svn/squeak/branches/qwaq

Any questions? ask away!

--
Best regards,
Igor Stasenko AKA sig.

On Mon, Dec 24, 2007 at 11:24:47PM +0200, Igor Stasenko wrote:
> Hello everyone,
> i would like to make anyone know, what i have done during December in
> a collaboration with Andreas, for creating a VM, which can run
> multiple squeak images in separate native threads, running in
> parallel.
>
> Hydra VM is codename, which we have choose to call this project :)

This sounds very interesting indeed. What a nice follow up to all the
earlier discussions on this topic, a real implementation! Well done.

Excellent name too.

Dave

On 25/12/2007, David T. Lewis <[hidden email]> wrote: There is more and more pressing matters, because we are standing at
rising multi-core era. So, we need tools for fully utilizing their
powers.

> Excellent name too.
>
> Dave
>


--
Best regards,
Igor Stasenko AKA sig.

--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

On 25/12/2007, Michael van der Gulik <[hidden email]> wrote:
Good question. Communication within same process can be as fast as
reading memory.
And, of course without being too dependent from OS (shared memory,
pipes or TCP/IP).
Another is, that it's certainly much simpler to manage multiple images
within single process boundaries than manage multiple OS processes.
Next reason, that some external resources can require an exclusive
access , and writing plugin which can manage it for multiple images in
single OS process is much easier than writing a plugin which try
manage access for multiple OS processes.

So, in short: main difference is, that multiple OS processes share
nothing and can communicate only using provided OS facilities.
In Hydra VM you still sharing nothing between images, but different
VM/plugins/OS states are now shareable.


--
Best regards,
Igor Stasenko AKA sig.

Hi Igor,

on Mon, 24 Dec 2007 22:24:47 +0100, you wrote:

> Hello everyone,
> i would like to make anyone know, what i have done during December in
> a collaboration with Andreas, for creating a VM, which can run
> multiple squeak images in separate native threads, running in
> parallel.
>
> Hydra VM is codename, which we have choose to call this project :)

Wow, what a project, what a name :-D

> There is much to be done left, but i think, at the moment, there is
> enough support in VM to write tests and experiment, without much risk
> of crashes.
...
>
> Any questions? ask away!

How about passing a socket's handle to one of the serpent's heads. See  
(aSocket socketHandle) in #acceptFrom: of Socket.

That looks easy doable, (aSocket socketHandle) could be passed as a  
constant bytearray, similiar to sending something to the #transcript or  
#doIt channel, and the result of #acceptFrom: is totally controlled on the  
serpent head's side.

Can you see any problem with this, OS-wise or other? If not I could give  
it a try.

/Klaus

On 25/12/2007, Klaus D. Witzel <[hidden email]> wrote:
Sockets are managed by socket plugin and keep own, private separate
list for each interpreter instance.
You may pass it, but if you try use it with other interpreter, which
creates it, all primitives will fail.
This can be changed however, i see good reasons why socket handles can
be passed between images.

>
> /Klaus
>


--
Best regards,
Igor Stasenko AKA sig.

On 25/12/2007, Igor Stasenko <[hidden email]> wrote:

> Sockets are managed by socket plugin and keep own, private separate
> list for each interpreter instance.
> You may pass it, but if you try use it with other interpreter, which
> creates it, all primitives will fail.
> This can be changed however, i see good reasons why socket handles can
> be passed between images.
>

On second thought, i say no. There is many concurrency issues arising,
when two (or more) independent interpreters trying to work with same
socket handle.
Of course OS sockets are thread safe, but structures, assigned to them
for serving ST side, like semaphores, mutexes and different state vars
are unique and should be accessed synchronously.

However, its very easy to write few additional primitives which tell
socket to redirect all incoming data to specified channel, and also
make socket to behave like a channel which listens for data.

Since sockets (at least in windows) using own thread, there is no real
difference, where to pass data - in channel or to some buffer. And
speed degradation should be minimal (if it will be at all).

Also, erasing differences between channels and sockets having many
benefits - common interface, simple use.
Currently channel features is not very mature, and i'm already don't
like some of their current functionality.
I thought it was a good idea to have named channels. It's much more
convenient for developer to use names instead of port numbers to
identify them. But channel discovery mechanism needs more thought.
well, this is only preliminary design and use cases will show us what
need to be changed.

There are already some variants, which i would like to see for
channels: like using staticaly allocated buffer queue, so writing to
channel will not require memory allocation for buffer and freeing it
upon receipt.
Also, its possible to pull data from channel in 'hot' manner - without
waiting semaphore. So,  for heavy data throughput tasks or for a fast,
realtime reacting on events, you can create at process which will
constantly pulling data from channel without waiting on semaphore.


--
Best regards,
Igor Stasenko AKA sig.

>>
> There is more and more pressing matters, because we are standing at
> rising multi-core era. So, we need tools for fully utilizing their
> powers.

yes!
So what would be a typical set up of multiple images from your  
perspective?

Stef

If someone could email me (not the list)  their src32 VMMaker results  
for Hydra that would be appreciated.

On Dec 25, 2007, at 8:26 AM, stephane ducasse wrote:

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

Hmm.. a frustrating results:

1 tinyBenchmarks

- VM built with gcc-2.95.2

 '178025034 bytecodes/sec; 5308098 sends/sec'
 '174268209 bytecodes/sec; 5502853 sends/sec'

- VM built with latest gcc, available from mingw binaries  gcc 3.4.2
(mingw-special)

'99843993 bytecodes/sec; 4512903 sends/sec'
'101105845 bytecodes/sec; 4512903 sends/sec'

Interesting, that it feels more responsive when built with 3.4.2 :)

-----
P.S. To ones, who might want try to build Hydra VM. Here the list of
plugins which known to be able to build with:

ADPCMCodecPlugin B3DAcceleratorPlugin B2DPlugin BitBltPlugin
BMPReadWriterPlugin ZipPlugin DropPlugin DSAPrims FFTPlugin FilePlugin
FloatArrayPlugin FloatMathPlugin GeniePlugin HostWindowPlugin
JoystickTabletPlugin JPEGReaderPlugin JPEGReadWriter2Plugin Klatt
LargeIntegers LocalePlugin Matrix2x3Plugin MiscPrimitivePlugin
Mpeg3Plugin RePlugin SecurityPlugin SocketPlugin StarSqueakPlugin
SurfacePlugin UUIDPlugin

- external
SqueakFFIPrims

--
Best regards,
Igor Stasenko AKA sig.

On 25/12/2007, stephane ducasse <[hidden email]> wrote:
> >>
> > There is more and more pressing matters, because we are standing at
> > rising multi-core era. So, we need tools for fully utilizing their
> > powers.
>
> yes!
> So what would be a typical set up of multiple images from your
> perspective?
>
There can be a wide range of deployment models, depending on intents.
As i said, its a general purpose VM, and therefore things you can do
with it depends on your imagination :)

For Seasiders, there now a good perspectives to have a single 'main'
image, which accepts incoming connections, and do load-balancing
between smaller images which do all dirty work.
You could have much finer control on things comparing to running
multiple squeak processes.

I think, that Andreas having own ideas how to use new VM, and i think
it's better ask him to describe where it will be used.

But things are more or less the same: distribute the tasks between
multiple images, making them performing in parallel.

--
Best regards,
Igor Stasenko AKA sig.

2007/12/26, Igor Stasenko <[hidden email]>:
How would that work? How would you pass a request to a different
image? How would it return the response? How would you keep the images
in sync (deploy code to all the images)? I still feel that for Seaside
one Image with multiple native threads would be the best option.

Cheers
Philippe

On 26/12/2007, Philippe Marschall <[hidden email]> wrote:
> >
> > For Seasiders, there now a good perspectives to have a single 'main'
> > image, which accepts incoming connections, and do load-balancing
> > between smaller images which do all dirty work.
>
> How would that work? How would you pass a request to a different
> image? How would it return the response? How would you keep the images
> in sync (deploy code to all the images)?

See, Hydra VM is just VM it's not a smallatlk application (such as
Seaside). And of course, to resolve all of the above there a lot to do
and think of.

> I still feel that for Seaside
> one Image with multiple native threads would be the best option.
>

If you talking about making single image be able to run using multiple
native threads.. oh..
There was a lot of discussions around that. And i think, that my
attempt to introduce multithreading into VM at least on a per-image
basis is a step forward to it.


--
Best regards,
Igor Stasenko AKA sig.

Igor Stasenko ha scritto:
Two possible solutions:

- have a common protocol for Channel and Socket operations, so that Kom
may listen either on the former or on the latter without changing any code.

- use a Kom variant that knows it's a "slave" process in one of the load
balanced images. In this case, it could use channels to receive
HttpRequest objects from and return HttpResponse objects to the load
balancing image.

        Giovanni

PS. Great work, Igor (and Andreas, too)!

On 26/12/2007, Giovanni Corriga <[hidden email]> wrote:
I think, the latter is more appropriate, because channels don't have
'listen/accept' semantics. Once channel is created, it starts
listening for incoming data, not connections.
But this can be easily changed by introducing a framework on top of
that. For instance, you can create a channel which will listen for
'connections', and then upon request, it creates new channel and
sending it's name/id in response which will be used to receive
incoming data.

>         Giovanni
>
> PS. Great work, Igor (and Andreas, too)!
>
>
>

--
Best regards,
Igor Stasenko AKA sig.