Re: SHA256 performance with Guile 2.2 vs. Guile 3.0

[Göran Weinholt]

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
>
> The patch below gives us:
>
> ludo@ribbon /tmp/hashing$ guile --r6rs -L .. ~/tmp/sha256.scm
>
> ;;; (hash "b33576331465a60b003573541bf3b1c205936a16c407bc69f8419a527bf5c988")
> clock utime stime cutime cstime gctime
> 59.31 80.65  0.39   0.00   0.00  30.73
>
> It’s a disappointingly small improvement.  The reason is that (hashing
> fixnums) adds another layer of opacity, where it ends up doing
> essentially:
>
>   (define fx32xor fxxor)
>   …
>
> Thus, no inlining, and no easy trick to solve that.  :-/

I've pushed a Guile-specific version of (hashing fixnums) that inlines
the generic arithmetic procedures. This and some other small changes
improved the runtime:

           clock utime stime cutime cstime gctime
 before:
    2.2.6  31.06 32.61  0.03   0.00   0.00   1.38
    2.9.8  15.55 16.23  0.01   0.00   0.00   1.19
 after:
    2.2.6   2.95  3.01  0.00   0.00   0.00   0.10
    2.9.8   1.98  1.99  0.00   0.00   0.00   0.08

That's about 100 times slower than sha256sum from coreutils. You might
get some more performance out of it by unrolling the loop in
sha-256-transform!.

Regards,

-- 
Göran Weinholt   | https://weinholt.se/
Debian developer | 73 de SA6CJK