Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Intel Software Development Products for OSX

Posted by Hemos on Mon Jan 16, 2006 08:37 AM
from the seeding-the-landscape dept.
Businesses Programming Apple IT Technology
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."
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Intel Software Development Products for OSX 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • Apple uses GCC behind Xcode, so just look for the already-existing comparions of GCC against Intel's compilers.
    • 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 (Score:4, Insightful)

    by acomj (20611) on Monday January 16 2006, @08:42AM (#14481223) Homepage
    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.
    • I think the Folding@home program is done in Fortran. Since there's no good Fortran compiler for OS X it makes it really slow.

    • Re:apple uses objective c / uses of fortan (Score:5, Informative)

      by TheRaven64 (641858) on Monday January 16 2006, @09:52AM (#14481667) Homepage Journal
      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 (Score:4, Informative)

          by TheRaven64 (641858) on Monday January 16 2006, @12:43PM (#14483131) Homepage Journal
          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 GCC manual says it synthesizes instructions using a narrower mode, and I suspect (although haven't checked, TBH) that it does the same thing with GCC FORTRAN.

            The following does indeed compile on GCC 4 (on Tiger and FC4):

            typedef int zz __attribute__ ((vector_size(64)));

            but what you say may have been true in GCC 3...

      • 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.

        Has ANYONE produced a language with vector-based switch statements?

        A pseudo-example might look like

        BooleanThingAMaBob theZerothBooleanThingAMaBob = new BooleanThingAMaBob(INSERT_BOOLEAN_VALUE_HERE);
        BooleanThingAMaB

        • Not to be snide, but if you have a bit-vector of truth values, can't you just use ints?

          • Not to be snide, but if you have a bit-vector of truth values, can't you just use ints?

            Obviously, but now you're embedding "machine code" in an abstract software language.

            The purpose of a language is to abstract the "machine code" to the point that a maintainer of the code can glance at the code, and, without too much thought, realize more or less what it is that is transpiring within the code.

            PS: A priori apologies if "abstract" is forbidden to function as a transitive verb.

            • I absolutely agree with your claim that languages should abstract away machine-level details.

              However, representing bit-vectors as integers is an extremely common practice in C and other languages, and any competent programmer will recognize this idiom. (See for example the "flags" argument for the UNIX open(2) call.) With a little bit of (tasteful) preprocessor use, you can basically get the same sort of code as the example in your initial post. Finally, while you must put in some extra effort if data ar
        • 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 matchin
        • APL and Fortran both do this sort of thing well. Here is one way to do it in Fortran:

          elemental integer function myconditional(a,b)
          integer, intent(in) :: a, b
          select case (a+b)
          case(1, 2, 3, 5, 7, 11, 13)
          return (a+b)^2
          case(4,9)
          return a+b
          case(16:)
        • switch(theLogicVector) { case [false, false]:

          Pretty much any functional language has this sort of thing. In Ocaml [inria.fr], for examples, you have "match" statements that can use tuples, lists, or whatever as arguments:

          let bool_and boolpair =
          match boolpair with
          (true, true) -> true
          | _ -> false
          ;;

          this defines a boolean "and" that takes a pair of bool's and returns "true" only if both are true. Not sure if this is what you meant... And by the way, ocaml compiles to pretty fast native code (com

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

      It is trivial to write a translating compiler- in fact Apple has (had?) one for Objective-C and Objective-C++ at one point. Objective-C is a strict superset of C, so if XCode does directly target Intel's new offering I suspect that we'll simply see the translator again, and yes, it will be of considerable use.
    • Not necessarly. GCC provides compilation of Objective C in the GCC package, but it's defined as a preprocessor language ... if you can compile C, you can compile Obj-C.

  • The reason why new Macs are so much faster? (Score:4, Interesting)

    by yabos (719499) on Monday January 16 2006, @08:48AM (#14481255)
    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.
    • 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.
    • 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...
      • 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
  • This is only an announcement of "plans", and a sign-up for a "free trial" of a *beta* version of the tools. No obvious word on pricing (OSX's Developer Tools are free), or release dates.
  • By default, Xcode uses gcc. In fact, Xcode itself is just a GUI development environment, you can use it with other compilers (such as IBM's G5 compiler). It's fairly simple to configure Xcode to use Intel's compilers if you find yourself in a situation where Intel's compilers would give you a boost. Where these "alternative" compilers are really helpful is with C++ and FORTRAN. Xcode supports C++ but I'm not sure about FORTRAN.

    And you can always compile from the command-line, either directly or with a makef
    • >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
      • "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?"

        Because most development for Windows and for Linux is not done with Objective-C.
        It is done with C++ on Windows and with c and C++ under Linux.

        If you want to port your program from OS/X to a different program you ar
        • I have yet to see Objective-C bindings for QT or GTK so for Linux it is a none starter.

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

          • GNUstep is interesting but very few people use it compared to GTK or Qt. Even if you don't use Gnome odds are very good that you will still have GTK installed so you can use Gimp, Gaim, or Eclipse.org. I would bet that many Linux desktops don't have Gnustep installed but very few don't have GTK or QT.
            For an individual GNUStep +objectiveC could be a great solution but if you are planing on building software for the masses C++ still is the compiled OO development of choice for Windows and Linux
      • > 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

        "One man's theology is another man's belly laugh." [brainyquote.com]

        Perhaps we should extend this to language wars: "One man's sensibly designed language is another man's mutant freak."

        You may really dig Obj-C, but personally, I look at it and get the heebie-jeebies. It has its moments, but I hate the syntax, and for me, I'll take C++'s rigid type system over it any day.
        • I hated the syntax too, for a while. Then I broke down and actually used it and now it makes perfect sense. It's just different. These days I code mostly in Python, Objective-C and C and switching modes between them is pretty much automatic (although I do occasionally still write myobject.mymethod instead of [myobject mymethod] in ObjC).
        • I wrote

          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.

          you responded

          Your definition of "real world" is a lot different to ours.

          Instead of relying on ad-hominem [reference.com] attacks, please try to actually address the

          • Re:Notice its C++ and not Objective-C (Score:2, Informative)

            by 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++:

            B

    • Re:Notice its C++ and not Objective-C (Score:5, Interesting)

      by mrsbrisby (60242) on Monday January 16 2006, @11:19AM (#14482378) Homepage
      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 [paullynch.org].

      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.
      • > Objective-C is a strict superset of C

        Yes, but what version of C?

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

                for (int i = 0; i 99; ++i) { ... }

        would not compile because it didn't recognize the inside-the-for-loop variable declaration.
        • 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
          • 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
      • QT uses a "moc" C++ compiler that isn't even really C++

        Qt programs are 100% pure C++. "signal", "slot", and "emit" are macros. Plain ordinary C macros. But far far prettier macros than those monstrosities Microsoft has for MFC. What moc does is to use those macros to generate signal/slot code. As such, it's not much different from Qt Designer, which generates GUI code from XML.

        You don't need stuff like this with Objective-C, to be sure, but beware getting stuck in that FUD pit of thinking that Qt isn't true
        • Sadly, that's no longer true. For a trivial example, there are keywords in C++ that aren't keywords in C, which means that you can good C code and find out that it won't compile under C++.
          • That was ALWAYS true. "class" was always a C++ keyword, and not a C keyword.
            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.
            • 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 m
              • The question is: why do C++ users think the barrier into Objective-C is so high?

                The barrier is high because only Apple uses Objective-C. You're going to face all sorts of hurdles using ObjC with Windows, Unix or Linux. I really wish ObjC caught on outside of NeXT and Apple, because it is such a nice language, but the reality is that it didn't.

                Using Objective-C to write GUI code outside of Mac OSX is difficult, to list one particularly high barrier, simply because there are no suitable(*) Objective-C GUI lib
          • And it will take 5 minuts to rename your struct from class, to something else. (You do have a gui with refactor support right?)

            An other problem, which is a bit more work to fix, is that you have to cast (void *) so

            int *data=malloc(sizeof(int)*100) is not valid c++

            • yeah, and some other subtleties. #define for NULL was another annoying one, as I remember. (And one of the reasons behind needing templates, as I vaguely recall.) The point was that making C++ a proper superset of C was always a goal, but never completely achieved. The keyword one was the first one that came to mind, but I tend to write either straight C (kernel code) or Common Lisp now and couldn't think of a fancier one.
        • So what? All good C code is also C++ code.

          Subjective. This construct:

          typedef void* class;

          is valid C and Objective-C, but not C++.

          You might say "most C code", or "a lot of C code", or even "my C code" and get less argument, but by saying "good C code" you're saying that anyone who wants to use an obvious type name (like class) in C (like Bjarne did with C-with-classes) isn't producing good code.

          Now, I may tend to agree: I think the author of C++ has no idea what he's doing and couldn't good code (let alone "

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.