Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
plinden said:
It just provides another option for compilation. Programs compiled with the Intel C compile consistently show higher benchmark performance than applications compiled with e.g. gcc. Hence the remark about accusations that Intel write for benchmarks ... having been out of the C/C++ field for several years, I don't know what the true impact is on real applications.

(400th post in 14 months - getting closer to my avatar)

I can speak a little bit to what the Intel compiler can do for real applications. I wrote a 3D plug-in a few years ago that I was going to do some SSE optimization with. At the time I was compiling with VC++ 6.0 I think. Since VC++ didn't support SSE at the time I picked up the Intel compiler. Of course first thing I did was recompile (no code change) and test. With absolutely no changes in what we were doing, render speed on our test files jumped 40% for things that used this plug-in heavily!!! The Intel compiler rocks!

Ultimately we rewrote the plug-in and the new algorithm which gave an even bigger boost in performance did not benefit nearly as much from an intel compile (a few percentage points), but for some applications there are big gains to be had. Those Intel guys really know how to squeeze the performance out of their chips.
 
MySQL with Intel Compiler

MySQL compiled with the Intel compiler is 20% faster than the GCC compiler. Not the compilation speed, the actual program speed. Think of how much money in costs to get 20% more speed (how about the difference between a 2.3GHz and 2.7GHz G5), when for some programs it could be done with a better compiler.

For reference:
2003 Intel Press Release
 
is "basic 7.1 surround sound" an amusing thought?

gio64 said:
Intel graphics and sound (at least, I think this is a very possible option).
Sound is part of all the current PCI Express chipsets, with support for basic 7.1 surround, 192 KHz sampling, Dolby and DTS.

If you want better, you can disable the onboard sound and use a PCI/PCI-X sound card.

Although most of the sound circuitry is in the chipset, power amplifiers and some other high current circuits need to be on the mobo, as well as the connectors for speakers/mic/SPDIF etc. Some mobos might omit the connector circuitry - so even though the chipset has the sound builtin, you need a sound card.
 
Nermal said:
Are Intel's compilers usually free (like Xcode) or do you need to pay for them?
The current intel C++ compilers (for Windows and Linux) sell for USD400.

They offer free time-limited trials.

It is possible to get the compiler free of charge, but only for non-commercial use and only on Linux.
 
Abstract said:
Agreed. Apple only makes the operating system and the good software that comes free with every Mac, making it a tool and not just a bunch of electronic components thrown together. Nothing that important. If Intel got Apple out of the equation, they could just put another operating system on these PowerIntels, maybe Windows XP or something (just throwing around an example).

I hope I wasn't misunderstood. I think Intel Macs refers to the hardware. Not to the entire computing experience. In that sense, I am afraid they are unfortunately Intel Macs. I am with you all, it's about OS X and all the other goodies. However, buying a Mac is not going to mean what it meant anymore. Now I know that -aside from hardware lock problems- if I can install OS X on a home made PC I'll have a very close experience to the one of the Mac users, for a lot less money...
 
gio64 said:
...I am not so sure...
Let's see: Intel processor(s) Intel chipset (they are certainly the best option if you are going to use Intel processors) and, in the "consurmer-all-in-one design, rest assured, Intel graphics and sound (at least, I think this is a very possible option). Is it legitimate to suppose that a lot of these components will come from Intel altogether?
...Sorry, I forgot! Apple will get some high-end plastic manufacturer or aluminum producer to make pretty enclosures for these components, so Apple really makes them, right...
Wow, I guess that makes my powerbook a Thinkpad©®™!!!
 
tuartboy said:
Wow, I guess that makes my powerbook a Thinkpad©®™!!!

Why? Does the Thinkpad use a moto/freescale/whatever G4? is the board chipset IBM? I am not sure about the comparison
 
I feel that Intel/Apple connection will go far ahead of simple supply/Manufacturer relashionship.
I am afraid that Apple will simply rely on Intel for the entire production of some of their models.
It's a speculation, but it is a possibility, since the more Intel engineering will go in the product, the more reliability and components efficiency you can expect; and Apple certainly doesn't have a whole lot of experience in working with Intel hardware...
 
iMeowbot said:
The current intel C++ compilers (for Windows and Linux) sell for USD400.

Glad someone else has thought of this as well.

I would assume (and maybe that makes me an a**) that any XCode Plug-in would cost a similar price in turn. This definitely means that GCC is not leaving OS X any time soon.

But that doesn't mean you won't see binary distributions of OS X compiled with Intel's compiler. Apple would be smart to use the best optimized compiler and get the absolute best performance out of X - especially if James' remarks about "optimizing the compiler for Apple" are true.

-rand()
 
This is cool

1. There's no reason to believe you won't be able to glue together PowerPC gcc with Intel xlc binaries. You can already strip one or the other out of a file with supplied tools, so putting a new one in seems like it wouldn't be rocket science.

2. Intel compilers generate output that runs way faster than gcc in most cases, and last I saw, significantly faster than Microsoft's Visual Studio.

3. Intel compilers will not generate PowerPC code (of course), and will not compile Objective C source. So they can't directly build universal binaries or Cocoa applications. But they can build highly optimized C/C++ libraries that link to Cocoa, and can probably build an entire Carbon app top to bottom.

4. The Intel compiler is not free. It costs $400 for Windows or Linux. In addition, the super-highly optimized libraries are available for another $400. Pricing for Mac hasn't been announced, but my guess would be $400.
See the list here:
http://www.xlsoft.com/en/products/intel/index.html

5. They've also announced some sort of vague support for CodeWarrior transitions. They seem to, understandably, be very focused around Carbon development, since they can draw from their linux and Windows experience more there.

6. All-in-all, this is a very good thing. It means the real performance critical apps can eek out every ounce of performance from the Intel chips. It is likely that even if PowerPC chips and x86 chips themselves were exactly even in performance, these compilers would push x86 way over the top in benchmarks and real-world use.
 
"at the time" is important

ewinemiller said:
Since VC++ didn't support SSE at the time I picked up the Intel compiler.
Note that Visual Studio .NET does support SSE, and will do automatic [Alti-]vectorization using SSE instructions. No source code changes necessary....
 
Booga said:
4. The Intel compiler is not free. It costs $400 for Windows or Linux. In addition, the super-highly optimized libraries are available for another $400. Pricing for Mac hasn't been announced, but my guess would be $400.
See the list here:
http://www.xlsoft.com/en/products/intel/index.html
Still a developmental stage product that doesn't have the feature set nailed down.

Wonder if it'll include autovectorization. :confused:
 
Anybody know what percentage of apps out there are Cocoa? Seems to me that not supporting Objective-C is going to cause problems-- it's the Cocoa framework that Apple has been pushing as the easy route to OS X development.

Does XLC support ObjectiveC?

One school of thought might say that if you're coding in Objective C then you're not worried about performance-- but the decision of which language to go with will depend a lot on the performance difference between frameworks and this is going to widen that gap.

And what about that line saying Intel hasn't decided whether to support Altivec instructions? Would they do a translation to SSE or something?
 
What you need to understand..

Analog Kid said:
Anybody know what percentage of apps out there are Cocoa? Seems to me that not supporting Objective-C is going to cause problems-- it's the Cocoa framework that Apple has been pushing as the easy route to OS X development.

An earlier post noted that the only thing you'd need to do to compile for intel vs ppc was a check box - that's right.

But for those of you who think that's the open door to having all these MS apps run on the mac, you're mistaken. Applications are still written to the APIs that each OS runs, MFC or .Net doesn't live on the mac. And while java apps might work in both environments, or generic java apps to be more accurate; the issues of building an application that works on both MS and Apple would be many.

Now if Mono caught on, or someting like CocoaSharp libraries - it might be a little easier, but you still be writing to some lowest common denominator for things like file access and graphics.

I think VPC will be an answer, and a more popular choice to allow user to run multiple OS's once dual core (or more) CPUs are everywhere. Then performance will be acceptable.
 
Analog Kid said:
Anybody know what percentage of apps out there are Cocoa? Seems to me that not supporting Objective-C is going to cause problems-- it's the Cocoa framework that Apple has been pushing as the easy route to OS X development.
It should be okay. The different compilers should be able to interoperate, even within the same project, and the Intel compiler can be saved for critical sections. ObjC can call normal C functions just fine, so it's no big deal.
Does XLC support ObjectiveC?
Yes.
 
FunkSpaceMonkey said:
Must you really pay for the compiler? :confused:
Don't worry about it. GCC isn't going anywhere, you would only need to buy the Intel stuff if you want it.
 
Lots of people misreading this. Apple is not going to replace gcc. They had a "better" compiler on PPC from IBM and made no effort to use it. Why would they switch to Intel's costly compiler? They won't. Intel will offer it for sale just like on all the other platforms. What's different about os x and linux is that they both have free options for developers, while Windows does not (ok, I suppose there's cygwin...)
 
intel documentation on compatibility with GCC. It explains how you can link ICC and GCC code together to take advantage of ICC speed while retaining GCC where you need its language features.
 
louden said:
An earlier post noted that the only thing you'd need to do to compile for intel vs ppc was a check box - that's right.

But for those of you who think that's the open door to having all these MS apps run on the mac, you're mistaken. Applications are still written to the APIs that each OS runs, MFC or .Net doesn't live on the mac. And while java apps might work in both environments, or generic java apps to be more accurate; the issues of building an application that works on both MS and Apple would be many.

Now if Mono caught on, or someting like CocoaSharp libraries - it might be a little easier, but you still be writing to some lowest common denominator for things like file access and graphics.

I think VPC will be an answer, and a more popular choice to allow user to run multiple OS's once dual core (or more) CPUs are everywhere. Then performance will be acceptable.

Kinda confused why I got quoted for this response... My question and comments weren't about compiling for Windows, or cross-compiling or cross platform development. What I'm thinking about is what impact this will have on the adoption of Cocoa, and how this might make existing apps compare to Intel compiled apps.
 
iMeowbot said:
It should be okay. The different compilers should be able to interoperate, even within the same project, and the Intel compiler can be saved for critical sections. ObjC can call normal C functions just fine, so it's no big deal.

Yeah, it still breaks the Apple model of piggybacking on optimized algorithms within the framework.

This isn't catastrophic by any means, especially since this is probably what's being done by most apps that care about performance under PPC, but it's going to make Cocoa look more and more like a single platform Java.

I guess if Apple was really worried about speed, they would have kept writing their own compilers. The frameworks themselves can still be optimized under the hood, with the interface just acting as glue-- but then you've got C code glued to C code through an Objective C interface and the whole thing just gets silly.

Then again, they've switched to Intel, they've released a 4 button mouse, maybe they'll release C++ frameworks next...
 
kevin smith you say?

hmm, kevin smith... with a name like that I just don't know. :cool:


Phil
 
UB

I have a question about UniversalBinaries (UB).
I dont know if there is a developer in the forum who might enlighten me on this.
I thought the UB contained two different sets of code, in one file. That is one code generated for ppc and one for intel. This doesnt exclude one from optimizing each part of the code for each platform or does it?

If you want the fastest code you can generate you would like to use compiler and plattform specific code. If you want a code that can live for 30 years you write it as plain as possible.

Any thoughts about specific plattform or compiler optimization in UB?
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.