Multi-Image Sista VM?
Locked
 
|
I have not read about this anywhere I can remember. Would it be possible to run two images on one VM? Robertotini Sent from ProtonMail Mobile |
|
|
The Hydra VM from Igor was doing exactly that. The Actor model in Newspeak is also somewhat similar to that, though part of the image is shared between threads. Not sure what is the status of these projects though. On Wed, Apr 29, 2020 at 8:43 PM Robert <[hidden email]> wrote:
|
|
|
> On 2020-05-01, at 11:59 AM, Clément Béra <[hidden email]> wrote: > > The Hydra VM from Igor was doing exactly that. > > The Actor model in Newspeak is also somewhat similar to that, though part of the image is shared between threads. I'm not sure what benefit is anticipated by running multiple images on one vm. The VM executable is not terribly big, so you don't save a great deal of memory and any sensible OS is likely to be able to share the static code pages at least. For a Cog VM quite a lot of space for the caches and translated code needs to be per-image, so you wouldn't save there. A VW-like permspace that is treated as read-only can also be shared of course. So what would the advantages be? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Design simplicity: It was developed on a shoe-string budget. |
|
|
In reply to this post by Clément Béra
On 5/1/20 2:59 PM, Clément Béra wrote:
Stellar! Could we reintegrate with the latest squeak.cog.spur?
I believe the Newspeak Actors are implemented with local capabilities, from ELib, just as my CapabilitiesLocal package. DoIt:
works. Both implement a ELib Promise system with async resolution and resolved promise reactor invocation. Would you be able to say a few words about their use of shared
memory, please? As well, what could you mention about their use of
promises, regarding Ease of use, understandable code, tips &
tricks with promises? K, r
-- Kindly, Robert |
|
|
In reply to this post by timrowledge
Hi ya, Tim, I had to mull this over a little. In my use case, I believe that each core is running its own event loop inside its own memory. Objects are not shared. Yet, there is a use case to migrate objects to different event loops. Doing so efficiently may provide an opportunity to do heuristics with performance and tune the threads within 1 process. I think it opens another dimension in performance optimization that would allow some sort of JIT compiler moving actors around. A) Actor Mobility. Plus it would be B) totally cool!!! I mean completely! + 1,000 coolness factor. Your thoughts? K, r On 5/1/20 5:32 PM, tim Rowledge wrote: > > > >> On 2020-05-01, at 11:59 AM, Clément Béra <[hidden email]> wrote: >> >> The Hydra VM from Igor was doing exactly that. >> >> The Actor model in Newspeak is also somewhat similar to that, though part of the image is shared between threads. > I'm not sure what benefit is anticipated by running multiple images on one vm. > > The VM executable is not terribly big, so you don't save a great deal of memory and any sensible OS is likely to be able to share the static code pages at least. For a Cog VM quite a lot of space for the caches and translated code needs to be per-image, so you wouldn't save there. > > A VW-like permspace that is treated as read-only can also be shared of course. > > So what would the advantages be? > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Design simplicity: It was developed on a shoe-string budget. > > Kindly, Robert |
|
|
In reply to this post by Robert Withers-2
On Sat, May 2, 2020 at 8:06 PM Robert <[hidden email]> wrote:
Hydra was a fork of the pre-stack VM. I don't know where is the code. Igor may be able to answer. Ask him. As Tim said, it's not clear there is a high benefit from running many image on 1 VM vs multiple images, each on their VM. One advantage could be the speed of communication between the images. However, it's possible to have a byte array on a Posix Shared Memory section (Pavel had made some FFI bindings to do that) that is shared between multiple images. I'm sure with a clever design one could share more than just a byte array. With a shared memory section and external semaphores, it's not clear there are good use-cases that would require multiple images on 1 VM.
I think Ryan could answer in a better way. My understand is that NewSpeak have value objects, which are immutable, and such objects can be shared between actors, including classes, methods and so on. Not sure about promise. Ryan, can you answer?
|
|
|
Hi Clément, On 5/2/20 2:47 PM, Clément Béra wrote:
Do you have Igor's email? I will ask.
I see your and Tim's point here. When asked I have always reported that the way to take advantage of multiple cores is to run multiple images on their own VM. The realm of actor mobility I have not worked on. Actor Mobility: I think it works just like a eukaryotic cell. with proteins produced through the ribosome and ER, then packaged for delivery with a network motif, and sent through the Golgi Apparatus to be delivered then unpackaged. Normally an Actor is not passByCopy, but a remoteERef is sent abroad. To convert a passByReference object into a passByCopy, serialize it into bytes and wrap it in a package, which is passByCopy. Send it forth, unpackaged remotely, it becomes a passByReference Actor again. Use this to communicate between VM/image/Vat/eventLoop.
Did you mean to copy Ryan? I would definitely like to hear of NewSpeak in this regard.
Value objects are immutable, thus sharable. Hmmm. Thinks about that. K, r
-- Kindly, Robert |
|
|
On Sun, May 3, 2020 at 2:59 AM Robert <[hidden email]> wrote:
Ask him directly. He will answer better.
|
|
|
In reply to this post by Clément Béra
On Sat, May 02, 2020 at 08:47:46PM +0200, Clément Béra wrote: > Hydra was a fork of the pre-stack VM. I don't know where is the code. Igor > may be able to answer. Ask him. There is a copy here: http://files.squeak.org/HydraVM/ Pierce |
| Free forum by Nabble | Edit this page |