belated feedback Alex Shinn (16 Apr 2021 15:00 UTC)
Re: belated feedback Bradley Lucier (16 Apr 2021 17:08 UTC)
Re: belated feedback John Cowan (16 Apr 2021 18:25 UTC)
Re: belated feedback Bradley Lucier (17 Apr 2021 21:48 UTC)
Re: belated feedback Alex Shinn (18 Apr 2021 23:45 UTC)
Re: belated feedback Bradley Lucier (16 Apr 2021 23:46 UTC)
Re: belated feedback Alex Shinn (17 Apr 2021 00:03 UTC)
Re: belated feedback Bradley Lucier (17 Apr 2021 01:10 UTC)
Re: belated feedback Alex Shinn (17 Apr 2021 01:22 UTC)
Re: belated feedback Alex Shinn (30 Apr 2021 05:41 UTC)
Re: belated feedback Bradley Lucier (30 Apr 2021 14:17 UTC)
Re: belated feedback John Cowan (30 Apr 2021 15:04 UTC)
Re: belated feedback Bradley Lucier (30 Apr 2021 16:42 UTC)
Re: belated feedback Alex Shinn (01 May 2021 09:27 UTC)
array-elements-in-order? (Was: belated feedback) Bradley Lucier (16 Jan 2022 19:08 UTC)

Re: belated feedback Alex Shinn 18 Apr 2021 23:45 UTC

On Sun, Apr 18, 2021 at 6:48 AM Bradley Lucier <xxxxxx@math.purdue.edu> wrote:
>
> On 4/16/21 2:25 PM, John Cowan wrote:
> >     Good question.  In my implementation safe? starts off #f, and mutable?
> >     starts off #t.  I'm pretty sure this was discussed somewhere in the
> >     mail
> >     list, but it doesn't seem to be in the document.  I'll add it to the
> >     pull request.
> >
> > I think there are good arguments for safe or immutable or both as
> > reasonable defaults, so I'd rather leave this explicitly
> > implementation-specific.
>
> Some of my thoughts:
>
> 1. We did discuss it on the mail list as starting with default-mutable?:
> #t default-safe?: #f, so in some ways I consider this simply an error in
> the SRFI document.

I think this can be added as at least a recommended default in a
post-finalization note.

> 2. If the default is implementation dependent, then every program, no
> matter how it wants default-mutable? and default-safe? to be set, is
> going to have to start with calls to
>
> (specialized-array-default-safe? <whatever>)
> (specialized-array-default-mutable? <whatever>)
>
> which is, in my opinion, unfortunate.

Safety is a little vague and implementation-specific to begin with,
so it may be OK to leave as a parameter, but I think using such a
dynamic parameter at all for mutable? was a mistake.  The default
should be built into the constructor procedures themselves.

The situation is made worse that these are not explicitly SRFI 39
or R7RS parameters.

> 3.  When default-safe? is #t, then many, many array operations will be
> significantly slower than when default-safe? is #f.  [...]
>
> 4.  I know that people programming with arrays generally want things to
> go fast, so I've been quite conscious about the speed of this library [...]

It turns out that by careless oversight, initially all SRFI 160 operations
in Chibi were unsafe.  I've since fixed this, and now they are always safe.
I have not as of yet exposed any unsafe operations in Chibi.  Chibi will
thus effectively ignore the safety setting.

Clearly, if you're interested in performance you wouldn't be using Chibi
to begin with.  But the interesting thing about arrays is that all of the
performance-sensitive operations are bulk computations, so this lends
itself to a variety of optimizations.  Matrix multiplication on two homogeneous
specialized arrays knows the inputs are valid and can therefore switch
to a fast-path using unsafe operations regardless of the safety setting.

But we can go further and consider pushing the computation onto a GPU,
or using an optimized Fortran implementation via FFI, etc. The Chibi
solution will naturally be to use an FFI, which puts in on the same footing
as the primary competitor, numpy, and will likely make it faster than any
other pure Scheme implementation.

So, I think there is a lot of leeway in how the safety setting is
used, if at all,
and don't think it matters as much for performance as one might suspect.

--
Alex