Compiler optimizations and Guile's module system

Compiler optimizations and Guile's module system

[No Itisnt]

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? If a binding is inlined, propagated, etcetera, and the
binding was set! by another module, then behavior could vary based on
whether the binding was optimized or not. (Bonus whine: Guile
currently does this with primitives like +) Off the top of my head,
R6RS makes all imported bindings immutable. How often are cross-module
set!s used in Guile? 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.

Re: Compiler optimizations and Guile's module system

[Andy Wingo]

On Fri 04 Jun 2010 09:25, No Itisnt <theseaisinhere@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/