Re: SHA256 performance with Guile 2.2 vs. Guile 3.0

[Ludovic Courtès]

Hello,

Andy Wingo <address@hidden> skribis:

> On Sat 04 Jan 2020 01:40, Ludovic Courtès <address@hidden> writes:
>
>> Ludovic Courtès <address@hidden> skribis:
>>
>>> ludo@ribbon ~/src/guix$ ./pre-inst-env guix environment --pure --ad-hoc 
>>> guile-next guile3.0-hashing -- guile ~/tmp/sha256.scm
>>>
>>> ;;; (hash 
>>> "b33576331465a60b003573541bf3b1c205936a16c407bc69f8419a527bf5c988")
>>> clock utime stime cutime cstime gctime
>>> 65.17 89.75  0.45   0.00   0.00  35.63
>>
>>   (define fx32xor fxxor)
>>   …
>
> From a speed perspective I think there is one major issue and one minor
> issue.
>
> The major issue is that we don't do cross-module inlining.  But now that
> we have declarative modules, this is a possibility:
>
>   https://lists.gnu.org/archive/html/guile-devel/2016-03/msg00026.html
>   https://lists.gnu.org/archive/html/guile-devel/2016-03/msg00027.html

Neat.  Storing Tree-IL in object files reminds me of LTO in GCC & co.

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

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

> The minor issue, at least relatively speaking, is that IMO the (rnrs
> arithmetic fixnums) API is not appropriate for bitwise operations.  When
> you do bitwise operations and you want to ensure that you're within some
> fixed domain, it's best to do e.g. "(logand x #xffffffff)" on operands
> and results.  Guile will optimize this well.  The good optimization
> isn't fixnum vs other kinds of numbers, it's unboxing to raw unsigned
> integers; and you usually want to exclude negative numbers.  fx+ doesn't
> help with that.

I agree, of course.  The tragedy is that people would use this (clumsy)
API in the hope of getting better performance, and the result ends up
being worse performance, at least on today’s Guile (perhaps also on
other implementations?).

Thanks,
Ludo’.