About StackInterpreter VM
Locked
 
|
Hello, VM hackers i just want to ask, how well StackVM could replace original Squeak VM? If that's only image format aspect, then i think we can deal with that and forget about it once and for all. Also, i suspect that stack-interpreter VMs will be much more stable (because not including JIT), so people can always use it as a fallback solution if they can't make own code running stable on Cog. But if there are more issues than just image format, then please let me know. Because maintaining two different VMs is too much, especially that we don't have enough human resources for that. And so, we must choose. And choice is obvious, as to me. :) P.S. Can you please remind me, what conversion is needed between old image format and one which is edible by stack-based VM? And why just don't add it by default, so Stack VMs (and Cog) can read old image format (closure one)? -- Best regards, Igor Stasenko AKA sig. |
Re: About StackInterpreter VM
|
|
On Thu, Jan 6, 2011 at 5:47 PM, Igor Stasenko <[hidden email]> wrote:
The main issue is that it relies on a heartbeat. It doesn't have to rely on a heartbeat, but it's performance suffers. I should measure but I would guess overall performance would drop by 3% - 5%. But also the use of an interrupt counter (as in the standard VM) is a very bad thing since its frequency depends on what the VM is doing. If the VM is doing lots of slow primitives (large integer arithmetic) it counts very slowly and the VM's interrupt latency soars. If the VM is not doing lots of sow primitives it burns cycles polling for I/O too frequently (or on fetching the time to prevent it from polling for I/O too frequently). So IMO heartbeats are a really good idea. However, the heartbeat isn't well-supported on every platform. In particular we have been fighting linux at Teleplace for some time and so far we don't have a bullet-proof heartbeat. It works perfectly well on Mac OS X and Windows. I also wonder if there are minimal embedded systems that don't provide one of the two alternatives for heartbeats, a) a high-priority thread that blocks on a timeout and b) a periodic interrupt timer.
The StackVM requires closures, which we have. Also, nut not necessarily, the stack VM uses native float ordering. Of course the right fix here is to make the standard VM support native float ordering. It makes no sense for the standard V to waste cycles reversing floats on every floating-point op. Whether I should have exposed that in the image format and image segment format is debateable; it could have been hidden at snapshot or image format write time. Btu that the standard VM doesn't hold floats in platform order at run-time is IMNAAHO absurd.
best Eliot
|
|
|
In reply to this post by Igor Stasenko
On Fri, Jan 07, 2011 at 02:47:59AM +0100, Igor Stasenko wrote: > > Hello, VM hackers > > i just want to ask, how well StackVM could replace original Squeak VM? > If that's only image format aspect, then i think we can deal with that > and forget about it once and for all. > Also, i suspect that stack-interpreter VMs will be much more stable > (because not including JIT), so people can always > use it as a fallback solution if they can't make own code running stable on Cog. > > But if there are more issues than just image format, then please let me know. > Because maintaining two different VMs is too much, especially that we > don't have enough human resources for that. > And so, we must choose. And choice is obvious, as to me. :) With respect to work and human resources, by far the largest part of the work will be in merging and reconciling the code bases. This needs to be done carefully and is therefore time consuming, and to to be honest not very enjoyable work so I suspect that it may take longer than any of us might like. Aside from that, I see no reason that the StackInterpreter would not become a replacement for the standard interpreter. Near term, StackInterpreter cannot support pre-closure images, which affects a large community of users. Currently it does not support the 64 bit image or the ability to create 32 and 64 bit image VMs from a single code base, although I know of no obstacles here other than somebody doing the work. So in summary, no real technical obstacles, just some work and dedication to make it happen. > > P.S. Can you please remind me, what conversion is needed between old > image format and one which is edible by stack-based VM? > And why just don't add it by default, so Stack VMs (and Cog) can read > old image format (closure one)? Cog can read any image that includes closure support. The traditional interpreter can read all known image formats, including Cog. StackInterpreter and Cog require images with closure support. Cog is currently limited to 32-bit image and 32-bit host. StackInterpreter is limited to 32-bit image, and I don't know if it can be compiled for 32-bit host. For most users, "limited to 32-bit" is no real limitation, since all practical images are 32-bit, and all widely used VMs are 32-bit host anyway. Currently allocated image formats are documented in the ImageFormat package on SqueakSource/VMMaker, see unit tests in ImageFormatTest. Dave |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |