Red Hat To Support PowerPC, AltiVec

Steve Cowan writes "According to an article at MacCentral, Red Hat has announced that they will produce a GNUPro toolchain and cross compiler for AltiVec-enabled PowerPC processors (such as that found in the Power Mac G4). It will be interesting to see just what kind of performance gains this will bring, because many believe that the full potential of AltiVec is far from tapped."

Comments

The real worth here...

[Venomous Louse]

The real worth here lies in the fact that MacOS X is, let's not forget, essentially a UN*X platform. If RH play their cards right on this one, we should start seeing GNU tools perceived as a technical leader where in the past they've been perceived as something more like a reliable least common denominator.

Free software has to grow. It still needs to prove itself to make that happen. It's good to see RH concentrating on something genuinely forward-looking.

It will stay untapped.

[Erich]

Parallelism is really, really, really hard to do in a compiler. Intel has a hard time doing it even after spending millions for a compiler on their VLIW architecture. DLP is typically even harder than ILP for a compiler to do.

Compilers can typically do a pretty good job on sequential machines, but there is still a long way to go for getting good parallel code. Hand coding things is still the way to go for maximum performance.

That being said, the compiler can probably use it some, and having a resource available is typically better than not having the resource at all.

Re:It will stay untapped.

[RobertFisher]

I don't agree with this author's assessment. The type of "parallelism" involved in the AltiVec is SIMD -- single instruction, multiple data. It's the same kind of parallelism which Cray pioneered over 25 years ago. While in the early days, a great deal of hand-tuning was required, leading to such memorable Cray-specific replacement constructs as the vectorized Cray vector merges (CVMGT, CVMGZ, CVMGP, etc...) in place of non-vectorized If-Then's, great strides were made in Cray's compilers over the last few years. You could get very reasonable vectorized performance for most numerically intensive codes straight out of the compiler, without any modifications at all. With a bit of profiling and additional compiler directives, you could get excellent performance indeed.

The plain fact of the matter is that SIMD is MUCH, MUCH easier than doing distributed parallelization. It took Cray about 20 years to really get it right, so given how new the Altivec is, let's give Apple and company a few years to see how much they can accomplish.

Bob

Re:It will stay untapped.

[Erich]

I don't agree with this author's assessment. The type of "parallelism" involved in the AltiVec is SIMD -- single instruction, multiple data.

Right, DLP (Data Level Parallelism) instructions. Exploiting parallelism in the data rather than the instructions. The G4 actually has a really nice set of DLP instructions, and some of the "Single Instructions" (from what I understand) actually allow you to do different operations on different parts of data -- wich is nice.

The G4 also has ILP features -- it's a superscalar architecture can issue several instructions in a given cycle.

But the ILP features are done automatically in hardware, and hardware doesn't have the "big picture" that the compiler (or person writing assembly code) has. Architectures that define parallelism explicitly (like VLIW (EPIC) architectures) tell the hardware what can go in parallel and what can't. Unfortunately, the compilers for VLIW architectures have a hard enough time doing good ILP code; DLP code is even harder.

For instance, you have c code:

c = a+b;
d = e+f;

Say that these are in packed words in the register file. Perhaps the compiler can write "add2 r0,r1,r2" and do both of the adds at the same time. It should be even easier to not keep track of packed words and say "add r0,r1,r2 & add r3,r4,r5", where add instructions are explicitly defined as running at the same time. And compilers can usually do this OK. It's very hard for compilers to software pipeline loops and such, which is what provides the biggest benefit.

You could get very reasonable vectorized performance for most numerically intensive codes straight out of the compiler, without any modifications at all. With a bit of profiling and additional compiler directives, you could get excellent performance indeed.

But GNU C isn't designed to be a vector compiler, it's designed for single-issue, non-DLP (SIMD == DLP) architectures. Sure, giving it vector and DLP or ILP resources might let it use the things once in a while, but for the most part it will go unused.

Don't expect huge speedups everywhere without hand-tuned libraries.

Honestly no,

[macdaddy]

at least not to me. OS X currently can't replace my PPC Linux needs. I need a box that's garunteed to run for long periods of time (2+ years) as a rock solid and stable system. I need to be able to run it headless, without a GUI, or replace/upgrade the GUI to fit my needs or fix it as needed without rebooting. OS X doesn't give me these things (yet).

I'm old school Mac. I've been using them for a long time (not nearly as long as some though). I love the Mac GUI. It's consistent and fits my graphical needs. I love the useability of Linux and the power it affords. Not to brag but I'm a fair admin of redhat-styled Linux boxes. I pride myself on my security while still being usable. I know both very well. That's why I always use a Mac and Linux box in pairs. The Mac is my GUI and that box has 3-4 terms open on the Linux box (or VNC). I integrate both. OS X is neither. I can't call it a Mac OS because it's just so damned funky. They had a great GUI and had to go and change it. For someone just starting out on Macs or not that familar with one, this is probably not a big deal to you. For someone like myself, it's a damned nightmare. The *nix underpinnings really aren't like any *nix I'm used to. Not Solaris, Linux, IRIX, or any of the BSDs I've played around on. It just isn't the same thing. The learning curve for a person in my position is incredibly steep. Now the OS kicks ass, don't get me wrong. It's amazing how good it is for the first (major) release of a completely new OS. I can't wait until the next major revision though. Maybe 10.5 or something similar. They are bound to fix the quirks that hurt most of us. They're bound to make it even better. Maybe then I can justify forcing it on myself. For now I only run it on my network sniffing box. Until it gets better, I'll stick with 9.2.2 and my Linux terms.