bug#14599: An option to make vector allocation aligned

[Jan Schukat]

On 06/14/2013 02:21 PM, Ludovic Courtès wrote:
> Jan Schukat <address@hidden> skribis:
>
> >   The more I think about it and hear what you have to say, the more I
> > think alignment just needs to be tied to the type of the uniform
> > array.
> I think it would be wrong.  An array of floats is an array of floats,
> regardless of its alignment.

For floats nothing would change anyway. Those are 4byte data types with 
4byte alignment already. As for the larger types, you can still make 
them in any alignment with the take functions. Just the default would 
the optimized one when you add padding, and that's what it should be, 
since the scheme programmer doesn't care about the underlying memory 
layouts as much as the C programmer does. In normal guile uniform vector 
use you are completely oblivious to the underlying vector 
implementation, apart from the performance. In short: an array of floats 
is still an array of floats, and you can create them at any alignment, 
although cumbersomely. But the very point if creating arrays of native 
types is to better use the underlying hardware. And not taking advantage 
of alignment there unless you absolutely can't is negligent at best.
> > Also, now I lean more towards switching to 2.2 for myself and
> > implement it on there, because as Ludovic said, the compiling will
> > possibly preserve alignment there better.
> Well yeah, though you’d still need to come up with an annotation for
> that, and I’m not enthusiastic about changing the read syntax for that
> purpose.

You don't need a special annotation if the default alignment is the 
native alignment of the native type. If you create arrays of native 
types that is what you want in the vast majority of cases. Overriding 
that should be the extra work and forced by external requirements, not 
by internal coincidental implementation details. And the interfaces to 
do that are already there.

I wanna use native SIMD types, which are obviously less portable, but in 
the end where they do exist they are all more or less the same in memory 
layout:  4 32bit ieee floats, 4 32bit ints or 2 ieee doubles, all 
preferably aligned at 128 bit. That's true for sse, altivec and neon on 
x86, power and arm respectively.

I can see why you wouldn't want SIMD types in the core modules. I can 
also see why you wouldn't want to change existing read syntax.

What I can't see is why you wouldn't want native type arrays in native 
alignment by default. There is no downside, and the implementation makes 
doing that trivial.

And having a module of uniform SIMD type arrays/vectors could be very 
valuable. I'll probably do that as an extension then, with a #, reader. 
Would just be a lot of code duplication and less nice.


> Now, I think the compiler should support a generic annotation mechanism,
> to allow users to specify various things (like ‘declare’ in some
> implementations.)  That could be one possible use.
>
> Ludo’.

Yes, that would have a lot of utility.

Regards

Jan Schukat