guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SHA256 performance with Guile 2.2 vs. Guile 3.0


From: Ludovic Courtès
Subject: Re: SHA256 performance with Guile 2.2 vs. Guile 3.0
Date: Tue, 07 Jan 2020 12:08:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hi!

Andy Wingo <address@hidden> skribis:

> 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.

OK, sounds great.  What are your thoughts about versioning that wire
Tree-IL representation?

>> 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 :)

Alright, fine with me!

Thanks,
Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]