On 2/3/24 16:03, John Cowan wrote:
On Sat, Feb 3, 2024 at 5:39 PM Jeremy Steward <jer...@thatgeoguy.ca
<mailto:jer...@thatgeoguy.ca>> wrote:
Likewise, I opt to use (chicken fixnum) but this is
because I discovered that SRFI-143 is so egregiously slower than
(chicken fixnum) that it was causing serious performance regressions in
many of the array APIs.
That's very odd. The Chicken-specific library wrapper for SRFI 143 at
GitHub (srfi-143.scm, which needs to be updated to Chicken 5) makes use
of Chicken's native fx* procedures. I don't know how the Chicken (srfi
143) egg was built, though; it may be using rubber-chicken.scm and
fxcore.scm, which are slow emulations meant for complete portability.
From what I understand on the SRFI page it is in fact re-exporting
these procedures and not handling the overflow / underflow of some of
the operations.
There's this note on overflow on the docs page:
<https://wiki.call-cc.org/eggref/5/srfi-143#note-on-overflow>
Differences from the intended implementation details aside, I think the
core of what was a performance hazard (at least as far as I looked into
it) could have been one of two things (maybe both?):
1. The egg itself is not compiled with -O3, whereas if I link to
(chicken fixnum) I believe that these procedures will be inlined by the
CHICKEN compiler when the arrays egg is compiled with -O3 or higher.
2. There may be some rewriting rules that the compiler uses for
procedures in the (chicken ...) namespace that optimizes these directly
into their equivalent optimized C procedures. I'm not sure the compiler
has the same visibility if you re-export these from behind a module, and
especially not if you link dynamically (any hope of inlining those is
thus gone forever).
In fact on the latter point above, this raises an interesting question I
had for the mailing list: if I re-export a CHICKEN-specific procedure,
does the way the compiler handles translation units prevent certain
optimizations from applying? I've somewhat noticed that to be the case
but I haven't seen any writing about it nor have I understood the extent
to which that might affect certain SRFIs or eggs.
If you have time/energy, it would be useful to make Chicken's
implementation do what it was originally intended. See the
"Implementation" section in the SRFI, or feel free to ask me for
explanations of details.
I might have the time/energy for this, so I'll let you know if I stumble
into anything soon. I think a CHICKEN-specific implementation probably
wants to use the FFI since fixnums are guaranteed in their representation:
<https://wiki.call-cc.org/man/5/Data%20representation#immediate-objects>
It might also be a good idea to enforce SRFI-143's behaviour around
overflow / underflow as part of CHICKEN's default behaviour in CHICKEN
6, but I don't really know how I would get started having that discussion.
In any case, I've cc'd Diego (SRFI-143 maintainer), maybe together we
can find a way to improve the situation :)
Regards,
--
Jeremy Steward
