Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Intel

Intel Releases Compiler Suite 7.0 47

Yokaze writes "Intel boosts its Pentium 4 and Itanium 2 and released Version 7 of its compiler suite. On the Windows side, there is the plugin compability to the .NET enviroment, on the Linux side better compability to the GNU compiler, including the Common C++ ABI.
As usual, there are 30-days evaluation copies and for Linux an unsupported non-commercial version after previous registration at the Intel Evaluation Centre. According to the comments published by Intel marketing, Dr. Fons Rademakers, CERN, claims high compability with GCC 3.2 and a performance increase of up to 30% on their code (The ROOT System)."
This discussion has been archived. No new comments can be posted.

Intel Releases Compiler Suite 7.0

Comments Filter:
  • Doubtful (Score:1, Troll)

    I doubt that such a compiler would be any faster than the Free gcc compiler. Sure, Intel makes the chips, but they have not had the advantage of thousands of software experts and academics being able to look over their code and fix bugs. I wouldn't trust it at all, especially not a .0 release. I'm surprised that commercial companies even use this when there is a far superior alternative available for Free.
    • Re:Doubtful (Score:4, Interesting)

      by jericho4.0 ( 565125 ) on Saturday November 23, 2002 @08:55PM (#4740709)
      As I understand it, Intels compilers kisk ass. Faster compilations, faster code, smaller code, etc. Not to knok a great product in GCC, but Intels engineers are no slouches.
    • gcc actually is pretty crappy for optimization. gcc is a portable compiler and getting it to be fast on all platforms is hard.
    • I wouldn't trust it at all, especially not a .0 release.

      Uhm, it's not a Redhat release, don't be so pessimistic :)
    • Re:Doubtful (Score:4, Insightful)

      by selectspec ( 74651 ) on Sunday November 24, 2002 @03:36PM (#4744466)
      gcc in some areas produces slower code than the native compilers.

      The fact is that gcc is designed for cross platform compilation and the native compilers are not. The abstract tree approach to gcc's design is somewhat limiting for some arch specific operations, and certainly adds complexity to the compiler development process.

      Also, Intel and Sun have spent many millions of dollars on their compilers over the years. You get what you pay for.

      However, I would hesistate to use the intel or sun compiler for a project.

      Using a platform specific compiler ties your project down to a single architecture, defeating one of the major purposes of C/C++.

      A far better approach, if practical, is to isolate the real performance sucking areas (encryption, xor routines, float ops, etc), and write these sections in assembly. Those sections will become platform specific, but will smoke any compiler output.
      • Re:Doubtful (Score:2, Insightful)

        by mcbevin ( 450303 )
        A far better approach, if practical, is to isolate the real performance sucking areas (encryption, xor routines, float ops, etc), and write these sections in assembly. Those sections will become platform specific, but will smoke any compiler output.


        I use the Intel compiler on Linux. The program I work on when compiled with it runs around 50% faster than gcc. But in general, use whatever suits your particular needs, and just make sure you use standard C/C++ and it'll still be compatible. If you're not sure, check occasionally that it still compiles with other compilers.

        Personally theres no way I'd go near assembly. That pretty much guarantees unmaintainability, unreadability, platform-dependance. I don't know how many hours I've had to waste working out what someone else's assembly is doing, converting it to readable C, and then having understood what its doing, optimised the C algorithm to make it faster than the assembler ever was.

        I've also used the Intel Compiler's Intrinsics to MMX-optimise my code without a line of assembler. I've tested the code to be just as fast as hand-coded assembly equivalents. I also always create an identical pure-C/C++ function, so its clear exactly what is being done, and can still be compiled on other compilers/platforms. This is necessary in any case so that the code will run on non-mmx (pre P-III) systems.

        I'm looking forward to testing the version 7.0 Intel compiler - my experience with version 6.0 was that it made programs faster than gcc but still slower (and a lot bigger) than Visual Studio .net. If 7.0's better I might be able to leave Microsoft behind :).

  • Well... (Score:3, Informative)

    by bic2k ( 140221 ) on Saturday November 23, 2002 @08:52PM (#4740693) Homepage
    I just downloaded the new intel compiler for windows. Tested it with a opengl application I made that runs really slow. The difference between the microsoft c++ compiler and the intel one is about 15%. Not quite 30%, but that probably applies to particular situations...
  • Gentoo support? (Score:4, Interesting)

    by crow ( 16139 ) on Saturday November 23, 2002 @09:39PM (#4740845) Homepage Journal
    What would be really cool would be if a source distribution like Gentoo would support this in addition to gcc. Perhaps they could set it up to first try building with the Intel compiler, and if any errors show up, then try with gcc. It would certainly be interesting to see how well such a system would run.
    • Re:Gentoo support? (Score:4, Informative)

      by GreyWolf3000 ( 468618 ) on Saturday November 23, 2002 @10:01PM (#4740904) Journal
      It's not in CVS yet (server down, other issues), but Linux from Scratch [linuxfromscratch.org] builds GCC 3.2.1 for most people out of the box with the same commands as 3.2. Also, many have reported that they have built LFS with glibc 2.3.1, and have experienced huge speed increases. I know a few on the IRC channels who have successfully built glibc 2.3.1 with no changes to the commands used in LFS 4.0. Note that GCC 3.2.1 is required for glibc 2.3.1.
    • Re:Gentoo support? (Score:4, Informative)

      by photon317 ( 208409 ) on Saturday November 23, 2002 @11:20PM (#4741193)

      Gentoo has a package for icc, as well as gcc. BTW they had a working autobuild for gcc 3.2.1 two days before the slashdot announcement of the release :)
    • And they could have the Watcom and Borland compilers too... ideally a single front end 'cc' with common command-line flags which can run any of the four compilers. I think that Watcom is now free software, so it might be a better choice than Intel's compiler if not quite as fast.
  • Imagine that - the ad I'm viewing is for intel development tools.

    So slashdot runs articles for intel development tools and advertisements for intel development tools.

    At the same time.

    Cmdr Taco - how do you like being a whore?

  • By looking at that site (quick glance), it doesn't seem that the ABI is as stable as it's been totted to be, there seems to be a lot of proposals for new ways of doing things and some open issues. Are these just minor ideas or could we see a version 2 ABI sometime soon in the future?
    • i know gcc 3.2.1 was just released which fixes a few bugs in the 3.2.0 abi implementation. Ok, so that's unrelated.

      But, there will probably be updates to the abi in the future, as it has not yet been extensively tested in the real world.

      • I think for the moment, the main problem is that there are no good test suites to test ABI compliance. That's the reason why GCC is currently struggling. They think they have done it correctly, but then from time to time someone notices a new ABI bug.
        Anyway, the real world test will be when people try to actually link C++ libaries produced by compilers from different companies.

        Marcel
  • by benjamindees ( 441808 ) on Sunday November 24, 2002 @04:36AM (#4742223) Homepage
    I just finished reading this interesting thread [debian.org] on the Debian [debian.org] developers' mailing list. They discuss all aspects of the Intel compiler, including AMD support, possibly adding packages to Debian non-free, and (most interestingly) using icc to compile Debian binaries for distribution.

    There are several speculative "requests" for a donation of a license to Debian for this purpose as well as a plea to Intel to release the suite in .deb format instead of just RPM. All in all it was an interesting read.

  • AMD (Score:4, Interesting)

    by Per Wigren ( 5315 ) on Sunday November 24, 2002 @05:21AM (#4742308) Homepage
    How much faster will it be on AMD processors then?

  • by SweenyTod ( 47651 ) <.sweenytod. .at. .sweenytod.com.> on Sunday November 24, 2002 @09:29AM (#4742752) Homepage
    Is GCC still the only compiler that can build the linux kernel sucessfully?
    • by Ryu2 ( 89645 ) on Sunday November 24, 2002 @09:37PM (#4747472) Homepage Journal
      It's doubtful that compiling any OS kernel with Intel's compiler will result in significant speed increases. Most architectural optimizations that the Intel compilers make that gcc doesn't lie in the area of SIMD instructions, and instruction scheduling to maximize pipelining, parallelism, etc. It will be very useful in areas such as graphics, multimedia, other heavy-duty computation, and the like, but not in a general purpose OS, where the instructions are mainly loads and stores of data.

      • Er, in all fairness the question had little to do with performance. He simply asked if the Linux kernel even *could* be compiled with anything but GCC. I believe the answer is still a very flat "no."
  • by Anonymous Coward

    Just for peoples reference, I came across these patches for the FreeBSD kernel (LINT) to get it going with icc.

    I haven't tried them yet but I would love to see the whole of FreeBSD compiled with icc. The speed increase would be very cool.

    icc_20020721.diff [leidinger.net]

    --
    Dreamweaver Templates [dynamicexpression.com]

It appears that PL/I (and its dialects) is, or will be, the most widely used higher level language for systems programming. -- J. Sammet

Working...