Introducing the PowerPC SIMD unit

An anonymous reader writes "AltiVec? Velocity Engine? VMX? If you've only been casually following PowerPC development, you might be confused by the various guises of this vector processing SIMD technology. This article covers the basics on what AltiVec is, what it does -- and how it stacks up against its competition."

Comments

AltiVec is nice...

[Grand V'izer]

I've done some altivec programming in the past, and discovered it was a very effective use of my time. Since there's no mode-switching penalty for using the vector instructions you can use it for some very trivial-but-common tasks, like replacing strlen(), vector operations on small tables, etc.. I knocked a lot of computation time (25%) from one of my projects just by vectorizing three functions. Of course there's a hitch: vector processing only works for certain kinds of algorithms and requires a change in mindset. In spite of that it's a great tool to have in your box.

Re:AltiVec is nice...

[evn]

The other nice thing about Altivec on OS X is that Apple has done a fairly good job of making it accessible without forcing the programmer to learn and use assembly language. These libraries will automatically fall back to a scaler code path if they're running on a G3 so it saves you from a fair bit of work there too. They have included a number of optimized libraries that use Altivec that are ready to go "out of the box" with xCode including:

• Vimage: for image processing
• vDSP: for signal processing
• BLAS: the name says it all: "Basic Linear Algebra"
• LAPAC: for solving systems of equations and matrix factorization
• Vector Math Library: unloads common operations like square root, transcendental functions, division, etc to VMX
• vBasicOps: for simple algebra operations like integer addition, subtraction, etc.
• VBN: for dealing with 256-1024bit numbers easily

Apple has documentation and source code for the libraries on their Developer Connection Website. What good are vector units if nobody can make use of them? I can't wait for Apple to put the GPUs image processing abilities into my hads with CoreImage/Video.

Re:The article makes a very good point...

[adam31]

the fact that SSE optimised code usually runs slower on an Athlon than 'unoptimised' code has severely limited its applications.

What does this even mean? I've written a great deal of optimized SSE code, and I can promise you that it works just as well on AMD. In fact, if you look at Athlon's pipeline, it does some really amazing things rescheduling and executing operations out-of-order. Fiddling around with ordering individual instructions is basically pointless because the scheduler has gotten so good at doing it on-the-fly.

Can you cite a specific example, because I've never run into this.

Re:Altivec and OS X

[ip_fired]

I googled around and found this article on Macworld:

According to several developers Macworld talked to who are currently working on OS X applications, anytime the OS can take advantage of the AltiVec engine, it does. This ensures that the parts of the OS that can utilize AltiVec, such as working in the new user interface, experience a significant increase in performance.

I don't know how much of OS X has AltiVec code, but there are many other apple apps that use it. iTunes uses it for encoding music. I'm sure the video codecs in Quicktime use it as well.

The Mac has a really nice optimization tool called shark which will help you find things that can be put into the AltiVec processor (it also helps with general optimization).

simdtech.org

[kuwan]

If anyone is interested, simdtech.org is probably the best resource you can find for AltiVec (or any other SIMD) programming. They have a number of tutorials and technical resources and the mailing list is the best there is. Motorola, Apple, and IBM engineers frequent the list so you can get help and information directly from the guys that created AltiVec as well as from those who program for it.

--
Join the Pyramid - Free Mini Mac

Re:Altivec and OS X

[Chuckstar]

Most (all?) Apple hardware does the checksum in hardware (built into the NIC). Add to that the inefficiency of using Altivec in the kernel, especially for small data sets, and it did not make sense for Apple to develop an Altivec version of the TCP checksum code.

The reason the article mentions the checksum case is not because Apple is missing the boat, but because there was a nice research article written about writing optimized TCP checksum code for Altivec, providing a good set of example code for aspiring Altivec coders.

Hold on there, partner. This isn't AltiVec stuff!

[Paradox]

Ahh Slashdot. First, let's mention this link which you were evidently too busy to provide. It links to two papers on how to tune for the G5. That way, someone can verify what I'm saying.

The problems you're talking about are not the AltiVec's fault, and the AltiVec instruction set is still stable. Code will still run very quickly even if you don't optimize for the G5. But, let me bring a quote from one of those linked papers:

Of course, your code may still need to be restructured to handle the increased latencies of the G5 Velocity Engine pipeline. Avoid small data accesses. Due to the increased latency to memory, the longer cache lines, and the nature of the CPU-to-memory bus, small data accesses should be avoided if possible. The entire system architecture has been designed to optimize the transfer of large amounts of data (i. e. maximize system memory throughput). As a side effect, the cost to handle small accesses can be very high and is quite inefficient.

See, the problem you're complaining about is a problem with any port to the G5, or really any port from a slow-thin-memory-access system to a fast-wide-memory-access system. It has nothing to do with your AltiVec code. It just has to do with tuning for a larger L2 cache and and faster FSB rather than a slow FSB and a huge L3 cache.

So let's not blame AltiVec for this. Except for a brief change in policy in the 745X G4, it seems like the AltiVec invocation has been stable for quite awhile.

Re:Altivec and OS X

[bill_mcgonigle]

I'd like to know if Mac OS X uses the Altivec instructions to their full potential.

No, at this point too much needs hand tuning for everything to fully utilize the potential of Altivec. Most serious DSP-class apps spend the effort to do this in critical code, but there's plenty of compiled code running in OSX that doesn't benefit from the parallel vectorization that the Altivec unit can offer.

This is all about to change with GCC 4 which offers an SSA tree optimizer. The SSA form is particularly useful for doing automatic vectorization of code. I'm not sure what the efficiency will be like in the first release but it looks like good things are coming.