🚀 go-pugleaf

In article <943r3l$hn2$1@nnrp1.deja.com>, petrock 
<petrock00@my-deja.com> wrote:

> 
> Can I simply enable the Altivec compile settings in my existing code and
> recompile and it will have Altivec optimizations (At least the MacOS
> functions)?  like it kind of was with the 68k to PPC transition...

   No.

> it seems to me that Altivec code is very close to Assembly.  Assembly
> isn't that easy to code with.  Are their any libraries I can use to do
> alot of the work for me?

   There are intrinsic vector datatypes added to the language, and in 
fact a nice suite of stuff to wade through on the Apple site:

http://developer.apple.com/hardware/ve/


   (and yes there are libraries like vDSP and others available)

Rob

In article <943r3l$hn2$1@nnrp1.deja.com>, petrock
<petrock00@my-deja.com> wrote:

> Can I simply enable the Altivec compile settings in my existing code and
> recompile and it will have Altivec optimizations (At least the MacOS
> functions)?  like it kind of was with the 68k to PPC transition...

Metrowerks compiler does not do this. If you check out
<http://www.psrv.com/>, they make a vectorizing compiler for C, and
they say that C++ and Fortran are on the way. I've never used it, so I
don't know how well it works.

> Are there any tutorials or good books on Altivec programming?

You might search the MacHack web site or CDs to see if Doug Clarke's
presentations about AltiVec are there. Everything I know about AltiVec
I learned from Doug. Well, that and by making numerous mistakes on my
own. :-)

You can also get on the AltiVec list at www.altivec.org.

> it seems to me that Altivec code is very close to Assembly.  Assembly
> isn't that easy to code with.  Are their any libraries I can use to do
> alot of the work for me?

It's not that bad, really. You can even do crazy things like:

v1 = vec_add (vec_sub(v1,v2), vec_add (v3,v4));

That's equivalent to

v1 = (v1 - v2) + (v3 + v4);

Personally, I try to keep things to one AltiVec instruction per line.
It helps me optimize later, but there's no reason you have to do it
that way.

As others have said, there are various libraries available. Be careful
of vMathLib, though, as the trig functions are wacked. They are either
very buggy, or I'm using them in some unintended way. For example, the
sin and cos functions will return values outside of the -1 to 1 range.
It's always repeatable, and always the same result, but it's wrong, as
far as I can tell.

Hope that helps,
Darrin

-- 
Darrin Cardani
Buena Software, Inc. - Macintosh Video, Graphics and Audio Contract Development
http://www.buena.com/
dcardani@buena.com

In article <170120011731277716%dcardani@buena.spamfree.com>, Darrin
Cardani <dcardani@buena.spamfree.com> wrote:

> As others have said, there are various libraries available. Be careful
> of vMathLib, though, as the trig functions are wacked. They are either
> very buggy, or I'm using them in some unintended way. For example, the
> sin and cos functions will return values outside of the -1 to 1 range.
> It's always repeatable, and always the same result, but it's wrong, as
> far as I can tell.

Have you reported the bug?  I'm sure the engineers would be interested
in getting that fixed right away.

-Mark

On Wed, 17 Jan 2001, Darrin Cardani wrote:

> It's not that bad, really. You can even do crazy things like:
>
> v1 = vec_add (vec_sub(v1,v2), vec_add (v3,v4));
>
> That's equivalent to
>
> v1 = (v1 - v2) + (v3 + v4);
>
> Personally, I try to keep things to one AltiVec instruction per line.
> It helps me optimize later, but there's no reason you have to do it
> that way.

CodeWarrior does a reasonable job at scheduling if you write in C, so I am
curious how keeping things one per line helps you optimize.

Ian

---------------------------------------------------
   Ian Ollmann, Ph.D.       iano@cco.caltech.edu
---------------------------------------------------

> > Personally, I try to keep things to one AltiVec instruction per line.
> > It helps me optimize later, but there's no reason you have to do it
> > that way.
> 
> CodeWarrior does a reasonable job at scheduling if you write in C, so I am
> curious how keeping things one per line helps you optimize.

Ian, you misunderstood. He didn't say it helps CodeWarrior to optimize,
but that it helped HIM to optimize. If your code is written one
instruction per line, it's easier from an editing standpoint to reorder
operations later, than if you have to edit complex vector expressions.

Dave

Dave Howell wrote:

> > > Personally, I try to keep things to one AltiVec instruction per line.
> > > It helps me optimize later, but there's no reason you have to do it
> > > that way.
> >
> > CodeWarrior does a reasonable job at scheduling if you write in C, so I am
> > curious how keeping things one per line helps you optimize.
>
> Ian, you misunderstood. He didn't say it helps CodeWarrior to optimize,
> but that it helped HIM to optimize. If your code is written one
> instruction per line, it's easier from an editing standpoint to reorder
> operations later, than if you have to edit complex vector expressions.
>
> Dave

Hi, I'm curious about the qualifier "if you write in C" CW will schedule the
instructions effectively.  What I have done is to write a C++ class called
"vec4" so I can do things like

vec4 a(1,2,3,4);
vec4 b(2,3,4,5);
vec4 c;
c = a + b;

via operator overloading and inlining the c = a+b should resolve to
c = vec_add(a,b);
The vec4 is a union between a vector float and an array of four floats. For the
moment, I deal with vec_madd and vec_nmsub by wrapping them in equivalent
functions that operate on a vec4.  via inlining, the wrapper should have no
effect on the final code.

However, I observe that I take a modest performance hit by doing this as
opposed to just writing out the vector instructions explicitly.  Is there some
reason the compiler should optimize differently in the two cases?

Dan Gordon

In article <170120011731277716%dcardani@buena.spamfree.com>, Darrin
Cardani <dcardani@buena.spamfree.com> wrote:

> Be careful
> of vMathLib, though, as the trig functions are wacked. They are either
> very buggy, or I'm using them in some unintended way. For example, the
> sin and cos functions will return values outside of the -1 to 1 range.
> It's always repeatable, and always the same result, but it's wrong, as
> far as I can tell.

I checked with the AltiVec engineers, and they say this is already
fixed in 9.1.

-Mark

On 18 Jan 2001, Dave Howell wrote:

> > > Personally, I try to keep things to one AltiVec instruction per line.
> > > It helps me optimize later, but there's no reason you have to do it
> > > that way.
> >
> > CodeWarrior does a reasonable job at scheduling if you write in C, so I am
> > curious how keeping things one per line helps you optimize.
>
> Ian, you misunderstood. He didn't say it helps CodeWarrior to optimize,
> but that it helped HIM to optimize. If your code is written one
> instruction per line, it's easier from an editing standpoint to reorder
> operations later, than if you have to edit complex vector expressions.

I understood perfectly. Reordering the instructions line by line by hand
doesn't do much if Codewarrior is doing the scheduling for you. It will
rearrange them right back the way it wants them in my experience. I guess
he could turn scheduling off, but goodness that wouldn't help the rest of
the program much.

Ian

---------------------------------------------------
   Ian Ollmann, Ph.D.       iano@cco.caltech.edu
---------------------------------------------------

In article
<Pine.SGI.4.30.0101171735050.41019-100000@helix2.caltech.edu>, Ian
Ollmann <iano@cco.caltech.edu> wrote:

> On Wed, 17 Jan 2001, Darrin Cardani wrote:
> 
> > Personally, I try to keep things to one AltiVec instruction per line.
> > It helps me optimize later, but there's no reason you have to do it
> > that way.
> 
> CodeWarrior does a reasonable job at scheduling if you write in C, so I am
> curious how keeping things one per line helps you optimize.

It helps me (not the compiler) understand what's going on better. I'm
better able to see all the instructions, and on a few occasions, I've
noticed that I could eliminate an instruction or replace a couple of
instructions with fewer instructions. I didn't mean to imply that the
compiler does anything different. Sorry if that's what it sounded like.

And yes, CodeWarrior does do a good job of scheduling. Or maybe, I just
do a bad job of it since I haven't read much about it. :-) Although, I
found on a few projects that CW's scheduling by itself made the code
slower, but with optimizations turned up all the way made it better.
So, as always, profile to be sure.

Darrin

-- 
Darrin Cardani
Buena Software, Inc. - Macintosh Video, Graphics and Audio Contract Development
http://www.buena.com/
dcardani@buena.com

In article <180120011044342311%mday@apple.com>, Mark Day
<mday@apple.com> wrote:

> In article <170120011731277716%dcardani@buena.spamfree.com>, Darrin
> Cardani <dcardani@buena.spamfree.com> wrote:
> 
> > Be careful
> > of vMathLib, though, as the trig functions are wacked. They are either
> > very buggy, or I'm using them in some unintended way. For example, the
> > sin and cos functions will return values outside of the -1 to 1 range.
> > It's always repeatable, and always the same result, but it's wrong, as
> > far as I can tell.
> 
> I checked with the AltiVec engineers, and they say this is already
> fixed in 9.1.

OK. Thanks for checking! It came up on the AltiVec list the other day.
Doug Clarke had submitted it as a bug a few months ago, but he said he
never heard back on it. Glad to hear it's fixed.

Thanks,
Darrin

-- 
Darrin Cardani
Buena Software, Inc. - Macintosh Video, Graphics and Audio Contract Development
http://www.buena.com/
dcardani@buena.com