Re: Generalized-Arrays egg v1.0.1

[Jeremy Steward]

On 2/3/24 16:03, John Cowan wrote:
> On Sat, Feb 3, 2024 at 5:39 PM Jeremy Steward <jeremy@thatgeoguy.ca 
> <mailto:jeremy@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