I've not really used Apple's vecLib before, so I'm bit of a newbie
at this. However, I'm trying to create a vFloat from an array (float
*) of floats that my software generates. The length of the array
(and therefore width of the vector) is computed at runtime.
So, I've looked everywhere (Apple's docs seem to be significantly
lacking in how to actually use all these vector functions), but I
can't see how one creates a vFloat of dynamic size? Am I trying to
do something wrong? Is it not possible to dynamically allocate
vFloats?
There is no vFloat of dynamic size; a vFloat is four floats. You can
cast a pointer-to-float to a pointer-to-vFloat:
float *Pointer = some value, likely a pointer returned from malloc;
...
vFloat *vPointer = (vFloat *) Pointer;
However, you must ensure that Pointer is aligned to a multiple of 16
bytes, because a vFloat must be so aligned. Pointers returned by Mac
OS X's malloc are aligned to multiples of 16 bytes. Arrays you
declare, e.g., "float f[4]", might not be. You can use GCC's attribute
extension to ensure that it is:
float f[4] __attribute__((__aligned__(16)));
So you would not have a vFloat of dynamic size, but you would treat a
pointer to vFloat like an array. You could refer to vPointer[0],
vPointer[1], et cetera. You can dynamically allocate an array of
vFloat with malloc or related functions (realloc et cetera):
vFloat *vPointer = malloc(n * sizeof *vPointer);
Here "n" is the number of vFloat objects, which can hold 4*n float
objects.
If you cast pointers as shown above, do not use "-fstrict-aliasing"
when compiling. "-fstrict-aliasing" tells the compiler that you will
never refer to the same object through pointers of different types,
like vPointer and Pointer. If you have "-fstrict-aliasing" on and
write to the array through Pointer but read through vPointer, the
compiler might not know that the contents of *vPointer have changed
and so might use old values instead of getting current ones from
memory. "-fstrict-aliasing" is off by default in GCC, but I would
check the command line Xcode actually uses to compile your source in
case it got turned on indirectly by some selection you made in your
project.
As Ian Ollmann writes, there are ways of loading vFloat objects from
unaligned addresses if you need to do that. Performance will not be
good, so you should try to avoid it.
If you describe more about what you are trying to do, we might be able
to give you more help. For example, if you are using the vDSP portion
of vecLib, you will generally not need vFloat objects. You would give
vDSP pointers-to-float, and it would deal with the SIMD issues. Using
vFloat objects is generally for people creating their own SIMD code,
and there is a fair amount to learn in that area.
There is a variety of material about SIMD/vector/AltiVec/SSE
programming on Mac OS X at <http://developer.apple.com/hardwaredrivers/ve/index.html
>. Some sample code I wrote is at <http://developer.apple.com/samplecode/SIMDPrimer/
>, but it is intended to go with WWDC 2008 session 453, "Using
Vectorization Techniques to Maximize Performance". (Video of the talk
is available through <http://developer.apple.com/adconitunes> to
WWDC08 attendees and premier Apple Developer Connect members. It can
also be purchased, but it appears you must buy a whole collection of
talks.)
—edp (Eric Postpischil)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
PerfOptimization-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
