<br><br><div class="gmail_quote">On Thu, Jan 6, 2011 at 5:47 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Hello, VM hackers<br>
<br>
i just want to ask, how well StackVM could replace original Squeak VM?<br>
If that's only image format aspect, then i think we can deal with that<br>
and forget about it once and for all.<br>
Also, i suspect that stack-interpreter VMs will be much more stable<br>
(because not including JIT), so people can always<br>
use it as a fallback solution if they can't make own code running stable on Cog.<br>
<br>
But if there are more issues than just image format, then please let me know.<br>
Because maintaining two different VMs is too much, especially that we<br>
don't have enough human resources for that.<br>
And so, we must choose. And choice is obvious, as to me. :)<br></blockquote><div><br></div><div>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.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
P.S. Can you please remind me, what conversion is needed between old<br>
image format and one which is edible by stack-based VM?<br>
And why just don't add it by default, so Stack VMs (and Cog) can read<br>
old image format (closure one)?<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>best</div><div>Eliot</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
</font></blockquote></div><br>