Slashdot Mirror
IBM Releases Compiler for Power4 and G5
davids-world.com writes "IBM offers its optimized XLC compiler not just for Intel CPUs, but also for its own G5 processor (article in German at Heise). Unlike gcc, it is optimized for the G5 and achieves a major boost in speed, as first results show. I guess we will have to compare the new benchmark data (once available) with the data we get with the optimized Intel compiler for Xeon. The compiler is available for download now."
Does it integrate with ProjectBuilder, XCode or CodeWarrior?
I don't know, you tell me. If not, who will use it?
AndY
This is a preview beta. What will the final product be released under?
Is there some good reason why IBM doesn't just improve gcc? I mean, apple uses gcc; free software users use gcc.. Gcc is a complete compiler suite.
Why didn't they just submit some patches? : )
Liberty.
located here says that people are seeing nearly a twofold increase in both G4's and G5's. I lifted this next spec directly from their discussion: (XL improvement over Absoft and GCC 3.3): Type of Code G4 G5 Scalar +70% +210% Vector +40% +70% _If this holds that places his _2.0GHz G5 (single)_=254 at _787__ Note also that the _P4 2.66_ is _255_. This is a big deal. Let's just hope they use this to compile the OS.
Xcode, the new compiler/IDE, which is based on gcc, is also optimized for the G5.
For more information, see Apple's Xcode site.
-- Fighting mediocrity one bad post at a time.
It is good to see IBM ending the habit of charging extra for the C compiler. AIX hasn't bundled the compiler since 3.2.5.
Um, that's the point. IBM cooks up code to make the G5 look as fast as possible. Intel cooks up code to make the Xeon looks as fast as possible. Now compare. Fastest code/chip against the competition's fastest code/chip. The complaint in the past was that it was always the fastest code/chip of one side against a non-optimized code on the other side. Now we can have a fair shootout.
-T
Since OS X.x has BSD underpinnings, why not just compile it on x86?
Running OS X.x with MS Orifice seems like the sweet spot for stable OS/file format compatibility in the proprietary world...
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
I wonder how the AltiVec support in XLC for OSX compares to that in GCC?
This is actually really important. One of the big reasons that the Intel C compiler spanks every other available x86 compiler is that its SSE/SIMD support is, in the words of one of my assembly-programmer friends, "awe-inspiring." Like, unrolling entire program loops and replacing them with single SIMD instructions.
As far as I know, pretty much all of the AltiVec/VMX support in GCC was contributed by Apple and Motorola, and prior to the ppc970, IBM has never produced a PPC CPU with AltiVec instructions, so prior versions of XLC have never had to support it. So I'll be really curious to hear how it stacks up against GCC's Altivec.
News for Nerds. Stuff that Matters? Like hell.
(Disclaimer: I used to work for IBM Research. This is not inside info.)
The XL line of compilers has a long and glorious tradition. What matters most here is compatibility with existing code. IBM doesn't optimize XLC so you could get a faster kernel, it optimizes XLC so they could recompile DB/2 on AIX and get faster results; and also, obviously, for many of their other products. Another consideration is those clients that have a large codebase used with XLC.
The world of C/C++ is rather sad in that code is not only non-cross-platform in most cases, it is also commonly unlikely to compile using a different compiler on the same platform. Moving from XLC to gcc would mean throwing away an investment of decades in the compiler, not to mention the huge amount of work required to port the source code of products such as DB/2. So IBM helps gcc, and also invests in XLC. There's no conflict here. I would not be surprised if many of the various optimizations employed by XLC will eventually find their way to gcc -- by the very same IBM researchers.
BTW, talking of optimizations, people in IBM Haifa have developed an amazing post-compile optimization tool
. Now, seeing an open-source version of that would be cool. Not very likely, though, since this is the source for some of the performance edge DB/2 has over its competitors.- Tal Cohen
Plus, the team working on this compiler would probably take several man-decades---if ever---to become as fluent and comfortable with gcc as they are with their own code.
(Disclaimer: I work for IBM. In fact, I work on a compiler for IBM, though it's neither this compiler nor gcc. My opinions don't reflect those of IBM.)
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Virtual PC doesn't run on the G5 because of it's lack of pseudo little endian support.
-- oldthinkers unbellyfeel ingsoc
Unless raw CPU isn't your only deciding factor (frankly once you get over 1 GHz I really don't care, I'm not sequencing DNA here :) ). For me I know it is a technically inferior processor, but being able to run OSX was worth the minor trade off in raw CPU speed I got by getting a G4.
But hey, to each his own.
Finkployd
FDPR is much more advanced that GNU Rope; it actually optimizes the code in addition to reordering it.
The IBM compiler dis some wild instruction reordering which made the optimized compiled code really hard to understand, but somehow better fitted to the processor's pipeline structure. Fortunately the only thing that broke when I turned on the optimizer was the "marching ants" used for selection, and that was the result of some way-too-fancy-casting of Pattern pointers that fooled the optimizer. I suspect the IBM compilers will continue to reign if performance is the goal.
Actually, I work part-time in a lab that does DNA sequencing, and the machines they have doing the sequencing are all Macs, even though there's plenty of Suns and Dells around.
Karma: Ran over your dogma.
Huh, maybe I'm all backwards on this then. My understanding from our HPC guys is that Apple hardware is not up to par with that they do. Were the Apple's picked due to processing speed, or software considerations?
Finkployd
Anyways, back to your problem. If you copy with the shell or with any other file manager on the Mac it will be considerably faster.
As for Adobe Acrobat, I don't know what is wrong there. I installed it in just a few minutes without any problems.
However I must ask if you are for real. Sorry but just today have reports of dual G5's come out. That you "recently upgraded" sounds a bit doubtful. I don't know anyone with a dual G5. That you say your iPod stopped working and Safari isn't working during a copy makes me think either you have a flawed pre-release machine or are just blowing air. My apologies if you are legit. Just doesn't sound right.
Very often, that "native" compiler either doesn't exist (because even the vendor is using gcc), or is prohibitively expensive for a startup company.
It's best to approach GCC like Java: use it to prove the correctness of your app, then profile profile profile and insert inlined assembly into your bottleneck points. Remember your Brooks: 90% of all optimization is premature.
News for Nerds. Stuff that Matters? Like hell.
IBM's benchmarks comparing gcc and xlc on SPECint2000 and SPECfp2000 seem not very meaningful to me. First of all, note that both -O2 and -O3 are semantics preserving in gcc, while -O4 and -O5 in xlc are not. That is, in particular on the SPECint2000 benchmarks, the xlc compiler is faster simply because it changes the behavior of your program. The same may even be true for xlc compiling SPECfp2000 at lower optimization settings; the Intel compiler on P4, for example, achieves large gains in performance on some benchmarks by inlining math functions that gcc uses a library for--because the P4 instructions aren't quite right.
In my experience, you can usually match the performance of those other "fast" compilers with gcc by using the "-f" and "-m" flags. The main difference is that gcc forces you to be explicit about which semantic changes the compiler is allowed to make, rather than lumping things together under some generic "-O5" setting. That's a good thing.
(Note that my comments apply to gcc; g77 may well be a much worse performer than commercial Fortran compilers even though it shares the same back-end with gcc. That affects the SPECfp2000 scores. Fortran just doesn't seem to be a high priority for gcc.)
It's got altivec in the CPU which can speed up vector computations dramatically - photoshop on mac also uses altivec optimalizations which is why its so very fast compared to photoshop on a comparable intel. I bet the dna sequencers use the altivec. (prolly ppc linux w gcc)
Of those to whom much is given, much is required.
The G4's are much faster for sequencing since they use a better SIMD than the Intel's. Performance wise the G4's rock, and IBM's new compiler for OSX should not only catapult the G5's but benefit the G4's as other benchmarks are already showing. IBM is a much better partner than Motorola for Apple. It's the kind of partner Apple needs to win their competition with Wintel in the enterprise. All of a sudden the G4's are given a new lease on life. Expect to see a G4 equivalent from IBM soon on a 90nm process.
Hmm... lets see... you're comparing a processor to a full system. Apples vs. Oranges.
Lets do some real analysis... top server vs. top server:
vs.
And this isn't even from big boys like Dell (who wouldn't be caught dead using AMD)... just a bottomfeeder from pricewatch.
Now, the G5 has all sorts of desktop/workstation goodies built in (Radeon 96/9800 Pro, awesome sound, good looks), and the with AMD server, you can cut corners with things you don't want in a server, like soundcard, highend video card, etc.
My point? im sure we're still comparing apples to oranges. People who want a mainstream kickass workstation will love to buy the G5. People who want beowulf node clusters or inexpensive uberservers will love the Opteron. I just wish I had either :-)
Make sure everyone's vote counts: Verified Voting
So, here is that compiler.
Yes, and this is exactly what a lot of us (scientific users) were asking for. Looking at the individual SPECfp benchmarks most similar to our application, we expect about 30-40% improvement over gcc. This puts the Mac almost on par with x86 solutions when it comes to flops/$ (we never pay list price for x86 machines in academia; unfortunately the Apple discount is only 10-20%).
During the past decade I've been working on Sparc, Alpha, Power4, Pentium, Athlon, and Cray CPUs. Apart from a very short period in the 1990s when then G3 appeared this is the first time Apple is truly competitive.
What I wonder is whether this compiler will be used in future versions of xCode. If it is, in fact, significantly faster than GCC, it seems logical that Apple would wants it as part of their own developer tools.
In addition, I wonder what this will do for Metroworks' CodeWarrior compiler?
"Reality is merely an illusion, albeit a very persistent one " -Albert Einstein