On Apr 16, 2013, at 04:00, Mark H Weaver wrote:
>> [1] have vector- ops only accept vector- types. This removes container
>> type dispatch from the vector- ops but not from the array- ops. The
>> last patch set I've sent to the list goes in this direction. It
>> matches the behavior of other vector-like types such as bytevectors
>> and strings.
>
> I very much favor this approach, but unfortunately I don't think we can
> do it in 2.0. It'll have to wait until 2.2.
What should we do then about the consistency bugs? like vector? being #f on
something that is accepted by vector-ref and so on. Did you have a look at the
table I posted?
> I consider this option completely unacceptable. Arrays are much more
> complex than vectors, and will inevitably be *much* slower in the common
> case where the compiler doesn't know much.
...
> Most egregiously,
> 'make-shared-array' requires that array references apply an arbitrary
> affine transformation that's unknown at compile time, which means
> multiplications and additions for each index.
make-shared-array itself is a very slow function and I'd like to have some
alternatives, but it's only called when setting up the shared array. In any
case, it's not slow because of any multiplications, but because of how much it
conses.
You overestimate (by a lot) the cost of the index computation. One works on
arrays by looping over them. In these loops the strides are always constant. No
matter the rank of the array, in the inner loop only one index moves. The cost
of this stepping is negligible on any scenario that isn't hugely contrived.
Things like traversal order and memory order have a much larger impact on
performance. 90% of the reason why Guile arrays are dog slow is that they've
been programmed with no concern for efficiency. The other 10% is the need to do
type dispatch on various kinds of containers and various types of elements.
(These numbers are invented.)
> Don't get me wrong: I'm all in favor of providing flexible, generic,
> extensible procedures. They have their place. I think that's why
> there's still a justification for keeping 'generalized-vectors' around.
They didn't do anything that the array functions didn't do just as well. Plus
they were buggy —they are buggy in stable-2.0. And the names took half the
screen.
> However, efficiency demands that we also have simple, non-generic,
> non-extensible procedures as well. IMO, we should keep the vector,
> bitvector, and bytevector procedures as simple as possible.
Other than the bizarre idea that arrays have to be slow, I think this is a
sensible position. After all, arrays have both an array descriptor and a
reference to linear storage, so there must be a type for this linear storage.
(E.g. in stable-2.0, vector- operations take either arrays, in a buggy way, or
the underlying storage type, which is called 'simple vector' and isn't exposed
to Scheme.)
What's your take on Daniel Hartwig's position? For example a and b on the table
I posted —b is an array, but it prints as #(2 4). How do you justify forbidding
vector-ref for something that prints #(2 4) ?
Thanks for you comments,
Daniel
