Preview Beta of XL C V6.0 and XL C++ V6.0 for Mac OS X. (IB...

[MacBytes]

Category: 3rd Party Software
Link: Preview Beta of XL C V6.0 and XL C++ V6.0 for Mac OS X. (IBM is preparing its industry-leading C, C++ and Fortran compilers to exploit the Apple PowerMac G5.)

Posted on MacBytes.com

Approved by arn

[Nermal]

Does this need the G5, or will it run on older systems? Also, how is this any different from Apple's developer tools with the G5 patch? I don't know that much about programming

[Sun Baked]

Kool,

Possibility of a zippy-fast compiler for the G5 to replace the slug called GCC.

Should be interesting to see the comparison of the code generated between XL C6.0 and GCC 3.3 for OS X.

[arn]

here's a thread from Ars that someone sent me.

Thread's from Ars... they may have some more insight as to how big a deal this is

http://arstechnica.infopop.net/OpenT...1&m=4250963285

arn

[Catfish_Man]

Very impressive results on the NASA benchmark. +210% scalar performance is nothing to sneeze at.

[centauratlas]

> up to +210% in Scalar performacne <

I have read that Clearasil will clear up that "performACNE" right up. ;-)

[I am sure the typo will be corrected soon!]

[adamfilip]

Wow this is MAJOR news!!

im not even kidding.


kicks A$$

[centauratlas]

I think (after reading the ars thread), that a big benefit will be re-compoling the OS with this. It looked like it wasn't only G5s that benefitted, but G4s and G3s could benefit slightly (e.g. very small %s) too. I am about 99.99999999999999999999% sure that they wouldn't recompile Panther with it now if they are anywhere close to release, but if/when they do, it should give another nice performance boost to the areas not already well-optimized for the G5 and perhaps slight ones for the G3/G4...

I am presuming of course that Apple is still using gcc for 10.3 and not a pre-release version of this. Lots of ifs without more digging...

[Powerbook G5]

This is great, the systems are just now shipping and already we have news that these things can become even faster than we first thought by just an update or two. Perhaps it's just all these years of being stuck with Motorola, but I am not used to seeing so much positive news about increased performance like this.

[adamfilip]

im going to assume that ibm and apple have been working on this and that apple has had their hands on a early version for panther.. there is no reason why apple wouldnt be in the loop..

[centauratlas]

Originally posted by adamfilip
im going to assume that ibm and apple have been working on this and that apple has had their hands on a early version for panther.. there is no reason why apple wouldnt be in the loop..

I would agree they had early versions, the question is though whether they'd use a beta (or before today, an alpha) compiler to compile the OS. I think the odds are low of that because you'd be fighting compiler bugs *and* coding bugs at the same time. I presume that xcode was probably used with gcc where needed since they were well tested.

[andyduncan]

Originally posted by centauratlas
I am about 99.99999999999999999999% sure that they wouldn't recompile Panther with it...

That's a pretty safe bet considering it looks like it doesn't do Objective-C.

[manu chao]

To polish macbidouille's reputation a little bit, the first time I heard about this was in June (26?) when macbidouille reported that IBM would port its C++ and Fortran compilers to Mac OS X.

[andyduncan]

Originally posted by manu chao
To polish macbidouille's reputation a little bit, the first time I heard about this was in June (26?) when macbidouille reported that IBM would port its C++ and Fortran compilers to Mac OS X.

When you take the shotgun-approach to rumor publishing it's not like anyone can be suprised when you finally hit something.

[tizza]

All I have to say is that IBM and Apple have a far better marriage than Apple previous partner (grrr Moto grrrr)

This compiler looks great!

[mim]

Originally posted by Sun Baked
Kool,

Possibility of a zippy-fast compiler for the G5 to replace the slug called GCC.

Should be interesting to see the comparison of the code generated between XL C6.0 and GCC 3.3 for OS X.

I don't think they expected to be using GCC for everything - it just helped with their original benchmarks so that the PC crowd couldn't complain about unfairly optimised compilers (go figure - surely that's the point?) and lend some credibility to some of the cross platform tests.

The 970 when demoed started out pretty strong. These continuing developments to take advantage of all it has to offer will make the G5 seem truely outstanding methinks.

[themadchemist]

Originally posted by andyduncan
When you take the shotgun-approach to rumor publishing it's not like anyone can be suprised when you finally hit something.

to be fair, though, this isn't like a 15" powerbook rumor that everyone and his grandmother could (and does) come up with.

To report something like this, which has a niche audience of interest and a more technical bent, I imagine macbidouille must have had some actual evidence...Or a great deal of creativity.

If you ask me, MacBidouille's problem is that it feels that it accepts rumors with a very low burden of proof. In other words, it has its sources, but MOST (not all) of them are crap.

[manu chao]

Andyduncan, actually they published this info back than as news, not as a rumor, which shows they were able to judge the credibility of their source quite well.

[Scott Smith]

I got the xlc (the name of IBM's compile) to install and work on my G4 12" PB.
This is just another confirmation to the previous statements about it working on earlier machines. I don't have a G3 with me, so I can't check that.

So now the question, how does it do.
A couple weeks ago, I wrote a small program to try my hand at altivec and see how much faster it is in a test of something I might do.
For those that can read C, it was basically this:
main()
{
... // Declaration
for(i = 0; i < 1000000; i++) {

// When I would compare scaler to altivec, I would comment out the next two lines, or the last line depending.
// Scaler part
for(j = 0; j < 1024; j++)
fr[j] = f2[j] + f1[j];
// altivec
vadd(f1,1,f2,1,fr,1,1024);
}

It is somewhat more difficult to compile the altivec version, this is true for the xlc and for gcc, because you have to set some flags and what ever else.
Here are some time results:
The best case for improvement was the scaler with the compiler optimizer turned off.
TinyAl:~/Programs/altivec] jsmith% time xlc_test_scaler
25.480 sec
[TinyAl:~/Programs/altivec] jsmith% time gcc_test_scaler
34.570 sec

The next is the optimizer turned on, but still scaler:
[TinyAl:~/Programs/altivec] jsmith% time xlc_test_scaler
0.010 sec
[TinyAl:~/Programs/altivec] jsmith% time gcc_test_scaler
6.090 sec
I am pretty sure that xlc was able to detect my "dumb" for loop, and only did it once. This just means that the optimizer is smarter. I did recompile it several times, and looked at the output to make sure I didn't make a mistake.

Now, lets look at altivec operations:
First, let look at the not optimized case,
[TinyAl:~/Programs/altivec] jsmith% time xlc_test_altivec
1.350 sec
[TinyAl:~/Programs/altivec] jsmith% time gcc_test_altivec
1.330 sec

Notice that the gcc is slightly faster than the xlc, at this time, I should have really increased the size of the loops to get better data, but I'll let a real bench mark do that.
Now, for the optimized altivec.
[TinyAl:~/Programs/altivec] jsmith% time xlc_test_altivec
1.290 sec
[TinyAl:~/Programs/altivec] jsmith% time gcc_test_altivec
1.300 sec

Note, that the is NOT a good benchmark. I am just sharing some results of a test I ran. For those geeks who know what the output for the "time" command, I changed it for helping everyone else to read it.
I am in the process of checking some of my other code, but I'm having trouble getting it compile (mostly my fault for writing compiler specific code and makefile).

[tiktokfx]

Originally posted by centauratlas
I think (after reading the ars thread), that a big benefit will be re-compoling the OS with this. It looked like it wasn't only G5s that benefitted, but G4s and G3s could benefit slightly (e.g. very small %s) too.

NASA's result comparison on a G4 are not "slight" numbers. 70% increase is not something to sneeze at.

[saabmp3]

Wow, this is seriously bigger than the announcement of the G5's itself (ok, maybe upcoming panther). Think about it, if your a programmer, you know that the compiler is your biggest variable. For people talking about new hardware, remember, you need software to optimize the hardware. Without developments like this it would be akin to running Windows 3.1 on a over-clocked Barton @ 3.2.

BEN

[rjwill246]

Originally posted by andyduncan
When you take the shotgun-approach to rumor publishing it's not like anyone can be suprised when you finally hit something.

Not so fast! Macbidouille, who also nailed the exact supplier of the new Power Macs are leading everyone right now with their factually based rumours. Mmm .. now about them PBs.... really, give them SOME respect!

And I am being facetious! Macbidouille, je t'aime beaucoup parceque tu as raison plus souvent que les autres! Baisse- baisse.. MMMMMmmm delicieux!

[jettredmont]

Originally posted by adamfilip
im going to assume that ibm and apple have been working on this and that apple has had their hands on a early version for panther.. there is no reason why apple wouldnt be in the loop..

1) The compiler doesn't support Obj-C or Obj-C++. So, obviously not.

2) Apple has been quite vocal that GCC is its internal compiler. Not Code Warrior; not IBM. GCC.

So, the answer is: "No, Apple has not been using this compiler."

Theoretically, the core libraries might be able to be compiled with the IBM compiler, assuming is emits libraries using the gcc 3.3 ABI (which, actually, I rather doubt), but the Obj-C stuff obviously is not (unless they had an Obj-C-to-C compile step, then a C compile step on IBM's compiler ...)

[edit:

Looks like the IBM compiler does adhere to the GCC 3.3 ABI, so it is possible that the low-level libraries of Panther could be compiled with it and the front-end Cocoa interfaces with gcc:

Portions of an application can be built with XL C++ for Mac OS X and combined with portions built with gcc to produce an application that behaves as if it had been built solely with gcc.

I stand corrected.

However, as I said before: Apple has been quite vocal about "using its own dogfood" with gcc. I don't remember anything coming from this year's WWDC specifically saying that as an overall statement as they had said last year, but I do have confirmation that many low-level systems for Panther are compiled using gcc, not any other compiler.

[jettredmont]

Originally posted by Scott Smith
I got the xlc (the name of IBM's compile) to install and work on my G4 12" PB.
[ ... ]
The next is the optimizer turned on, but still scaler:
[TinyAl:~/Programs/altivec] jsmith% time xlc_test_scaler
0.010 sec
[TinyAl:~/Programs/altivec] jsmith% time gcc_test_scaler
6.090 sec
I am pretty sure that xlc was able to detect my "dumb" for loop, and only did it once. This just means that the optimizer is smarter. I did recompile it several times, and looked at the output to make sure I didn't make a mistake.

Yes, the gcc compiler is pretty darned dumb regarding optimizations. You have to do them yourself, and if you're relying on the compiler to do them you generally are going to get less-than-optimal performance out of gcc.

[daveL]

Originally posted by manu chao
To polish macbidouille's reputation a little bit, the first time I heard about this was in June (26?) when macbidouille reported that IBM would port its C++ and Fortran compilers to Mac OS X.

OS X isn't written in Objective C. The code base for the OS is from BSD 4.4, which is all C/C++. Objective C shows up in Cocoa; it's mainly used in the UI frameworks. Since most modern compilers have a frontend parser and a separate backend code generator, it wouldn't be that big a push to add an Objective C parser to the IBM compiler's code generator. Given how closely Apple and IBM have been working on the 970, I would think the Objective C parser is already in the works.

[EDIT] Sorry, I quoted the wrong post. This reply was intended to address the post by AndyDuncan,