Re: Compiler optimizations and Guile's module system

[Andy Wingo]

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