Allocated aligned arrays

Allocated aligned arrays

[ldb]

I'm trying to allocate two floating point (4 bytes each) arrays that
are both address-aligned to 16. Ideally, the first element of each
array is aligned on 16 (ie, the address mod 16 = 0), but that's not
really necessary, as long as they are both aligned to the same mod 16
(i don't care if the first element is 8 or 12 or whatever, as long as
both arrays have the same).

I'm trying to set up these arrays so I can use aligned SSE instructions
in assembly.

I have tried something along the lines of:

type Matrix is array (INTEGER range <>, INTEGER range <>) of float;
for Matrix'Alignment use 16;


and then, for an input of 0..200 by 0..200

sam := new Matrix(0..200,2..198)
bob := new Matrix(2..198,2..198);


These are the actual indicies I would use (it's an image processing
algorithm that trims the edges). I'm not sure if the strange indices
could be causing the problem, but I cannot imagine it is.

However, the three matricies, input, sam, and bob aren't necessarily
aligned (for certain input index ranges they are, by default, and some
times they are not. The alignment statement I am using seems to have no
effect).

Any ideas?

Re: Allocated aligned arrays

[jimmaureenrogers]

ldb wrote:
> I'm trying to allocate two floating point (4 bytes each) arrays that
> are both address-aligned to 16. Ideally, the first element of each
> array is aligned on 16 (ie, the address mod 16 = 0), but that's not
> really necessary, as long as they are both aligned to the same mod 16
> (i don't care if the first element is 8 or 12 or whatever, as long as
> both arrays have the same).
>
> I'm trying to set up these arrays so I can use aligned SSE instructions
> in assembly.
>
> I have tried something along the lines of:
>
> type Matrix is array (INTEGER range <>, INTEGER range <>) of float;
> for Matrix'Alignment use 16;
>
>
> and then, for an input of 0..200 by 0..200
>
> sam := new Matrix(0..200,2..198)
> bob := new Matrix(2..198,2..198);
>
>
> These are the actual indicies I would use (it's an image processing
> algorithm that trims the edges). I'm not sure if the strange indices
> could be causing the problem, but I cannot imagine it is.
>
> However, the three matricies, input, sam, and bob aren't necessarily
> aligned (for certain input index ranges they are, by default, and some
> times they are not. The alignment statement I am using seems to have no
> effect).

You may specify alignment only for the first subtype of a base type.
Thus, you may want to define a new type:

type Real is new float;
for Real'Alignment use 16;

The AARM contains the following bit of wisdom:

"The Alignment of a composite object is always equal to the least
common multiple of the Alignments of its components, or a multiple
thereof."

Jim Rogers

Re: Allocated aligned arrays

[ldb]

However, if I do that, won't that essentially break every current
implementation of Matrix already in the code? (The code isn't small,
and it's a very commonly used datatype... ).

Ie, is that going to require me to overload +, -, etc to work with Real
and Floats, etc? And/or functions that pass in a float, currently, will
need to be overloaded to also work with real, and so on? That seems
like alot of work just to get a memory allocation that is 8 bytes
farther north or south. Is there any other way, or I am up a creek?

Re: Allocated aligned arrays

[Martin Krischik]

ldb wrote:

> However, if I do that, won't that essentially break every current
> implementation of Matrix already in the code? (The code isn't small,
> and it's a very commonly used datatype... ).
> 
> Ie, is that going to require me to overload +, -, etc to work with Real
> and Floats, etc?

No. You can convert from and to Float:

http://en.wikibooks.org/wiki/Ada_Programming/Subtypes#Checked_conversion

> And/or functions that pass in a float, currently, will 
> need to be overloaded to also work with real, and so on? That seems
> like alot of work just to get a memory allocation that is 8 bytes
> farther north or south. Is there any other way, or I am up a creek?

No again: all standart functions are also available as generic variants.

http://en.wikibooks.org/wiki/Ada_Programming/Mathematical_calculations#Exponential_calculations

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Allocated aligned arrays

[Simon Wright]

"jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net> writes:

> You may specify alignment only for the first subtype of a base type.
> Thus, you may want to define a new type:
>
> type Real is new float;
> for Real'Alignment use 16;

Wouldn't that make arrays of Real rather large?

Re: Allocated aligned arrays

[ldb]

I just implemented it, and yes, my array is now an array of 4 byte
floating points, each aligned to 16 byte boundries... effectively
multiplying the array size by 4.

Re: Allocated aligned arrays

[Simon Wright]

"ldb" <louis@pittpatt.com> writes:

> These are the actual indicies I would use (it's an image processing
> algorithm that trims the edges). I'm not sure if the strange indices
> could be causing the problem, but I cannot imagine it is.
>
> However, the three matricies, input, sam, and bob aren't necessarily
> aligned (for certain input index ranges they are, by default, and some
> times they are not. The alignment statement I am using seems to have no
> effect).

A little experiment here shows that GCC 4.0.0 on Darwin seems to work
reasonably, but your problem is no doubt bigger.

What compiler/architecture? sounds like a bug to me -- I don't believe
a compiler is (should be!) allowed to accept a pragma like this and
then fail to honour it?

Note however RM 3.3(32):

   An implementation need not support specified Alignments that are
   greater than the maximum Alignment the implementation ever returns
   by default.

Re: Allocated aligned arrays

[Jeff Creem]

Simon Wright wrote:
> "ldb" <louis@pittpatt.com> writes:
> 
> 
>>These are the actual indicies I would use (it's an image processing
>>algorithm that trims the edges). I'm not sure if the strange indices
>>could be causing the problem, but I cannot imagine it is.
>>
>>However, the three matricies, input, sam, and bob aren't necessarily
>>aligned (for certain input index ranges they are, by default, and some
>>times they are not. The alignment statement I am using seems to have no
>>effect).
> 
> 
> A little experiment here shows that GCC 4.0.0 on Darwin seems to work
> reasonably, but your problem is no doubt bigger.
> 
> What compiler/architecture? sounds like a bug to me -- I don't believe
> a compiler is (should be!) allowed to accept a pragma like this and
> then fail to honour it?
> 
> Note however RM 3.3(32):
> 
>    An implementation need not support specified Alignments that are
>    greater than the maximum Alignment the implementation ever returns
>    by default.


It seems like one could reasonably work around this (whether it is a bug 
or an implementation limit) with a user defined storage pool.

Re: Allocated aligned arrays

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message
news:m2wtj56qdv.fsf@grendel.local...
> "ldb" <louis@pittpatt.com> writes:
...
> > However, the three matricies, input, sam, and bob aren't necessarily
> > aligned (for certain input index ranges they are, by default, and some
> > times they are not. The alignment statement I am using seems to have no
> > effect).
>
> A little experiment here shows that GCC 4.0.0 on Darwin seems to work
> reasonably, but your problem is no doubt bigger.
>
> What compiler/architecture? sounds like a bug to me -- I don't believe
> a compiler is (should be!) allowed to accept a pragma like this and
> then fail to honour it?

I agree, that sounds like a compiler bug. If you accept an alignment clause,
you ought to honor it. (Janus/Ada only accepts alignments of 1, 2 and 4 for
this reason.) That's little help for the OP, however.

It's quite possible that a variable (rather than an allocator) would do the
right thing. (Often there is separate code controlling such things.) That
may not be practical for the OP, either. Someone suggested a user-defined
storage pool, which may be the only recourse.

                               Randy.

Re: Allocated aligned arrays

[ldb]

Thanks for all the responses. I have looked into user-defined storage
pools, but they appear to have two very large limitations:

Can they be dynamically sized?
Can I only associate entire types with storage pools.. or can I
associate individual instances of a type with different pools?

In other words, I'd like to be able to allocate the storage-pool size
at run-time, after I know the dimensions of the input. I can't really
seem to figure out if this is even possible. And furthermore, I'd only
like certain instances of a particular class to use that storage pool,
not all of them (I don't want every instance of a particular variable
in a large structure to have to use my storage pool).

Perhaps, then, using subtypes, there is a way around the second issue?
But, again, the entire purpose of requesting aligned arrays is to
improve the speed of the run, so any rigorous conversion function is
essentially a killer, also.

Re: Allocated aligned arrays

[Frank J. Lhota]

"ldb" <louis@pittpatt.com> wrote in message 
news:1132756111.751623.309350@g14g2000cwa.googlegroups.com...
> Thanks for all the responses. I have looked into user-defined storage
> pools, but they appear to have two very large limitations:
>
> Can they be dynamically sized?

Yes. When you define your own storage pool, it is up to you to devise how 
the allocations and deallocations are performed. There is no prohibition on 
dynamically sized pools, and in fact that is frequently done.

> Can I only associate entire types with storage pools.. or can I
> associate individual instances of a type with different pools?

Pools are associated with access types. For a given type T, you can create 
multiple access types for accessing T, each with its own storage pool, e.g.

    type T is ...;

    type T_Acc_1 is access T;
    for T_Acc_1'Storage_Pool use Pool_1;

    type T_Acc_2 is access T;
    for T_Acc_2'Storage_Pool use Pool_2;

> In other words, I'd like to be able to allocate the storage-pool size
> at run-time, after I know the dimensions of the input. I can't really
> seem to figure out if this is even possible. And furthermore, I'd only
> like certain instances of a particular class to use that storage pool,
> not all of them (I don't want every instance of a particular variable
> in a large structure to have to use my storage pool).
>
> Perhaps, then, using subtypes, there is a way around the second issue?
> But, again, the entire purpose of requesting aligned arrays is to
> improve the speed of the run, so any rigorous conversion function is
> essentially a killer, also.
> 

Re: Allocated aligned arrays

[Robert A Duff]

"ldb" <louis@pittpatt.com> writes:

> Thanks for all the responses. I have looked into user-defined storage
> pools, but they appear to have two very large limitations:
> 
> Can they be dynamically sized?

Yes.

A storage pool can contain anything you like.  For example, it could
have a discriminant that controls the size of an array of bytes, and you
allocate out of that array.  Or it could contain a linked list of chunks
of memory.  The chunks could be allocated from some lower-level pool.
You could use mmap to allocate the chunks.  You can control their size
however you like.  You can make a storage pool type that always
allocates on page-aligned boundaries, if you like.

This is not a problem.

> Can I only associate entire types with storage pools.. or can I
> associate individual instances of a type with different pools?

This is a problem for some applications.  You say "for T'Storage_Pool
use ..." and _all_ allocators that return type T will use that pool.  It
would be more flexible to specify the pool on each "new", but Ada does
not directly support that.

Various workarounds are possible.  It's tricky to make them task-safe.

But I thought you just wanted to make sure all objects of a certain type
are allocated at some aligned boundary.  If so, you don't need a
different pool for each object.  Just make a storage pool that always
allocates on the boundary you want, and specify that pool via "for
T'Storage_Pool use ...".  I'm not sure I understand your requirements
-- why wouldn't that work?

> In other words, I'd like to be able to allocate the storage-pool size
> at run-time, after I know the dimensions of the input.

Why do you care about the size of the pool?  It seems to me you care
about the size (and alignment) of each allocated object, and that info
is passed to the Allocate procedure.  The pool itself can be programmed
to use however much memory is required, up to the available address
space.

>... I can't really
> seem to figure out if this is even possible. And furthermore, I'd only
> like certain instances of a particular class to use that storage pool,
> not all of them (I don't want every instance of a particular variable
> in a large structure to have to use my storage pool).

Heh?  Only objects allocated with "new" will use the storage pool.
Components of a record will not -- they're just part of the record.  To
align components of a record, you can use a record rep clause, and also
make sure the whole record is properly aligned.

> Perhaps, then, using subtypes, there is a way around the second issue?
> But, again, the entire purpose of requesting aligned arrays is to
> improve the speed of the run, so any rigorous conversion function is
> essentially a killer, also.

- Bob