Re: vectors are something else

[Daniel Llorens]

Date: Fri, 12 Apr 2013 17:43:14 -0400
From: Mark H Weaver <address@hidden>

> I've not yet had time to carefully read this thread, but I wanted to say
> that I think we *should* prohibit passing arrays to the vector
> interfaces.  When we have native code generation, then it will be
> possible to make the vector procedures extremely simple machine code
> sequences.  We must avoid adding any complications to this.  Even a
> single additional conditional branch will be painful, in both runtime
> overhead and code size.
> 
> If we were to support a subset of arrays to the vector interface, the
> way it should be done is have the array constructors produce actual
> vector objects when possible, or at least something that can be used by
> the simple vector code sequences without any additional conditional
> branches.
> 
> Does this make sense?

Two things about this.

First, arrays cannot remain opaque types if we want any kind of performance. 
The compiler should know about the storage and about the array descriptor as 
independent objects. Then it's possible to inline the index computations, or to 
eliminate the array descriptor whenever it is not used or when its fields are 
known at compile time, or to eliminate type checks.

Second, the array operations don't involve any more branching than the vector 
operations, only an extra indirection that can be amortized over the size of 
the vector.

That's why I think that there're two options:

[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.

[2] force all vector objects into arrays. This removes container type dispatch 
from both the vector- and the array- ops, but it adds the cost of indirection 
to the vector- ops. Which is, I think, a good tradeoff, because that cost is 
smaller, there's some hope that the compiler will remove it in many cases, and 
we retain the flexibility in the use of vectors that we have now.

This choice affects the interface, if you care about performance. For example 
in [1], you'd prefer vector- to *reject* strided rank-1 arrays (inc!=1), 
because those require a descriptor and you want to limit your checks to 
is-this-scm_tc7_vector. On the other hand, in [2], you want to *accept* offset 
rank-1 arrays (lbnd!=0) because to reject them you need an explicit check and 
it's faster to just do the index computation with this lbnd.

What I don't think is a good option is what we have now, where both the vector- 
and the array- ops have to be able to deal with either type. Aside from the 
bugs.