<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Feb 9, 2014 at 11:46 AM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Sun, Feb 09, 2014 at 10:23:37AM -0800, tim Rowledge wrote:<br>
><br>
><br>
> On 09-02-2014, at 10:07 AM, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
> > Joking aside, there actually is one legitimate reason for wanting a slow VM.<br>
> > With high performance VMs and with ever faster hardware, it is very easy to<br>
> > implement sloppy things in the image that go unnoticed until someone runs the<br>
> > image on an old machine or on limited hardware. It is sometimes useful to<br>
> > test on old hardware or on a slow VM to check for this.<br>
><br>
</div>> The cheapest and easiest way to do it these days is to buy a Raspberry Pi. You?ll learn very quickly where you have used crappy algorithms or poor technique? though of course you do have to put up with X windows as well. Unless you try RISC OS, which although not able to make the raw compute performance faster at least has a window system that doesn?t send every pixel to the screen via Deep Space Network to the relay on Sedna.<br>
<div class="im">><br>
> > I think someone mentioned it earlier, but a very easy way to produce an<br>
> > intentionally slow VM is to generate the sources from VMMaker with the<br>
> > inlining step disabled. The slang inliner is extremely effective, and turning<br>
> > it off produces impressively sluggish results.<br>
><br>
</div>> Does that actually work these days? Last I remember was that turning inlining off wouldn?t produce a buildable interp.c file. If someone has had the patience to make it work then I?m impressed.<br>
><br>
<br>
Dang it, you're right, it's not working. I guess I have not tried this in<br>
a while, though I know that it used to work. Making things go slower seems<br>
like a worthwhile thing to do on a Sunday afternoon, so I think I'll see<br>
if I can fix it.<br></blockquote><div><br></div><div>I *think* the issue is the internal/external split brought abut by the introduction of the localFoo variables, such as localSP and localIP. This optimization absolutely depends on inlining. Which reminds me that anyone who is interested in creating a StackInterpreter or CoInterpreter that *doesn't* use the internal methods and uses only stackPointer, framePointer and instructionPointer would have my full support. I'm very curious to see what the performance of stack+internal vs stack-internal, and cog+internal vs cog-internal will be. I'm hoping that the performance of the -internal versions is good enough that we could eliminate all that duplication.</div>
</div><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>