Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Intel

Benchmarking Intel C++ 6.0 to GNU g++ 3.0.4 59

axehind writes: "Here is a good article detailing a benchmark [comparison] between the two compilers. The results are very interesting."
This discussion has been archived. No new comments can be posted.

Benchmarking Intel C++ 6.0 to GNU g++ 3.0.4

Comments Filter:
  • by lprimak ( 538633 ) <{lprimak} {at} {hope.nyc.ny.us}> on Friday May 10, 2002 @12:13AM (#3494798) Homepage
    Intel compiler works great, except for handling exceptions in a multi-threaded program. The exception stacks get mangled if multiple threads throw/catch exceptions at the same time. gcc exception handling is completely thread-local so there is no locking and it works great. That's why I can't use icc for my own product. My info is about 3 months old. I wonder if they fixed this...?
  • by V. Mole ( 9567 ) on Friday May 10, 2002 @11:06AM (#3496820) Homepage

    What can happen with inlining is that code size expands to be larger than the available CPU cache memory. (Re-)Loading code from main memory (or slower cache, for CPU's with multi-level caches) is slower than a few register updates. You can see the same effect with loop-unrolling, although given the way CPU caches have grown means it's becomeing less of a factor.

    Note in particular the article's observation that "inlining doesn't show any slowdown" is exactly that: an observation, applicable to that particular processor. A serious project would have to benchmark their particular application on their particular target machine to determine the best choice of compiler options.

  • Official Addendum (Score:5, Informative)

    by ChaoticCoyote ( 195677 ) on Friday May 10, 2002 @02:24PM (#3498264) Homepage

    At the least the site stayed running with the spike in hits...

    I'm putting together some "large" benchmarks for the "rematch" when gcc 3.1 hits reality next week. The problem with most "real world" programs is that they're interactive or I/O bound, masking the code generator's abilities.

    I need to be clear about one thing: Anyone who tosses out gcc over this review is a fool. Intel C++ is a good product for very specific applications, but it does not replace gcc. All the benchmarks show is that Intel C++ can provide a performance boost for certain classes of computationally-bound programs. For some of my scientific work, Intel kicks ass in comparison to gcc... for some other projects, gcc comes out on top. What's important is choice and competition, which fuel evolution...

    I urge people to read the entire article before making any assumptions about my goals or the results.

  • Profiling feedback (Score:3, Informative)

    by Skuto ( 171945 ) on Friday May 10, 2002 @04:54PM (#3499275) Homepage
    They missed the most important part: profile feedback optimizations.

    This is one part where Intel C really gets way and beyond the GCC compiler. Compile first with -prof_genx, run program, recompile with -prof_use.

    The speedups are _big_. Intel C will totally kick GCC's butt with this option enabled.

    GCC can also do profiling feedback optimizations, but it is not nearly as good.

    --
    GCP
  • by sasami ( 158671 ) on Friday May 10, 2002 @06:03PM (#3499618)
    Think of mp3 decoding, divx playing, 3d games, etc...
    No, SSE or 3DNow is a much better choice than -ffastmath for that kind of thing. I'm pretty sure Winamp supports both instruction sets, and I'd be very surprised if the compute-heavy DivX didn't employ them, too.

    You might give up precision when using SIMD (on x86 anyway) but at least you can control that. Using -ffastmath is much more of a toss-up. Case in point, LAME has been observed to produce seriously different results when compiled with -ffastmath.

    ---
    Dum de dum.

Living on Earth may be expensive, but it includes an annual free trip around the Sun.

Working...