Re: Inlining calls to primitives

[Rob Browning]

address@hidden (Ludovic Courtès) writes:

> memoization + jt + inline     | 32.4%      22.1%
> memoization + switch + inline | 31.9%      23.2%
> memoization + jt + funcall    | 24.0%      18.3%

> Function call overhead, however, _is_ important, though only the
> second source of improvement.  Repeatedly using function calls to
> execute a handful of instructions is costly.  Plus it probably
> increases cache misses, things like that.

First off, I'd like to say that I'm glad you're looking in to these
issues.

In addition, I have some comments:

  - Just as a general concern, I would personally lean toward only
    adopting changes to the interpreter that affect language semantics
    (especially if they change things to be non-RnRS) if the changes
    are optional, and more importantly, if they produce a fairly
    substantial increase in performance.

    What's substantial?  I'm not sure, but as an example, I don't
    think I'd want to give up the ability to redefine globals and have
    all the code see those changes for say only a %5-10 performance
    increase.  In part, that's also because I'd really rather see the
    same effort put toward resurrecting a VM or Hobbit, or pursuing
    some other approach that we hope will produce much larger
    improvements.

  - With respect to cache misses, at least in the general case, I
    would expect the reverse -- that inlining will tend to bloat the
    object code, and make cache overflows more likely.  I would also
    expect that inlining may put more pressure on RAM and register
    allocation.  Of course I haven't looked carefully at what you're
    doing in this particular case yet, so I'm just speaking broadly.

> Also, Rob mentioned on IRC that he was concerned about the global
> switch.  I believe this can be fixed using fluids or something like
> that so that inlining can be enabled/disabled on a per-module basis
> (as we did with `current-reader').

Right.  If it affects the semantics of the language, then I think it
should probably be optional, so that you can just turn it on for code
that was written with the changed semantics in mind.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4