Re: SHA256 performance with Guile 2.2 vs. Guile 3.0

[Andy Wingo]

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

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?

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.

Cheers,

Andy