Re: SHA256 performance with Guile 2.2 vs. Guile 3.0

[Andy Wingo]

On Mon 06 Jan 2020 10:47, Ludovic Courtès <address@hidden> writes:

> Andy Wingo <address@hidden> skribis:
>
>> With cross-module inlining of "small" definitions, I think we would
>> solve a lot of this kind of problem.  I think we could add this during
>> 3.0 and for this reason I would hesitate to apply this patch for 3.0
>> because it changes "fx+" exports to be macros rather than "normal"
>> values in the ABI.  WDYT?
>
> I agree that cross-module inlining is the better fix whereas this patch
> is the immediate workaround.
>
> Are you confident that cross-module inlining can happen be added without
> introducing incompatibilities over in the 3.0 series?  (At first sight
> it seems tricky to me, notably because we’d have to store Tree-IL in
> object files, which introduces compatibility and thus external
> representation versioning considerations.)

Concretely I would add a little part of the compiler to the Tree-IL
phase to serialize a bytecode for the "small" definitions in the module,
for declarative modules, both public and private (because public
definitions may alias private definitions).  This would be stored as a
bytevector in an additional field of the module, and the program being
compiled would be transformed to initialize the "lto" field (placeholder
name) of the module, so that once the compiled module is loaded, we have
the inlinable bindings.  I think this can be done compatibly.

> If you do, then it’s fine to drop this patch.  If conversely
> cross-module inlining might take longer, then we can have this patch in
> and drop it in 3.2.  Your call!  (I guess I’m not being that helpful
> here.  :-))

:)

I hesitate to land this patch because we haven't shown that it
significantly helps things, it would need to be undone, and it makes the
ABI more fragile.  So if that's OK let's do nothing :)

Cheers,

Andy