FROM : Richard Cameron
DATE : Sun Oct 17 20:49:55 2004
So you've got some matrix M and you want to operate on a bunch of
vectors v1,v2,...,vn. You're worried about the overhead of calling the
BLAS function n times to act on each vector in turn?
If that's a problem for you (and you can easily benchmark it to find
out how much of a problem it is), then why don't you just store all
your vectors contiguously to form a matrix V such that the ith column
is the ith vector? Make one BLAS call to multiply matrix M by matrix V,
and then the ith column of the resulting matrix will be the result
you'd have got from multiplying M by your ith vector.
If you're really paranoid about speed then you might want to look at
ATLAS <http://math-atlas.sourceforge.net/>. I'm not sure what the state
of play is nowadays, but there was a point when it produced a faster
BLAS implementation than the one in Apple's Accelerate framework.
Richard.
On 17 Oct 2004, at 19:23, gabe taubman wrote:
> Thanks for the links! I was also wondering if anyone knows if this
> would be a useful way of utilizing AltiVec. For instance, the
> programs people write with this library are most likely not
> multiplying thousands of matrices in a row. However, it being a
> graphics package, they will be multiplying LOTS of vectors by matrices
> one by one, just not all in a bunch.
>
> On the Vector Libraries page, I read the stuff about cBLAS and it
> seems to have Matrix*Vector and stuff like that. So let's say that i
> comment out the function overload for Matrix * Vector and I replace it
> with one that uses the cBLAS version (gemv I think it is) and they do
> it just once. Will there be any significant speed up or is it just
> not worth it?
>
> Thanks!
> gabe
>
>
> On Sun, 17 Oct 2004 16:52:14 +1000, Steven Marcus
> <steven.<email_removed>> wrote:
>> Here are a couple of links you might find helpful:
>>
>> 1) http://developer.apple.com/hardware/ve/vector_libraries.html
>> 2) http://hpc.sourceforge.net/
>> 3) http://developer.apple.com/hardware/ve/index.html
>>
>> #1 introduces the Apple vector/matrix libraries which are altivec
>> accelerated
>> #2 has a reference to macstl which has accelerated numerics classes
>> for C++
>> #3 is the Velocity Engine / Altivec homepage
>>
>> good luck!
>>
>>
>>
>>
>> On Sun, 17 Oct 2004 00:38:48 -0400, gabe taubman <<email_removed>>
>> wrote:
>>> Hi,
>>> I'm part of the mac team porting an open source 3d graphics library
>>> to
>>> OS X. It has its own built in linear algebra package. I was
>>> wondering if instead of using its own matrix multiplication calls
>>> (etc) I could use the altivec ones instead.
>>>
>>>> From what I've read about altivec, is that the structure of the
>>> matrices and vectors would have to be changed into ones recognized by
>>> altivec, otherwise we'd lose tons of speed just transforming data
>>> around. If anyone has any advice, or comments on whether or not this
>>> is worthwhile I'd be very grateful. I'd really like to make this
>>> library great for OS X and it seems this is a good way to start.
>>>
>>> Thanks!
>>> gabe taubman
>>> _______________________________________________
>>> MacOSX-dev mailing list
>>> <email_removed>
>>> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>>>
>>
> _______________________________________________
> MacOSX-dev mailing list
> <email_removed>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
DATE : Sun Oct 17 20:49:55 2004
So you've got some matrix M and you want to operate on a bunch of
vectors v1,v2,...,vn. You're worried about the overhead of calling the
BLAS function n times to act on each vector in turn?
If that's a problem for you (and you can easily benchmark it to find
out how much of a problem it is), then why don't you just store all
your vectors contiguously to form a matrix V such that the ith column
is the ith vector? Make one BLAS call to multiply matrix M by matrix V,
and then the ith column of the resulting matrix will be the result
you'd have got from multiplying M by your ith vector.
If you're really paranoid about speed then you might want to look at
ATLAS <http://math-atlas.sourceforge.net/>. I'm not sure what the state
of play is nowadays, but there was a point when it produced a faster
BLAS implementation than the one in Apple's Accelerate framework.
Richard.
On 17 Oct 2004, at 19:23, gabe taubman wrote:
> Thanks for the links! I was also wondering if anyone knows if this
> would be a useful way of utilizing AltiVec. For instance, the
> programs people write with this library are most likely not
> multiplying thousands of matrices in a row. However, it being a
> graphics package, they will be multiplying LOTS of vectors by matrices
> one by one, just not all in a bunch.
>
> On the Vector Libraries page, I read the stuff about cBLAS and it
> seems to have Matrix*Vector and stuff like that. So let's say that i
> comment out the function overload for Matrix * Vector and I replace it
> with one that uses the cBLAS version (gemv I think it is) and they do
> it just once. Will there be any significant speed up or is it just
> not worth it?
>
> Thanks!
> gabe
>
>
> On Sun, 17 Oct 2004 16:52:14 +1000, Steven Marcus
> <steven.<email_removed>> wrote:
>> Here are a couple of links you might find helpful:
>>
>> 1) http://developer.apple.com/hardware/ve/vector_libraries.html
>> 2) http://hpc.sourceforge.net/
>> 3) http://developer.apple.com/hardware/ve/index.html
>>
>> #1 introduces the Apple vector/matrix libraries which are altivec
>> accelerated
>> #2 has a reference to macstl which has accelerated numerics classes
>> for C++
>> #3 is the Velocity Engine / Altivec homepage
>>
>> good luck!
>>
>>
>>
>>
>> On Sun, 17 Oct 2004 00:38:48 -0400, gabe taubman <<email_removed>>
>> wrote:
>>> Hi,
>>> I'm part of the mac team porting an open source 3d graphics library
>>> to
>>> OS X. It has its own built in linear algebra package. I was
>>> wondering if instead of using its own matrix multiplication calls
>>> (etc) I could use the altivec ones instead.
>>>
>>>> From what I've read about altivec, is that the structure of the
>>> matrices and vectors would have to be changed into ones recognized by
>>> altivec, otherwise we'd lose tons of speed just transforming data
>>> around. If anyone has any advice, or comments on whether or not this
>>> is worthwhile I'd be very grateful. I'd really like to make this
>>> library great for OS X and it seems this is a good way to start.
>>>
>>> Thanks!
>>> gabe taubman
>>> _______________________________________________
>>> MacOSX-dev mailing list
>>> <email_removed>
>>> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>>>
>>
> _______________________________________________
> MacOSX-dev mailing list
> <email_removed>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
| Related mails | Author | Date |
|---|---|---|
| gabe taubman | Oct 17, 06:38 | |
| Steven Marcus | Oct 17, 08:52 | |
| gabe taubman | Oct 17, 20:23 | |
| Richard Cameron | Oct 17, 20:49 | |
| Glen Low | Oct 18, 18:19 |






Cocoa mail archive

