Ludovic Courtès <l...@gnu.org> writes:
> Ludovic Courtès <l...@gnu.org> 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
