[Vm-dev] Making a Slower VM
eliot.miranda at gmail.com
Mon Feb 10 19:53:49 UTC 2014
On Sun, Feb 9, 2014 at 11:46 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> On Sun, Feb 09, 2014 at 10:23:37AM -0800, tim Rowledge wrote:
> > On 09-02-2014, at 10:07 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> > > Joking aside, there actually is one legitimate reason for wanting a
> slow VM.
> > > With high performance VMs and with ever faster hardware, it is very
> easy to
> > > implement sloppy things in the image that go unnoticed until someone
> runs the
> > > image on an old machine or on limited hardware. It is sometimes useful
> > > test on old hardware or on a slow VM to check for this.
> > 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.
> > > I think someone mentioned it earlier, but a very easy way to produce an
> > > intentionally slow VM is to generate the sources from VMMaker with the
> > > inlining step disabled. The slang inliner is extremely effective, and
> > > it off produces impressively sluggish results.
> > 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.
> Dang it, you're right, it's not working. I guess I have not tried this in
> a while, though I know that it used to work. Making things go slower seems
> like a worthwhile thing to do on a Sunday afternoon, so I think I'll see
> if I can fix it.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev