I have not read about this anywhere I can remember. Would it be possible to run two images on one VM?
Preggo,
Robertotini
Sent from ProtonMail Mobile
I was thinking they’d Run Concurrently, of course. #SVS!!!
K, r
Sent from ProtonMail Mobile
On Wed, Apr 29, 2020 at 14:43, Robert robert.withers@pm.me wrote:
I have not read about this anywhere I can remember. Would it be possible to run two images on one VM?
Preggo,
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 robert.withers@pm.me wrote:
I have not read about this anywhere I can remember. Would it be possible to run two images on one VM?
Preggo, Robertotini
Sent from ProtonMail Mobile
On 2020-05-01, at 11:59 AM, Clément Béra bera.clement@gmail.com 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; tim@rowledge.org; http://www.rowledge.org/tim Design simplicity: It was developed on a shoe-string budget.
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 bera.clement@gmail.com 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; tim@rowledge.org; http://www.rowledge.org/tim Design simplicity: It was developed on a shoe-string budget.
On 5/1/20 2:59 PM, Clément Béra wrote:
The Hydra VM from Igor was doing exactly that.
Stellar! Could we reintegrate with the latest squeak.cog.spur?
The Actor model in Newspeak is also somewhat similar to that, though part of the image is shared between threads.
I believe the Newspeak Actors are implemented with local capabilities, from ELib, just as my CapabilitiesLocal package. DoIt:
Installer ss project: 'Cryptography'; install: 'CapabilitiesLocal'.
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
Not sure what is the status of these projects though.
On Wed, Apr 29, 2020 at 8:43 PM Robert robert.withers@pm.me wrote:
I have not read about this anywhere I can remember. Would it be possible to run two images on one VM?
Preggo,
Robertotini
Sent from ProtonMail Mobile
--
Clément Bérahttps://clementbera.github.io/ https://clementbera.wordpress.com/
-- Kindly, Robert
On Sat, May 2, 2020 at 8:06 PM Robert robert.withers@pm.me wrote:
On 5/1/20 2:59 PM, Clément Béra wrote:
The Hydra VM from Igor was doing exactly that.
Stellar! Could we reintegrate with the latest squeak.cog.spur?
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.
The Actor model in Newspeak is also somewhat similar to that, though part of the image is shared between threads.
I believe the Newspeak Actors are implemented with local capabilities, from ELib, just as my CapabilitiesLocal package. DoIt:
Installer ss project: 'Cryptography'; install: 'CapabilitiesLocal'.
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?
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?
K, r
Not sure what is the status of these projects though.
On Wed, Apr 29, 2020 at 8:43 PM Robert robert.withers@pm.me wrote:
I have not read about this anywhere I can remember. Would it be possible to run two images on one VM?
Preggo, Robertotini
Sent from ProtonMail Mobile
-- Clément Béra https://clementbera.github.io/ https://clementbera.wordpress.com/
-- Kindly, Robert
Hi Clément,
On 5/2/20 2:47 PM, Clément Béra wrote:
On Sat, May 2, 2020 at 8:06 PM Robert robert.withers@pm.me wrote:
On 5/1/20 2:59 PM, Clément Béra wrote:
The Hydra VM from Igor was doing exactly that.
Stellar! Could we reintegrate with the latest squeak.cog.spur?
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.
Do you have Igor's email? I will ask.
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 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.
The Actor model in Newspeak is also somewhat similar to that, though part of the image is shared between threads.
I believe the Newspeak Actors are implemented with local capabilities, from ELib, just as my CapabilitiesLocal package. DoIt:
Installer ss project: 'Cryptography'; install: 'CapabilitiesLocal'.
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?
I think Ryan could answer in a better way.
Did you mean to copy Ryan? I would definitely like to hear of NewSpeak in this regard.
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?
Value objects are immutable, thus sharable. Hmmm. Thinks about that.
K, r
K, r
Not sure what is the status of these projects though.
On Wed, Apr 29, 2020 at 8:43 PM Robert robert.withers@pm.me wrote:
I have not read about this anywhere I can remember. Would it be possible to run two images on one VM?
Preggo,
Robertotini
Sent from ProtonMail Mobile
--
Clément Bérahttps://clementbera.github.io/ https://clementbera.wordpress.com/
-- Kindly, Robert
--
Clément Bérahttps://clementbera.github.io/ https://clementbera.wordpress.com/
-- Kindly, Robert
On Sun, May 3, 2020 at 2:59 AM Robert robert.withers@pm.me wrote:
Hi Clément, On 5/2/20 2:47 PM, Clément Béra wrote:
On Sat, May 2, 2020 at 8:06 PM Robert robert.withers@pm.me wrote:
On 5/1/20 2:59 PM, Clément Béra wrote:
The Hydra VM from Igor was doing exactly that.
Stellar! Could we reintegrate with the latest squeak.cog.spur?
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.
Do you have Igor's email? I will ask.
siguctua@gmail.com
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 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.
The Actor model in Newspeak is also somewhat similar to that, though part
of the image is shared between threads.
I believe the Newspeak Actors are implemented with local capabilities, from ELib, just as my CapabilitiesLocal package. DoIt:
Installer ss project: 'Cryptography'; install: 'CapabilitiesLocal'.
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?
I think Ryan could answer in a better way.
Did you mean to copy Ryan? I would definitely like to hear of NewSpeak in this regard.
Ask him directly. He will answer better.
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?
Value objects are immutable, thus sharable. Hmmm. Thinks about that.
K, r
K, r
Not sure what is the status of these projects though.
On Wed, Apr 29, 2020 at 8:43 PM Robert robert.withers@pm.me wrote:
I have not read about this anywhere I can remember. Would it be possible to run two images on one VM?
Preggo, Robertotini
Sent from ProtonMail Mobile
-- Clément Béra https://clementbera.github.io/ https://clementbera.wordpress.com/
-- Kindly, Robert
-- Clément Béra https://clementbera.github.io/ https://clementbera.wordpress.com/
-- Kindly, Robert
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
vm-dev@lists.squeakfoundation.org
-
Clément Béra -
Pierce Ng -
Robert -
tim Rowledge