Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming Businesses Apple IT Technology

Intel Software Development Products for OSX 83

Posted by Hemos from the seeding-the-landscape dept.
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."
This discussion has been archived. No new comments can be posted.

Intel Software Development Products for OSX More

Intel Software Development Products for OSX

Comments Filter:

  • Benchmarks already exist (Score:5, Interesting)

    by ChrisDolan ( 24101 ) <chris+slashdot@nosPaM.chrisdolan.net> on Monday January 16, 2006 @08:42AM (#14481216) Homepage
    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.
    • ifc (intel fortran compiler) is blazing fast on linux, so I hope the OS doesn't get too much in the way of the Mac version.

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

      by TheRaven64 ( 641858 ) on Monday January 16, 2006 @09:52AM (#14481667) 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.
      • GCC also has a vector type.

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

          by TheRaven64 ( 641858 ) on Monday January 16, 2006 @12:43PM (#14483131) 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.
      • No, the GCC implementation of Objective-C is not a preprocessor. It is a full-blown compiler, just like the GCC C, C++, Java, Fortran, and Ada compilers. The Stepstone implementation, which hasn't been widely used for ages, was a preprocessor.

        • Right. GCC can compile Objective C but it was defined — by Stepstone, specifically — as a preprocessor language. Just as I said.
          • True - but C++ was a preprocessor language when it started out as well.
            • Uhm, so? All I was pointing out was that if you have a good C compiler, you can get to Objective C easily.
              • Hello,

                is that so? Is producing an Objective-C preprocessor realy that easy? If so: How about any other progamming language. There is Objective-C and Objective-C++ - could there be Objective-Ada or Objective-Fortran as well?

                I read a little about Objective-C (- I know I never become a real /.ter - I inform myself about the subject at hand instead of repeating FUD -). AFAIK or understand Objective-C lives from it's object orientated runtime environment. But could that not be accessed from any programming langu
                • I don't know a tonne about the implementation -- back when Tom Love and Stepstone were pushing it, I was in grad school and far preferred C++, because it didn't cost money. But Objective C did depend on a runtime library to do things like, eg, garbage collection. Basically, if you look at Objective C, everything that had to be translated into C was indicated with @keyword structures, or between [square brackets].

                  Oh, one other thing: I was wrong to agree that C++ is a preprocessor language in quite the sam

  • 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.
    • The "4-5" number comes in part from Apple running the same benchmark on both CPU:s - a benchmark optimized for multiple cores. No wonder the single core Power CPU didn't do a good job on that. It is faster, but not that much faster. A bit disingenious.
      • 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
    • 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...
      • Actually, the biggest single hardware reason isn't the processor but the bus speed.

        ACTUALLY, the biggest single difference is from single processor to dual processor. And G4->Intel Core Duo is going to be a good increase in the first place.

        Why is everyone all "OMG, the iMac Intel is it's 2~3x faster than the iMac G5, how'd they do that?" Seriously, the G5 in the iMac G5 isn't much slower than a single iMac Intel chip... you just get two of them instead of one.

        Now, imagine them replacing the PowerMacs s
    • There are several reasons:

      Powerbook G4 is an older processor in the speed wars. There is less of a difference in between the G5 and Intel based iMac, but still some. (It is closer to 2-3x faster).

      The Powerbook G4 is single core, the Macbook Pro is dual core.

      Bus speed is 667 Mhz 4x faster, as well as faster memory.

      One drawback is that most of the program out there 'Right now' are compiled for PPC only and would run under Rosetta, so the performance will not be as good. Code that is "Universal" should be abl
  • 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.
  • Its a shame that most of the new OS X dev work is done using Objective-C and not C++. Most of the OS X developers would not be able to take advantage of Intel's optimizations. I wonder whether Apple would bundle this compiler with XCode? Probably not.
    • >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
      • > 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).

    • 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.
      • all C code is also Objective-C code

        So what? All good C code is also C++ code.
        • 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's trivially fixable with a few -D compiler options.
          • 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
                • If I were a writing for primarily a Mac audience, I would be using Objective-C. But since I'm writing for Mac, Windows and Unix, I'm sticking with C++ for now.

                  You misunderstand: Look at the other threads on this subject. Many C++ users are vehemently opposed to Cocoa because it's Objective-C. They can use Objective-C++, and Objective-C/C++ isn't a fundementally different language. I think they don't realize these two points, and the barrier I refer to is why they don't realize these two points.

                  GNUstep is a
              • > Is it because they secretly realize they don't know C?

                I will answer this: Yes, we realize that we don't know C. No, we do not keep it secret. If you are used to modern C++ with vector, string, *_cast, shared_ptr etc. it is not trivial to do things in pure C. I fear that I even will have to use malloc (*quakes in terror*) at some point if I use Objective-C. Also, in modern C++ everybody use the RAII idiom for all types of resources, while in Cocoa it seems to be standard to do manual reference counting
          • 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 "
        • *good* C code would use "restrict" where appropiate but C++ does not know about the keyword "restrict".

          Just one more example where C != C++.

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

          • C99 Test. (Score:2, Insightful)

            by krischik ( 781389 )
            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
        • Hello,

          Actually there are more then niggling details which seperate C99 and C++ 2003. C++ has new keywords which C++ won't understand. Also C99 has varing arrays which C++ has not got.

          Martin

          PS: I only care only of and compare the official ISO standarts and not any broken implementation. And older ISO standart have benn superseeded.

          PS2: I find it paticular sad that most C vendors are unable or unwilling to implement features which had been part of ALGOL 60, ISO Pascal and Ada 83.

          PS3: vector is no replacement
      • "all C code is also Objective-C code"

        not quite.

        int id;

        wont compile in Objective C, but its fine in C. might be trivial, but it can pose difficulties.

  • 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
  • Can it be used to make the Intel portion of Universal binaries along with something else to make the PowerPC code?
  • I signed up the beta, very shortly after it was announced. Today I got a message from Intel, thanking me and informing me the beta program was full b/c of the overwhelming response.

    (Despite the link saying I would get the download information immediately after signing up).
  • are these products for free (for personal use at least) like the Linux versions?

Slashdot Top Deals

Real programmers don't comment their code. It was hard to write, it should be hard to understand.

Close