Intel Software Development Products for OSX

rgraham writes "Intel has released a number of development tools for OSX, including a C++ and Fortran compiler. I for one would be interested to see some benchmarks of code compiled using these tools and Apple's own Xcode."

Comments

Benchmarks already exist

[ChrisDolan]

Apple uses GCC behind Xcode, so just look for the already-existing comparions of GCC against Intel's compilers.

Re:Benchmarks already exist

[ciroknight]

On the other hand, the numbers don't exist for OS X/x86 (publicly, yet). While you might get a general code performance idea, there are a lot of specific things that OS X does oddly that might cause one compiler to be "better" than another.

apple uses objective c / uses of fortan

[acomj]

Fortan is big in the modeling world, still. Oddly enough for a language that is that old, gives clout in science and engineering worlds.

The C++ is nice but since most osx programs are written on objective c, probably of little use.

Those math libraries look like the ticket though. Everone likes highly optimized math libraries.

Re:apple uses objective c / uses of fortan

[TheRaven64]

FORTRAN has a vector data type, which makes it a lot easier to optimise certain types of code for AltiVec, SSE, etc. If you write the code in C, you have to translate it into scalar intrinsics, and the compiler has to work backwards to attempt to determine the vector operations you meant. In FORTRAN you provide the vector operations, and all the compiler has to worry about is aligning the data so it can be used by the vector unit. For algorithms that can be expressed in a vectorised form, this makes FORTRAN a much better language for writing fast code, which is why it is still used a lot.

Re:apple uses objective c / uses of fortan

[TheRaven64]

The vector type introduced by GCC is vector-unit dependent. For an AltiVec target, for example, it is 128-bits. The only operations on it are those directly supported by the vector unit. You have to manually break your data into vectors of the correct size. In FORTRAN, you can operate on arbitrary sized vectors as if they were scalars. The compiler can easily break your large vector into blocks that will fit the vector unit and modify your scalar operations to correspond to individual or compound vector statements. It can also distribute your operations between the vector and scalar units on the CPU easily.

The reason why new Macs are so much faster?

[yabos]

I wonder if this is the main reason why OS X is so much faster on the Intel chip. I can see the Powerbook getting a good speedboost but 4-5x is a lot more than what you'd expect.

Re:The reason why new Macs are so much faster?

[wouterteepe]

The main reason why OS X is so much faster is that the powerbook so far used the G4 processor, which is actually a rather old processor. Given that the G4 is already out there for so long, the compilers for G4 are quite well optimized, I'd expect.

Re:The reason why new Macs are so much faster?

[jtrascap]

Actually, the biggest single hardware reason isn't the processor but the bus speed. For example, my 9-month old (snif!) PowerBook 15" running at 1.67 Mhz on a 167 MHz (10:1) bus. The competative 1.67Mhz model of new MacBookPros have a 667 MHz bus = a shade under 4x speed difference. Then you can add in the better Intel-optimized compilers, GCC libraries, etc, etc...

Re:The reason why new Macs are so much faster?

[jtshaw]

It isn't just the dual cores. The G4 while a well designed processor, has far too slow a memory bus to compete. The Core Duo's memory architecture is about 5x faster. That, coupled with the 2nd core and the more modern design make the Duo well faster. I would be willing to be on memory intensive tests even a single core version of the new Intel chip would trounce the G4.

That being said.. it would be interesting to see good benchmarks between the dual core G5 and the Core Duo. I realize that currently there is no verison of the G5 suitable for laptops, but I'm still curious as to which chip is the all out performance leadering...

Oh well.. I bought a MacBook Pro anyway. Now I just have to wait.

Re:Notice its C++ and not Objective-C

[ignorant_newbie]

>Its a shame that most of the new OS X dev work is done using Objective-C and not C++

why is this a shame? They're using a language that actually makes sense, rather than one that's just a bunch of ideas cobbled together on top of C, and you think this is a shame? or is it just that you didn't have an Objective C class when you went to devry*, so you don't know anything about it?

Yes, Intel's compiler is faster on intel hardware than gcc. this is true in every os that runs on intel hardware... but makes almost no difference in the real world, except for processor intensive apps ( mp3 ripping, dvd encoding, etc ). so, for 99 % of the code written for any os, it just makes more sense to use a portable compiler, and a good language.

* before you flame me on this, they didn't have an objective c class when I went there either. It's not that you suck, just that devry does.

Re:Notice its C++ and not Objective-C

[mrsbrisby]

Its a shame that most of the new OS X dev work is done using Objective-C and not C++.

I don't know that it would be a shame.

Certainly, if C++ were the language of choice for Cocoa, it might make C++ users feel more encouraged to target Cocoa, but it wouldn't actually help them write code for Cocoa.

The C++ interfaces for different display and widget systems are as different as the systems themselves- QT uses a "moc" C++ compiler that isn't even really C++ for signals and slots support- but encourages programmers to avoid tampering with the event loop, while Win32 encourages direct access with it.

So maybe if "Cocoa++" were around, it might help QT programmers (as the "moc C++" was designed to add features that Objective-C has, but that C++ didn't (and still doesn't well...)), but it certainly wouldn't help Win32 programmers in the slightest- except in "feeling" like all they've got to learn is a new API instead of a new language.

However, it may be better to point out that unlike the vast gap between C and C++ that makes them so distinctly different languages, Objective-C is a strict superset of C, in the sense that all C code is also Objective-C code. Apple also provides Objective-C++ which is a strict superset of C++, in the sense that all C++ code is also Objective-C++ code.

Now, most proficient programmers have no problem picking up a new language in a matter of hours; and Objective-C is so completely straightforward that just diving in is bound to validate that.

However, there are less-proficient programmers, and they tend to produce, sub-standard quality software. Given how much Cocoa software is of such high quality, it does beg the question: Is it the lack of poor programmers working in Objective-C, or is it that Objective-C is just that wonderful to use?

Having a "Cocoa++" might answer that question definitively, but I simply cannot see how that would be a Good Thing.

Re:Notice its C++ and not Objective-C

[Anonymous Coward]

Yeah, Ok, forget the whole language A -vs language B war:

C++ is better here:

vector va, vb, vc;
vector vd; // .. fill data here ...
vd = va * vb + vc;

vs Objective-C:

FloatVector * va, vb, vc;
IntVector * vd; // .. fill data here ...
[vd autorelease];
vd = [IntVector vectorWithFloatVector:[[va multiplyFloatVec:vb] addFloatVec:vc]];

Objective-C (err Cocoa) is better here:

id someObj, someString = ...
if([someObj respondsToSelector:@selector(stringValue)])
      someString = [someObj stringValue];

vs C++:

BaseClass * someObj = ...
string someString;
if(HigherClass * hc = dynamic_cast(someObj))
        someString = hc->stringValue();

else if(OtherHigherClass * hc = dynamic_cast(someObj))
        someString = hc->stringValue(); // ... potentially way more ...

These are only two examples off of the top of my head, but clearly, comparing languages without specifying domain is pointless, because I can come up with tons of examples where one is better than another. Hell I can even make VB look good if I limit myself to one of it's strengths, and avoid it's weaknesses.

I love Objective-C, I also love C++. I choose the more appropriate for the task.

Re:PLEASE: A vector-based switch statement?!?!?!?

[TheRaven64]

Try Erlang. Not only does it have a binary (bit array) type, which is very useful for doing anything that involves talking to sockets, you can use pattern matching with it. This allows you to define a version of a function that is called when you invoke the function with an argument that matches the pattern, so you could (for example) have two versions of a function taking a bit-field, one of which is invoked when the third bit is 1, and the other when it is 0. You can do the same kind of pattern matching in switch statements.

Oh, you also have process creation and message passing primitives in the language, allowing you to easily write very scalable code.

Re:Notice its C++ and not Objective-C

[hunterx11]

I have yet to see Objective-C bindings for QT or GTK so for Linux it is a none starter.

GNUstep may not be anywhere nearly as mature as Qt or Gtk, but it's hardly a non-starter.

Re:Notice its C++ and not Objective-C

[mrsbrisby]

It's been a while since I coded in Objective-C, but last time I did, it didn't appear to implement C99 standards...

Probably since before 1999, or at least before C99 support was added.

int main() {
      for (int i = 0; i < 99; ++i);
      return 0;
}

Compiled just fine with: gcc -std=c99 -o moo moo.m

Re:Notice its C++ and not Objective-C

[mrsbrisby]

That was ALWAYS true. "class" was always a C++ keyword, and not a C keyword.

That's the point. C++ is not compatible with C, whereas Objective-C IS compatible with C.

It's not like trying to get a C programmer to write C++ (something that's very difficult), because Objective-C isn't anywhere near as complicated as C++ and yet does it so much better.

It's just not very interesting because it's trivial to resolve such incompatibilities -- unless your compiler is really, really good at reporting deceptive error messages, I guess.

So what? The question is not whether a capable C++ programmer can dive into C code, but instead what the barrier is with C++ programmers and Objective-C.

I pointed out that Objective-C is a strict superset of C, and Objective-C++ is a strict superset of C++. That means that if the programmer feels much more comfortable expressing certain logic in C or C++, they are able to when using Objective-C/C++.

This however, isn't true in the other direction- C users aren't always able to express C-think logic in C++.

Something like this:

const int *a;
float *b, z;
z = ...;
b = &z;
a = (const int *)b;

Not valid C++ at all, no in C++ you need:

a = const_cast<const int *>(b);

This isn't surprising, or even new: C++ is not C. It's not a "better C", or a "newer C", it's got about as much in common with C as Java does.

But Objective-C is C, and Objective-C++ is C++.

Fine: C++ is your favorite language. You might even find it a fine language. That's okay, and I'm not making any effort to dispute that, or convert you or anyone else.

The question is: why do C++ users think the barrier into Objective-C is so high? Is it because they secretly realize they don't know C?

Well what about the barrier into Objective-C++?

C99 Test.

[krischik]

Thats a poor test. This particular feature has been with C++ for a while and most C vendors are also C++ vendors. All they had to do is copy it across to C. A good test whould be a C feature which is _NOT_ a C++ feature.

BTW: The place where most so called C99 compiler fail are variant arrays - A feature even ALGOL 60 had (40 years ago) - and it's decendants like Ada and ISO-Pascal still have today. But C vendors can't get it right or worse don't even try.

Martin