Considering I don't even think QuantLib XLL runs on Excel for the Mac, this might be a bit of a stretch, but from what I understand, the velocity engine in the G4 and G5 chips makes very short order of any hard vector/matrix processing, so should be ideal for finite difference calculations, option greek visualizations, calibration, or even the occasional least squares monte carlo.

Does anyone know of any software or easy to use libraries that take advantage of this?

For starters, you should write your code using the AltiVec libraries in the (Accelerate.framework) such as vDSP.h, cblad.h, clapack.h.
Compile with the gcc -O3 -framework Accelerate main.c

Then, you can start looking at using an autovectorization optimizer (Such as VAST/AltiVec)

And if that's not enough, start writing your own optimized code (compile using -faltivec). You then can access the AltiVec API in your code and do things like:

vec_add( vector1, vector2 );

Hope this helps.

Yes, rule as far as computation goes.... against Intel's architecture anyway...

However, if you are looking at highy arithmetically intensive operations on lots of data, such as vector math, there is a more specialized solution that allows for order(s) of magnitude of what you could achieve in todays main processors (and no, I don't care how good of an assembly programmer you are: It cannot be done).

CPUs are generally designed with serialism in mind. You may have several pipelines (which, in itself, can lead to problems). This is a conscious design choice as modern CPUs need to be all-purpose number crunching machines. This generalism means that you need an awful lot of so called "control hardware" (Hardware that directs where the computation should go and who should do it rather than performing any computation directly. Remember Turing machine: we need to be able to do pretty much anything).
So, we need to always feed the CPU the right data, otherwise it stalls while the right data is fetched from main memory. This is why modern CPUs have such huge caches (from a surface point of view, alot of the area in a modern CPU is caches: Level 1, Level 2 and Level 3) - So you don't have to take a trip down memory lane all the time!

's AltiVec attempts to to come to grips with data parellalism (applying the same computation to multiple data elements) but obviously does this only for limited bandwith.

Matrix operations are much more efficient when applied the "stream programming" paradigm (Take a stream of numbers, the longer the better and crunch them through a single computation making use of vast data parallelism).

What supports this kind of data parellism? Answer: The GPU

GPUs are very high-bandwith, massively parallel machines. They are progammable stream processors. You can achieve 10 times the speed that you could ever hope to achieve with todays CPUs. And the rift is growing, as GPU speed does not adhere to Moore's law. While a CPU may grow it's capability at 70% a year, modern GPUs are growing at 400% a year.

So, push your matrix operations to the GPU and you don't have to worry about cache misses, branch prediction failures or anything.

A word of caution, while playing around with the GPU for speed purposes may seem exciting, in the way that maybe adding N20 injection to your car is exciting, I can guarantee that your productivity will suffer... alot. While GPU general purpose computation has come a long way in the last couple of years, you can't use it to write overly generic code. Basically you'll be writing a new routine for pretty much everything. While you can see speedups on one or two orders of magnitude for specialized operations (such as exponentiation) it's very likely that the real speedup is perhaps on the order of 2 to 5. XServer cluster nodes cost 3K per pop, so you spend 30K and you got ten times the power.

The best way to learn would be to look at nVidias Cg language (while ATI seems to make more powerful chips at the moment, nVidia does a better job at "tutoring" programmers): Learn about Cg

I know about Cg. It is still not clear to me how one could retrive the results (yes, Cg provides data types like float, float4 etc, but excepting the very recents cards, they don't support it. I could be wrong on this.) other than through the framebuffer. If your friend knows, could you ask him give a pointer?