On Fri 04 Jun 2010 09:25, No Itisnt theseaisinh...@gmail.com writes:
I was thinking about inlining, contant propagation, and that class of
optimizations recently. Wouldn't Guile's module system (specifically,
module-set!) interfere with doing these optimizations on module-level
bindings?
Yes and no, I think. Inlining is fun, but effectively prevents late
binding. When you know you want to integrate a whole block of code, the
best thing to do is to express that lexically, by enclosing the whole
thing in a `let', for example. You can also specify that certain
important bindings are to be inlined by default, for example using
define-inlinable, as defined in srfi-9.
See http://www.scheme.com/csug8/use.html#./use:h6 for another
discussion.
(Bonus whine: Guile currently does this with primitives like +)
If it didn't, Guile would be quite slow :) Though, this should be an
option.
Off the top of my head, R6RS makes all imported bindings immutable.
How often are cross-module set!s used in Guile?
Not often.
Maybe exported bindings could be made immutable by default, and the
module definition would explicitly name variables that should be
mutable by external code, so the compiler knows not to optimize them.
Correct me if I'm wrong here, I've never dealt with this in practice
so I'm just musing out loud.
I wouldn't worry about it for now. We can always choose to inline more
in the future, but for now the performance bottleneck is native
compilation, which will take a couple years to sort itself out nicely.
Also consider that the logical end of an aggressive inliner is a
whole-program compiler, and I would not want to hack on a program
compiled with such a thing: if something does not go according to plan,
instead of debugging a live being, you have to do an autopsy on a corpse
:P
Cheers,
Andy
--
http://wingolog.org/
