[Vm-dev] Making a Slower VM

[Eliot Miranda]

Hi David,

On Feb 23, 2014, at 8:22 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:
>>> 
>>> 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 turning
>>> 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.
> 
> You're right about one thing, it required a lot of patience ;-)
> 
> I did manage to get it working though, and the results are in VMMaker-dtl.342.
> 
> This turned out to be a useful exercise, as I flushed out a couple of type
> declaration bugs along the way.
> 
> The major issue was that the refactoring of object memory and interpreter
> into separate class hierarchies (which is a very good thing IMHO) requires
> the use of accessor methods, and this leads to name conflicts in the generated
> code if those accessor methods are not fully inlined.
> 
> I went with the approach of naming the accessors getFoo and setFoo: as well
> as, for the case of array access, fooAt: and fooAt:put:. This is not very
> pleasing from a readability point of view, but it is simple and it works.
> 
> If I compile a VM with inlining disabled and compiler optimization turned
> off, the result is about 1/8th the speed of the same interpreter VM built
> normally.

But more to the point, what's the speed with the same level of optimization as the normal VM?

and does this affect the internalFoo inlining?  Does this VM have everything that uses localSP & localIP inclined in interpret or are localSP & localIP no longer local to interpret?

> Dave


Eliot (phone)