[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SHA256 performance with Guile 2.2 vs. Guile 3.0
From: |
Göran Weinholt |
Subject: |
Re: SHA256 performance with Guile 2.2 vs. Guile 3.0 |
Date: |
Sun, 05 Jan 2020 15:28:50 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Arne Babenhauserheide <address@hidden> writes:
> Göran Weinholt <address@hidden> writes:
>> 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!.
>
> I’d like to highlight the understatement: The new version is about
> factor 10 faster on 2.2.6 and factor 8 faster on 2.9.8 (and the new
> version on Guile 2.9.8 is factor 15 faster than the old version with the
> old Guile).
>
> That’s an awesome speedup!
>
> (can you show the change/patch that did this? Sidenote: It would be
> great to have a list of performance hints for Guile)
The commit is here:
https://github.com/weinholt/hashing/commit/eb28080180b5fdfb6ffc74f8cdf2c1a7823ef0cb
The relevant changes are:
* The define-fx macro previously returned:
#'(define name
(if (> (fixnum-width) bit-width)
fxname bitwise-name))
This was bad for three reasons: Guile does not do constant folding on
(fixnum-width); in Guile the fixnum procedures are slower than the
generic procedures; and Guile 2.2 did not inline those defines. It now
returns:
#'(define-syntax name
(identifier-syntax bitwise-name))
So the generic procedures like +, bitwise-and, etc are used instead of
fx+ and fxand. The use of define-syntax and identifier-syntax is
basically manual inlining for the benefit of Guile 2.2.
* I replaced some instances of fixnum operations with the ones from
(hashing fixnums), which benefit from the above.
* I changed some comparisons with constant fixnums to use eqv? instead
of fx=?, e.g. (eqv? i 8) instead of (fx=? i 8). This is commonly
faster, not only in Guile, because in implementations with immediate
fixnums it can be done with only a simple compare + branch. I don't
know if Guile takes advantage of this fact, but it's still faster than
fx=?.
Regards,
--
Göran Weinholt | https://weinholt.se/
Debian developer | 73 de SA6CJK
- SHA256 performance with Guile 2.2 vs. Guile 3.0, Ludovic Courtès, 2020/01/03
- Re: SHA256 performance with Guile 2.2 vs. Guile 3.0, Ludovic Courtès, 2020/01/03
- Re: SHA256 performance with Guile 2.2 vs. Guile 3.0, Andy Wingo, 2020/01/05
- Re: SHA256 performance with Guile 2.2 vs. Guile 3.0, Ludovic Courtès, 2020/01/06
- Re: SHA256 performance with Guile 2.2 vs. Guile 3.0, Andy Wingo, 2020/01/06
- Re: SHA256 performance with Guile 2.2 vs. Guile 3.0, Ludovic Courtès, 2020/01/07
- Re: SHA256 performance with Guile 2.2 vs. Guile 3.0, Andy Wingo, 2020/01/07
- Re: SHA256 performance with Guile 2.2 vs. Guile 3.0, Ludovic Courtès, 2020/01/07