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
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Preview Beta of XL C V6.0 and XL C++ V6.0 for Mac OS X. (IB...
- Thread starter MacBytes
- Start date
- Sort by reaction score
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
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 
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/OpenTopic/page?a=tpc&s=50009562&f=8300945231&m=4250963285
arn
Thread's from Ars... they may have some more insight as to how big a deal this is
http://arstechnica.infopop.net/OpenTopic/page?a=tpc&s=50009562&f=8300945231&m=4250963285
arn
"up to +210% in Scalar performacne"
> 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!]
> 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!]
A big benefit...
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...
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...
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.
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.
Re: A big benefit...
That's a pretty safe bet considering it looks like it doesn't do Objective-C.
That's a pretty safe bet considering it looks like it doesn't do Objective-C.
When you take the shotgun-approach to rumor publishing it's not like anyone can be suprised when you finally hit something.
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!
This compiler looks great!
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.
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.
Success, sort of
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).
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).
Re: A big benefit...
NASA's result comparison on a G4 are not "slight" numbers. 70% increase is not something to sneeze at.
NASA's result comparison on a G4 are not "slight" numbers. 70% increase is not something to sneeze at.
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
BEN
MacBidouille is like Rodney Dangerfield
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!
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!
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:
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.
Re: Success, sort of
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.
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.
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,