Re: New feature proposal: Support C-code inline?

[William ML Leslie]

On 23 April 2011 14:24, nalaginrut <address@hidden> wrote:
> I think this simple solution could be a temporary substitute before a
> AOT guile-compiler come out. To myself, I really want to use a AOT
> compiler to do such a job(it's better for optimizing the code).

Just to clear up a seemingly common misconception.

Those writing an aggressively optimising compiler like to see two things:

0. Information.  The more code you can see at a time the better, as it
enables you to see how functions are used; you can see this in
whole-program AOT compilers and modern JIT compilers such as hotspot,
which inlines very aggressively in order to obtain more data.
Information about the data these functions get applied to can be
useful as well, as can be seen from high-quality SQL query plan
optimisers, and the latest linear algebra libraries.

1. Room to breathe.  Once the language semantics are specified and
what effects are user-visible can be determined, the rest of the
universe is room to optimise!  For example, memory models are now
often chosen as a balance between sensible semantics for the
programmer and behaviour that has small enough impact on the runtime.

Now, the effect that these points are having on modern compiler and
runtime design should tend towards:

* AOT will get you half way there.  In embedded systems it may be
entirely suitable, but those environments are also the ones where
whole-program compilation is possible.  Where separate compilation is
desired, there are often more opportunities to optimise as dependent
modules are compiled, and even more opportunities once the working-set
and cache size, typical loop bounds, branch popularity etc can be
discovered, and many of these things may change across different
program inputs, so static compilation is unlikely to reach the quality
of code that dynamic compilation provides.

* Where calls into unsafe code occur, the semantics of the operation
are entirely unknown.  Thus the optimiser needs to assume that the
code may do absolutely anything it pleases.  It can mean that what
might have been loop invariant or heavily partially evaluated cannot
be.  To consider the impact that this actually has, the value bound to
a symbol in the current module cannot be assumed to be constant across
an external call, preventing inlining pretty much everywhere.  What
occasionally happens is that code written entirely within the language
that a smart runtime is able to inspect tends to be faster than that
which is in idiomatic C.

-- 
William Leslie