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