GNU bug report logs -
#14599
An option to make vector allocation aligned
Previous Next
Full log
View this message in rfc822 format
On 06/14/2013 02:21 PM, Ludovic Courtès wrote:
> Jan Schukat <shookie <at> email.de> 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
This bug report was last modified 12 years and 61 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.