On Sat 04 Jan 2020 01:40, 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 > > (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
