[EMAIL PROTECTED] (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
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
