Slashdot Mirror
Intel Ports Developer Tools to Mac OS X
turnitover writes "According to eWEEK, "Intel Corp. will port its software developer tools to Mac OS X and will ship its first beta later this year, the chip maker told developers on Tuesday at its first-ever session on Mac OS X at the Intel Developer Forum in San Francisco." This, as Apple is working on its first Intel-based Macs, due sometime in 2006. Will the promise of the same feature set and the same tools (for Windows, Mac and Linux) mean the future of cross-platform development is here?"
Is Intel trying to make us forget about all those IBM-powered XBox 360, PS3, and Revolution systems to come?
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
Surely that means that any projects created in the Intel Developer Tools will only run on Intel macs... However the comment that "...Intel has also not considered whether it will support Altivec instructions, a 128-bit vector execution unit in PowerPC G4 and G5 processors. Such support won't be in the early betas..." would suggest that they will be creating universal binaries and supporting PPC, allthough not using these non-Intel processors to their full potential.
I'm not knocking GCC, it's great - but ICC creates the fastest code for Intel processors and probably the fastest code for AMD processors too. I expect a barrage of flames for saying this, but there's loads of evidence out there for it.
Imagine an x86 Mac and a PPC64 Mac (G5) of equivalent specs, running OSX of the right flavour, both compiled with GCC. You'd expect them to both perform the same right? Now take your x86 OSX and recompile it with ICC and you get an immediate speed improvement... wouldn't you?
Just because Apple support GCC (and will continue doing so unless ICC for OSX suddenly becomes free or they start charging for XCode) doesn't mean they shouldn't compile their entire O/S with ICC to take advantage of the speed.
However, what it does mean is that ICC will also plug into X-Code, meaning binaries for Mactel machines will be *fast*. While I don't care for many of Intel's products, their compilers are superb (so long as you're using an Intel chip).
One of the great farces of the PPC Macs, in my mind, was the weight Mac users put into Altivec. Yes, it's a solid vector process, but, as I understand it, GCC doesn't vectorize for Altivec -- meaning, quite simply, that Altivec optimizations had to be done by hand. On the other hand, ICC is generally lauded for its ability to vectorize code in a manner that lends to performance increases thanks to the SSE/2/3 vector units on Pentium chips.
There've already been a lot of reports that OS X on x86 is faster than on PPC, the availability of Intel compilers for the platform will only make that difference more dramatic.
The article states that this compiler WILL NOT produce ppc binaries.
So does this mean that developers who use this compiler will be producing x86 only binaries and ignoring all the existing Mac PPC hardware?
--
Not happy Jan.
If intel's compiler supports in some way those intrinsic functions (A large part might be doable as macros) and maps them to the relevant SSE instructions then Altivec optimized programs would a) still compile b) use the already vectorized code to generate vector assembly. I is beyond me how easily you can map one vector instruction set on the other. There certainly won't be a 1 to 1 mapping.
Of course, the G5 Mac could have its OS compiled with IBM's XLC, and the race would be on.
That's the depressing thing about this change. ICC/IFORT are capable compilers and all, but IBM's compilers ported to OS-X were in a class by themselves. Extremely fast, extremely fast, extremely stable, and compatible with the flags from the AIX versions.
That's what cross-platform means, right? Runs on everything from Macs to AIX-based mainframes.
the more accurate the calculations became, the more the concepts tended to vanish into thin air. R. S. Mulliken
Just like on the G5, I have some apps that have a cocoa/obj-c front end to a pure 64 bit c++-based set of libraries written using xlC for performance reasons. I'll be happy to do the same thing on an Intel-based mac when it becomes generally available (and assuming that it'll also support 64-bit addressing).
Frankly, I don't see the need for Intel to worry about obj-c much...I would think the gains are not really worth it...if you're doing something graphically intense, then you're presumably going to target the gpu, and if it's mathmatically intense, you'd probably want straight C or C++ with templates.
Hell, if I thought it'd be even faster (and I knew how to program in it), I'd write my libraries in Fortran.
The great value of this news is that Intel's First-rate Fortran and Math libraries will be available for the Mactels as soon as they ship. This will ease the transition for scientists, as their codes can be rebuilt and tested on the early Macs, before the replacements for the PowerMacs and XServes ship in '07.
No, it's not XLF, which I would have preferred, but IFort is capable of producing screamingly fast code that generates correct results (generally; there are always the first couple releases of a new version that seem to have issues). It's also already a standard, so the porting from Linux-x86 to Mac-x86 will go more quickly.
Does anyone know if Pathscale plans to ports its compiler suite to OS-X or not? At the moment, I believe that they lead in the X86-64 world, having started with the SGI Open64 compilers, which were based on Cray technology. It would be nice to see them as an alternative as well.
the more accurate the calculations became, the more the concepts tended to vanish into thin air. R. S. Mulliken
will Apple finally stop supporting 9?
I'm just here for the sigs
Actualy. Apple contributes not only to GCC for the PowerPC but also to the ARM back end. I would imagine this is mainly because they use ARM for their iPod. They may also use MIPS for the AirPort (just a guess) as it is based off a Broadcom chipset (and Broadcom usually uses MIPS cores).
So I agree, I think Apple has invested quite a bit in GCC. Oh well, I'm still stuck targetting an m68k board! One of GCC's original targets!
Of course, Apple could modify Xcode and add support for ICC, but it's not just a matter of editing some file... Integration in Xcode of compilers other than what Apple supports out-of-the-box is currently a nightmare.
Donate free food here
Objective-C is really just a thin wrapper around C. All of the runtimes methods are exposed as C functions (take a look in /usr/include/objc/ - you can do some quite shiny things calling the runtime methods from your code). In early implementations, a very simple pre-processor translated Objective-C into C and then compiled the C. It is possible that Apple could return to this route - I don't know how much optimisation is done at the Objective-C level that is not done at the C level, but I suspect it is not a huge amount.
I am TheRaven on Soylent News
Um... REALbasic?
Yup. The FORTRAN compiler often does some good autovectorization. Show me the C compiler does too.
Hell, why not look at this? Ignore the Mac part, just look at the x86 results. Looks like ICC doesn't even beat Visual C++ for most of the tests they did here (at least not by much).
Apart from that, you can do some wierd-ass stuff with AltiVec (and to a lesser effect with SSE/MMX/3DNow) that can never be generated by autovectorization.
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck