Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Intel

Intel Releases V6.0 Compiler Suite 45

Posted by timothy from the smooshing-the-bits-around dept.
Yokaze writes: "Intels C++ and Fortran compilers are now available for Windows and Linux. The compiler for Linux provides higher compatibility with the GNU C-compiler including compability to the upcoming GCC-3.1 C++-ABI (binary compability) and support for several GNUisms in the syntax (PDF). To quote Intel: 'The 6.0 release of the Intel C++ compiler has improved support for the GNU C language extensions and is now able to build the Linux kernel with minor work arounds for both the IA-32 and Itanium architectures.' Little reminder: Running such a kernel is, of course, not supported by the kernel developers. Evaluation copies are available for download, but requires previous registration."
This discussion has been archived. No new comments can be posted.

Intel Releases V6.0 Compiler Suite More

Intel Releases V6.0 Compiler Suite

Comments Filter:
  • Standing up for the FSF,

    Compiling a Linux kernel for a GNU system without an Intel compiler does not mean that you are running Intel/Linux OS.

    Although there is a pretty good chance that whoever reads this is running GNU/Linux Intel.

    I love the smell of propaganda in the morning... It smells like sour grapes...
  • Interesting to see their compiler supports GNU C extensions. Usually it's the other way around, free software keeps implementing undocumented extensions. At least the GNU extensions are useful (like 0-sized arrays), and well documented.

    It's also interesting that they wrote their own compiler, instead of patching GCC. GCC also works on Windows and 3.1 already has optimizations for different CPU extensions to x86.

    They also wrote a new debugger (LDB) specially for Linux, although they claim it implements only a subset of GDB, so what is it for?

    And to compile the kernel...who will do that? Is there some server vendor planning to sell Intel servers with such kernels on?

    • Re:Adopt GCC extensions? (Score:3, Interesting)

      by psavo ( 162634 )
      It's also interesting that they wrote their own compiler, instead of patching GCC. GCC also works on Windows and 3.1 already has optimizations for different CPU extensions to x86.

      Well, that's mostly sad. They cannot extend gcc, because gcc is under GPL -> they'd have to release the source -> many patented & licensed tricks would be exposed.

      And to compile the kernel...who will do that? Is there some server vendor planning to sell Intel servers with such kernels on?

      Kernel compiling is pretty much 'fire test'. If they can do that, they can do almost anything (save from mplayer ;). Also, kernel accounts for pretty much system overhead, so speeding kernel up speeds system. especially linux kernel SW RAID, sweet.

      The area Intel compiler will shine is all computing -intensive tasks. Like Maya 4, povray, most math libs and stuff. So there is place and _demand_ for it.

      I wonder how this code will perform on Athlon/Hammer-32..
      • They cannot extend GCC because they're writing a high performance compiler, not an optimising compiler, it's a different architecture because it's solving a different problem.

        • Re:Adopt GCC extensions? (Score:3, Interesting)

          by Anonymous Coward
          Some people may find this interesting: GCC for IA64 Summit [linuxia64.org] Talks about some of the optimization problems with GCC. Here's one juicy bit:

          Suneel Jain: Is the goal of having a higher-level tree representation
          to do inter-procedural optimizations from information written to
          disk?

          Mark Mitchell: This question comes up a lot. The sticky issue is that
          the FSF is morally opposed to doing this. The aim of the FSF is not
          to produce the best compiler, but to convince the world that all
          software should be free. The concern is that writing out the
          representation to disk would allow a vendor to use a GCC front end,
          write the IL to disk, read it back in, and graft proprietary code
          into GCC in a sneaky way to get around the GPL. This is a very
          firmly held position in the FSF.

          • Re:Adopt GCC extensions? (Score:3, Insightful)

            by Anonymous Coward

            I had to read this twice... quite frankly, it's a pretty stupid reason to avoid those type of optimizations. First, if it's a real worry, add a clause to the gcc license that explicitly prohibits this hack. Second, there's nothing preventing someone from (essentially) doing this anyways - NuMega and Rational both have tools that are capable of injecting arbitrary code into a binary, and there are other projects that are exploring similar modifications (heck, disassemble the binary and run it through an optimizing assembler in order to generate proprietary code.)

  • Looks like Intel has woke up and smelt the coffee and actually listening to what the developers want, not what they think they want.

  • Performance? (Score:3, Interesting)

    by 4of12 ( 97621 ) on Wednesday April 24, 2002 @08:18AM (#3400785) Homepage Journal

    ...able to build the Linux kernel...

    So that begs the question: apart from issues of reliability, stability, do the Intel compilers make a Linux system perform better or worse than one built with gcc?

    • Re:Performance? (Score:4, Informative)

      by spencerogden ( 49254 ) <spencer@spencerogden.com> on Wednesday April 24, 2002 @09:14AM (#3401051) Homepage
      I think last time the Intel compiler was discussed it offered significant performance benefits ( read more than 10% ) on both Intel and AMD chips.

      • Re:Performance? (Score:3, Informative)

        by Lars T. ( 470328 )
        Again a word of warning: the Intel compilers can yield incorrect programs, if the more agressive optimizations (inter procedural optimization / -ipo) are used. At least this was the case for Version 5.5 (article in German) [heise.de].
        • Right. Which is also why people using an Intel or other non-gcc compiler should first replicate bugs they find in their 3rd party compiler builds with a build produced by the official gcc compiler.

          I'd rather see more work done on increasing the performance of the already excellent code that GCC produces on a wide variety of platforms (The Gnu Compiler Collection doesn't just generate IA32 machine code, btw, there's Alpha, ARM, M68K, AMD's version of IA-64 and a hell of a lot more...). I for my part don't want to use a proprietary compiler that makes use of secret, undocumented chip specific tweaks to eke out another 10% of performance on chips made by a specific manufacturer. I want a compiler that produces robust, dependable and fast code and that compiler is GCC.
    • It's more that the kernel code has been extensively tweaked for GCC, which does a few things the Intel compiler doesn't, and vice versa. Something as complex as the linux kernel usually relies on sensitive features in the compiler, or makes up for them with add-on scripts that massage the resulting binary into compliance.

    • Re:Performance? (Score:4, Informative)

      by tjwhaynes ( 114792 ) on Wednesday April 24, 2002 @10:12AM (#3401363)

      So that begs the question: apart from issues of reliability, stability, do the Intel compilers make a Linux system perform better or worse than one built with gcc?

      The correct answer to that question is: It depends

      I've made use of the new Intel compiler on some Linux projects. Initial results showed that it had about the same performance as gcc. But at this point we know a lot about the gcc compiler tuning and not a lot about the characteristics of the Intel compiler, so only time will tell how much performance can be (safetly) wrung out of the Intel compiler.

      Cheers,

      Toby Haynes

  • It says it does profiling, and Itanium-specific optimizations, along with some more standard compiler tricks...

    I'm sure it produces faster code on average than gcc, but it'd be interesting to see a gcc/Intel Athlon/P4 showdown. ;)
    • Not quite what you want but look at this page [nthu.edu.tw]. It compares many a chipset in re Gaussian 98. The benchmarks are in minutes so they are quite meaningful.
    • Somewhat offtopic, but since you brought up AMD...

      Ars has a story yesterday relating to Microsoft and AMD getting in bed together and Microsoft insisting that Intel incorporate AMD's x86 64-bit instructions over their own IA64 code. It may all be rumor, but it's intriguiging. Check it out. [arstechnica.com]

      You'll have to scroll down to "x86 64-bit support for Windows".
    • This hardly counts as a showdown, but, here are some statistically meaningless personal observations on my Athlon XP 1700+:

      I tried compiling a program I've been working on with gcc-2.96 and version 6 of icc with some cut'n'paste "heavily optimize" flags*.

      (The program generates all finite semigroups of a given order, and consists completely of integer operations).

      To generate all finite semigroups of order 7 took (under constant system load; result is the average of the system time reported by /usr/bin/time over three attempts):

      ~672 seconds with the gcc executable
      ~553 seconds with the icc executable

      Its not an Earth-shattering difference, but its certainly non-trivial.

      Again, please don't mistake this for a fair comparison of any sort... its simply a test of both compilers in the only domain that matters a tinker's cuss to me: Will it generate faster exectuables for the program I'm working on at the moment with little to no extra work? Extrapolate at your own risk.

      * flags for gcc were:
      -O3 -fomit-frame-pointer -mcpu=pentiumpro -march=pentiumpro -malign-functions=4 -funroll-loops -fexpensive-optimizations -fschedule-insns2 -finline-functions -fstrict-aliasing

      flags for icc were:
      -O3 -tpp6 -xK -ipo -prof_use

      (I compiled previously with -prof_gen and generated a profile running semigroups of order 6).

  • I hope they got it right this time. (Score:3, Informative)

    by Utopia ( 149375 ) on Wednesday April 24, 2002 @09:03AM (#3400987)
    The Intel compiler has been known to ignore possible pointer-aliasing (variable accessed directly and also accessed via a pointer).
    This is OK with Fortran or in Fortran converted to C because Fortran doesn't have aliasing.
    This serious bug results in a lot of incorrect code.
    It is prudent that you double check the results from the Intel compiler.

    • The Intel compiler has been known to ignore possible pointer-aliasing (variable accessed directly and also accessed via a pointer).

      Its not the only compiler that has problems with pointer aliasing. Optimizing aliased pointers will give you trouble on lots of platforms - careful reading of the ANSI standard says quite a lot about valid C coding and avoiding aliasing situations.

      Cheers,

      Toby Haynes

  • Let's harass AMD to give us an Athlon-optimized compiler for linux, eh ? These Intel tweaks don't do squat for my T-Bird. Or at least they could pitch in on GCC development.

    • Re:This is nice, but... (Score:1, Informative)

      by Anonymous Coward
      I can't speak for Intel's C compiler, but moving to Intel's Fortran compiler on an Athlon Linux box bought my research group a 35% decrease in runtimes (for a simulation code that relies heavily on matrix factorization). We experimented a little with the compiler switches, but nothing heroic.
    • That would be nice. Too bad AMD doesn't have a comiler team. Intel is a completely different company, they're about 6 times bigger.
      • Indeed, which explains why Intel cpus are 6 times more costly than the equivalent AMD chip. Still it would be nice to have some AMD-borne expertise working on GCC's code generator.

  • Pretty lame overall. (Score:3, Interesting)

    by Ogerman ( 136333 ) on Wednesday April 24, 2002 @01:31PM (#3402840)
    Intel ought to stick with what they do best: designing fast microprocessors. If they could give the gcc folks some tips on improving performance, I think that'd go a lot further for their bottom line then wasting time writing proprietary compilers that only a few companies will use. Do they quite realize the market advantage of having the Open Source community on their side? Heck, I'd quit using AMD processors tomorrow if Intel could squeeze significantly more performance out of their chips in gcc. AMD take note: you guys could be the first to jump on this as well.

    • You're missing the point (Score:1)

      by Anonymous Coward
      The GCC people will not add many of the optimizations the Intel compiler does. Is a gcc fork going to make people happier than a separate compiler? And why stop using AMD if they do? The Intel compiler makes binaries that run faster than gcc on AMD processors as well.

      > Do they quite realize the market advantage of having the Open Source community on their side?

      Yeah, I think they realize exactly how much value that has...

    • Re:Pretty lame overall. (Score:4, Interesting)

      by bstrahm ( 241685 ) on Wednesday April 24, 2002 @03:49PM (#3404299) Homepage
      Problem is that GCC's top goal isn't maximum performance, it is maximum portability. There are a lot of things you can do if you only have to target one architecture (and trust me Intel is only targetting one architecture) rather than the several dozen that GCC targets...

      This said there is a need for both, ultimate portability and ultimate performance. The intel compilers have been delivering ultimate performance on their architecture for years, look at the difference 10 years ago between the MS compiler (internally developed) and the Watcom compiler (Intel License) guess who's compiler produced significantly faster executables...
    • Actually, CPU houses have, AFAIK, always written compilers optimized for their chips, because a) they have a vested interest in the performance of their chips compared to competitors chips, b) a lot of CPU performance depends on the compiler and optimizing it for the chip, and c) if you're not the industry standard (like Intel currently is), then if you don't write a compiler for your chip, no one will, and then no one will use your chip. It's much more difficult to optimize a chip for a compiler, and the performance gains are less, than doing it the other way around.

      Also, chip vendor compilers aren't necessarily for people to use, but also to show Microsoft or Watcom or Metrowerks or the GCC team how they can write compilers to take advantage of the chip's architecture.

  • GCC is a bit slower than the vendors compiler on most other platforms...any benchmarks for us to see?

    I'm sure its optimised decently well for x86 however...
  • i remember the pgcc project aimed to distribute a pentium optimized version of gcc. i believe that the stampede linux project (defunct, resurrected and defunct again) used pgcc to deliver an optimized complete linux distribution. looking at what appears to be pgcc's website [goof.com], it appears that pgcc is inactive as well ("last change: 2000-12-27"). Does anyone know the actual status of this project or have any information? It's last release is gcc 2.95.2.1 so direct comparison is not quite possible, but how does pgcc compare against intel's cc performance-wise? the only value i can see in an intel cc is performance improvements. because intel obviously has all the specs on their processors, they can heavily optimize the compiler output. since they are not opening their source or specs completely, some people who are willing to pay can at least get the performance gains, but if something like pgcc can offer similar performance, there seems to be no point. any comments...
  • for Linux here [intel.com]. If you want support however, the supported version is a hair under $400 per licence (discounts for >9 licences)


    Sadly there's no Windows version of the unsupported offer.

  • Has Intel forgotten about the *BSD family, or do they just force us to use Linux 'emulation' ?

Slashdot Top Deals

Any sufficiently advanced technology is indistinguishable from magic. -- Arthur C. Clarke

Close