Slashdot Mirror
IBM Releases XL compilers for Mac OS X
Visigothe writes "IBM released their XL Fortran Compiler and XL C/C++ Compiler for OS X. The compiler is binary compatible with GCC 3.3, and has multiple levels of optimization, creating binaries that are much faster than their GCC-compiled counterparts." No prices are noted, and the planned availability date is January 16.
Has anybody seen any useful benchmarks of compiler output comparing XL and GCC on PowerPC?
That would be interesting to see.
Very cool! Looks like the C/C++ compiler also has support for Objective-C now. Even if it's in the form of a "technology preview" and probably preliminary.
This means that this could well be usable as a replacement for GCC in developing Cocoa-based apps. It's good to finally have some options. Can't wait to see how well it works!
According to an Ars thread the XLC compiler will be $499 for a single seat license. WAY below the cost for the AIX versions.
Linkage
I hope you die painfully and alone.
What does Apple use to compile OS X - and if IBM get the Objective C sections woking properly, could Apple use the IBM comiper to get OS X to run faster?
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
I'm not 100% sure but I seem to remember in the WWDC keynote Jobs saying it was built with gcc3.3 the version that ships with Xcode.
Ya probably. I was surprised that they implemented Vector support so quickly. XLC really shines on Floating Point code, but I'm really curious to see how well it handles Vector. Even if the whole operating system isn't compiled with xlc as long as the core libs and things like codecs for QT and other multimedia apps the speed up would be impressive.
I hope you die painfully and alone.
Binary compatible means same data layouts, same parameter-passing conventions, same conventions for shared libraries and position-independent code. However, between those interfaces, the generated code is probably different.
Think of it like nuts and bolts -- a nut and bolt are compatible if they have the same diameter and threads per inch, but they may be made of carbon steel, steel, bronze, nylon, titanium, whatever.
As for commandline switches and such, I would assume that they would be the same (or that there would be a simple option like --gcc that would turn on "gcc mode" so that it took the same command line stuff).
PS: If I'm wrong would someone please reply and correct me, and not just mod me wrong?
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Weren't these compilers supposed to bring automatic conversion of multiple 32bits arithmetic operations into Altivec-accelerated code ?
Maybe we deserve this world ?
"binary' refers, indeed, to the binary compatibility of object files; in GCC terms, when there's an "ABI" change, you have to re-compile all applications, as new stuff compiled in the new Application Binary Interface can't access stuff compiled in the old ABI.
What it REALLY means:
1) You can compile the majority of your application in GCC, and selectively compile in IBM's XLC.
2) You can compile one library in XLC, and link it in to your GCC application.
3) You can compile a library in GCC, and link it in to your XLC application.
Etc. You get the point. Essentially, while the code they generate is very, very different in terms of optimization and performance, they are, in fact, completely interchangeable in terms of the things they produce as output.
XLC is, in fact, a very different beast than GCC. The number of optimizations it provides goes well beyond what GCC currently provides, and does include auto-vectorization and support for OpenMP - things which don't suck on parallel systems.
So XLC is a good thing for commercial software developers, and at minimum, the compatibility of the systems means that we as developers have no excuse not to be compiling, at bare minimum, the most *important* functions (and if we're doing it this way, it might as well be specific functions) in XLC, and link in that parallelized and optimized object file into our existing project.
As for commandline switches... nope. Almost never compatible. No hope. Basic stuff is mildly similar, but the guts you'd use once optimizing are very different.
But at a high level, yes, you just say xlc -O3 instead of gcc -O3, only you might say xlc -O5.
-- A mind is a terrible thing.
The only problem being that XLC doesn't support G3 Machines, so it would be impossible to create a binary that runs on any Mac, as is currently supported by GCC. In theory they could make separate binaries and install the 'correct' one, but that poses problems for systems booting off of external hard drives (which binary do you put on the drive?) and booting over the network. The ability to carry around a copy of OSX on your iPod is a powerful thing, and not one most people would give up lightly.
Of course, this could have been gotten around by using Bundles, which is a folder that acts like a double-clickable application. The structure is:
SomeApplication.app/ <-- The application
Contents/MacOS/SomeApplication <-- The OSX binary
Contents/MacOSClassic/SomeApplication <-- The OS9 binary
Contents/Resources/Blah.jpg
Contents/Resources/Foo.tiff
It chould be:
SomeApplication.app/
Contents/MacOS/SomeApplication <-- The generic binary
Contents/MacOS-G3/SomeApplication <-- The G3-optimized binary
Contents/MacOS-G4/SomeApplication <-- The G4-optimized binary
Contents/MacOS-G5/SomeApplication <-- The G5-optimized binary
Contents/Resources/Blah.jpg
Contents/Resources/Foo.tiff
When you double-click, it uses whatever binary is appropriate for the system. Unfortunately, this doesn't work for Frameworks, which lack the notion of platform.
A rant to beat the lameness filter: this bundle format should be adopted everywhere. It allows for a folder to be used as an application, and to contain all the resources it needs to be used and run. Moving the folder moves the application, and the folder doesn't use any vodoo to keep the data together, as pretty much any HD format understands folders and files.
In addition, the multiple-binaries trick (as shown above working with OS9/X and proposed for processors) would allow the same bundle to work on muluple platforms, so I could email you a zipped version of Office from my Mac that could work on your Wintel, no Java required.
The support is in the Finder/Explorer/Browser, which needs to understand that 'double click on bundle' == 'find correct binary and launch it'.
- The Amazina Llama