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.

Re:The real worth here...

[Arker]

The real worth here lies in the fact that MacOS X is, let's not forget, essentially a UN*X platform.

I don't see what that has to do with anything. We're talking about porting the toolchain to the hardware. This has nothing to do with MacOs 10 at all. It's about Linux/PPC.

Linux/PPC has been hampered for quite awhile by the lack of good GCC support for things like AltiVec. Performance suffers from lack of optimisation. It sounds like RH is undertaking to fix that. This could be very cool - if they succeed then Linux/PPC programs will be able to take advantage of the full power of the PPC chips. AltiVec doesn't help with everything, far from it, but code which it does help will see truly impressive performance gains.

If you're not clear on what AltiVec is, try the link out. Basically it's MMX on steroids. It does everything MMX does, better, and some other things besides. It's really very cool tech, and it will be very nice to see Linux/PPC software finally taking advantage of it.

Re:The real worth here...

[tshak]

As cool and powerful as AltiVec is (arguably a more powerful SIMD Instruction Set then SSE2), I'm skeptical as to how much additional performance gain there will be. My skepticism was renewed when John Carmack made this post.

Time to convert all those Mac users ;)

[IamTheRealMike]

Well, maybe. OS X is pretty nice, but that's another story.

Last time my Mac-lover best mate tried Linux the poor quality and performance of Linux PPC ports frustrated him. I pointed out that it's catch-22, having lots of fanatical MacOS users means very few try other operating systems, which means there's little incentive for linux companies to make decent ports and so on.

Problems were really apparent - for instance he tried a distro that was for PPC, but it had no Mac customisations what so ever. It just assumed he was using a 3 button mouse for instance. Hopefully if Red Hat do this properly, rather than just use a fancy compiler, OS X will have some competition on its home ground.

Re:Time to convert all those Mac users ;)

[Anonymous Coward]

RedHat's GNUPro (the old cygnus stuff) is what's being touted ... that'd be the compiler and tool chain.

This is not a new redhat Linux distro.

this is Cygnus, not Linux news

[Anonymous Coward]

The article is about a release of GNUPro tools that support Altivec, not optimizing the linux kernel to use Altivec.

As to the question of "what will this bring since altivec is underused/underappreciated?" the answer is simple: nothing.

The same problem remains: if you want to optimize your algorithm using Altivec, you still have to jump through some hoops. GCC isn't magically going to detect that your for loop could be done 400 times faster using Altivec: you'll need to tell it.

In short, you can do everything you need to already using the existing tools from here.

Just-another-tool does not news make.

Huh?

[Jeffrey Baker]

I doubt this will produce any performance gains at all. Code will still need to be written specifically for the AltiVec unit, using either the C extensions or assembler. A simple recompile will not bring any gains, unless RedHat are able to improve GCC's PPC code generation.

BTW, GCC and binutils already support the AltiVec, including the C extensions.

Isn't this just rolling back Apple changes?

[stevek]

IIRC, Apple (perhaps with motorola), has already put all kinds of AltiVec stuff into GCC for use as the OSX system compiler. Apple has been working on their own GCC tree, but has always been feeding some stuff back up to the GCC maintainers.

Isn't this just some marketing hype for RedHat (nee cygnus) just taking the patches already incorporated into Apple's GCC, and putting them into their commercial GCC release?

I don't know how GCC compares to Metrowerks' Compiler, or what Apple is using for different parts of their code (I dunno if MW does OBJ-C, so Apple would likely use GCC at least for that).

I suppose it wouldn't be too hard to look at the binaries and see what they're using.

-SteveK

Re:Isn't this just rolling back Apple changes?

[devphil]

Uh, no. Not by a long shot.

First, the changes that Apple made to their own version of GCC were not well thought out. Those patches can't simply be applied to the real GCC.

Second, I don't know what "commercial GCC release" you're talking about. The AltiVec patches have been going into the publiv version of GCC for weeks now. Check their mailing list archives for all the gory details.

Probably won't help mac fans.

[Eric Seppanen]

My guess is that they're doing this for embedded applications. Remember that Red Hat does a fair amount of business in the embedded arena, and PowerPC processors are pretty big in embedded applications. So while their work on the compilers will benefit everyone, including people running Linux on their Macs, this doesn't mean you're going to see a PowerPC version of Red Hat Linux any time soon.

Re:RedHat on new Macs?

[chainsaw1]

Motorola and IBM parted ways at the G4. The Power4 doesn't include AltiVec....IBM wanted to use the on-chip real estate for other things.

Also, the Power4 is a 64bit chip, and the G4 is still 32bit.

Re:It's got a lot to do with OS X

[Arker]

Don't get me wrong, it's great to see Linux able to take advantage of AltiVec. You can deride graphics as "fluff",

And Lord knows I have, often enough. :) But seriously, it has its place, PPC is great hardware for it, and up until now Linux/PPC has been hobbled by not being able to take real advantage of that fact.

However: How many PowerPC boxes are running Linux, and how many are running OS X? And which is a more high-profile market?

*shrug* Who cares?

This still has nothing to do with OS 10. It has to do with Linux/PPC.

I take that back, indirectly it does have a little to do with OS10. Because Mac is using that horrid slow Mach kernel, and still performing as well or better than Linux/PPC, because of better optimisation. RedHat is poised to eliminate that gap, and make Linux/PPC a much more attractive system.

Linux, furthermore, is a "market" that GCC already owns. I know, I know, you can retarget from wherever, but making GCC a viable, and in some senses technically superior, choice for OS X development can only be a good thing. Can you compile Carbon apps w/ GCC? I have no idea, but if not, in eight months you will.

From where on earth are you getting all this?

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.

Re:RedHat on new Macs?

[Brian Kendig]

'Darwin,' the FreeBSD-based core of OS X, is open source:

http://www.opensource.apple.com/

The interface, Aqua, isn't open-source because Apple wants to retain control of it.

I wouldn't call OS X 'largely untested.' It's directly based on NeXT's OPENSTEP operating system, which was known for being very stable and having great developer tools (the game 'Doom' was written on NeXT systems because of this), and OPENSTEP has lineage back to 4.3 BSD.

What's especially interesting is that Darwin runs on Intel PC's. This means that if Apple wanted to make Mac OS X available as an alternative to Microsoft Windows, all it would theoretically take is a recompile for the x86 architecture...

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.

Re:Good way to make inroads.

[masonbrown]

And maybe, then Adobe will drop Photoshop on Windows, and make everyone use Linux. And maybe then, Microsoft will go out of business. And maybe then, Adobe will open source Photoshop, and make it free for everyone. And maybe then, Apple will give away its computers as free community property.......