[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 23:59:49 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Andy Wingo <address@hidden> skribis:
> On Tue 07 Jan 2020 12:08, Ludovic Courtès <address@hidden> writes:
>
>> Andy Wingo <address@hidden> skribis:
>>
>>> 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?
>
> It would be a little bytecode language, with its own versioning
> considerations. It would need to have a translation to and from
> Tree-IL, though not necessarily lossless. It would change only in
> ABI-compatible ways, using the bytecode version of the Guile doing the
> compilation as a proxy for what is OK to support.
I see, that makes a lot of sense to me. Thanks for explaining!
Ludo’.