Re: Inlining calls to primitives

[Ludovic Courtès]

Hi,

Rob Browning <address@hidden> writes:

> 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.

I think we agree on the general, long-term goal.

That said, this "inlining" thing is kind of a "pragmatic", incremental
approach.   Reviving Guile-VM or Hobbit may be a much longer process.

In the meantime, we find ourselves rewriting Scheme code (e.g., SRFI-1)
into C to get slight performance improvements.  If we can achieve
reasonable (although perhaps not as good) improvements by adding simple
annotations to Scheme code, then that will make things easier.

In designing those annotations, we should make sure that they are
"compiler-friendly", so that we can eventually make use of them in the
revived compiler(s).  (In hindsight, I think we did a mistake with
`current-reader' in that respect.)  This also rules out the
`eval-options' approach that I used in this prototype.

Note that C-rewriting has the same effect on semantics as this
"inlining" thing, since all the macros and C functions used in the C
implementation are not subject to redefinition.

>   - 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.

Cachegrind would tell us more.  In any case, it turns out that the
overhead of inlining few-instruction functions like `scm_car ()' is
ridiculous compared to function call overhead.

BTW, did you try inlining `scm_ilookup ()' as I mentioned in a previous
message?  Although that function is quite large, inlining it has a
noticeable impact on performance time.

Thanks,
Ludovic.