3 ms·

I don't read French but Intel's current official compiler documentation.. http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/composerxe/c

by copx 13y ago

I don't read French but Intel's current official compiler documentation.. http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/composerxe/compiler/cpp-win/index.htm http://software.intel.com/sites/products/documentation/docli... ..suggests nothing has changed. Search for "non-Intel". Maybe ICC generates code which beats GCC even when run on an AMD chip in one particular benchmark but that doesn't mean it generates better code in general. Personally I will never trust the Intel compiler, because it's part of their business strategy to generate bad code for AMD processors. Even if the claim in the original post about being "generally 15-20% faster" were true for Intel chips, it wouldn't be 15-20% faster on AMD or Intel's documentation - which clearly states the compiler generates inferior code for non-Intel chips - is wrong.

berkut 13y ago
You could look at the graphs - it's pretty obvious ICC wins in almost all benchmarks on all processors, not just one benchmark. Intel state they do different optimisations for different chips, and I'd guess it does it based on how many load/store ports there are as this seriously affects the fp throughput. These change per-chip - i.e. the core i7 sandy bridge doubled the number of front end float load ports from Nahalem, so more OOO execution can be done, and thus the compiler can generate code differently to take this into account. You can't expect Intel to optimise very thoroughly their compiler for all the processor models of their competitors.
- copx 13y ago
  >Intel state they do different optimisations for different chips, The documentation says more highly optimized for Intel® microprocessors than for non-Intel microprocessors. again and again. Not just different, inferior. Also the optimization notice mentioned in the Wikipedia article I linked, the one Intel was mandated to add by the courts is still there. Maybe I should quote the current version in full: Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice. >You can't expect Intel to optimise very thoroughly their compiler for all the processor models of their competitors. As I said I don't, I expect it to generate bad code for the products of the competition. And that's what it did and does. AMD dragged Intel to court over this and won. That's why the compiler documentation is now full of these "non-Intel" disclaimers. ICC exists to sell Intel processors, one should always remember that. Intel isn't trying to make money selling compilers..
  - berkut 13y ago
    > Not just different, inferior. Because they're not going to spend time working out by trial and error (it's possible based on timing and evaluating code) how many float ops / cycle each AMD chip can do. For their own chips they know the numbers themselves. So they make an assumption for non Intel chips. Maybe they assume 2 when some AMD chips can do 4. > ICC exists to sell Intel processors And strangely enough, if you use ICC you'll generally be getting better code out the other end regardless of what chip you run it on compared to the other two major compilers.
    - aidenn0 13y ago
      I don't know the current state of ICC, but previously it would ignore the instruction set the CPU claimed to support and not use a large fraction of SSE instructions on non Intel CPUs that supported it. Centaur did a study where they changed their CPU ID to pretend claim to be an Intel part and they got a significant performance boost when running code compiled with ICC.
  - marshray 13y ago
    > The documentation says more highly optimized for Intel® microprocessors than for non-Intel microprocessors. again and again. Not just different, inferior. No, it's "less superior". I don't see anything wrong with this, unless somehow Intel is preventing AMD from writing their own compiler and investing more into code generation for AMD chips than Intel's. > ICC exists to sell Intel processors, one should always remember that. I think it's probably more reasonable to look at it as ICC exists to ensure that Intel can ship new features, optimizations, and instructions in their chips and not be totally dependent on 3rd parties to make them available to C/C++ programmers.
- copx 13y ago
  I would like to add that I am not actually universally opposed to using ICC for general builds but one should carefully benchmark the resulting binary in those cases.. on a non-Intel machine. As I pointed out it is reasonable to assume that the code will run slower on non-Intel chips. Basically I just replied to the OP because I was worried about people blindly doing release builds with ICC assuming it means "higher performance for free". That maybe the case in some situations but given the background of the compiler one should always make sure.

by copx 13y ago

berkut 13y ago

You could look at the graphs - it's pretty obvious ICC wins in almost all benchmarks on all processors, not just one benchmark. Intel state they do different optimisations for different chips, and I'd guess it does it based on how many load/store ports there are as this seriously affects the fp throughput. These change per-chip - i.e. the core i7 sandy bridge doubled the number of front end float load ports from Nahalem, so more OOO execution can be done, and thus the compiler can generate code differently to take this into account. You can't expect Intel to optimise very thoroughly their compiler for all the processor models of their competitors.

copx 13y ago
>Intel state they do different optimisations for different chips, The documentation says more highly optimized for Intel® microprocessors than for non-Intel microprocessors. again and again. Not just different, inferior. Also the optimization notice mentioned in the Wikipedia article I linked, the one Intel was mandated to add by the courts is still there. Maybe I should quote the current version in full: Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice. >You can't expect Intel to optimise very thoroughly their compiler for all the processor models of their competitors. As I said I don't, I expect it to generate bad code for the products of the competition. And that's what it did and does. AMD dragged Intel to court over this and won. That's why the compiler documentation is now full of these "non-Intel" disclaimers. ICC exists to sell Intel processors, one should always remember that. Intel isn't trying to make money selling compilers..
- berkut 13y ago
  > Not just different, inferior. Because they're not going to spend time working out by trial and error (it's possible based on timing and evaluating code) how many float ops / cycle each AMD chip can do. For their own chips they know the numbers themselves. So they make an assumption for non Intel chips. Maybe they assume 2 when some AMD chips can do 4. > ICC exists to sell Intel processors And strangely enough, if you use ICC you'll generally be getting better code out the other end regardless of what chip you run it on compared to the other two major compilers.
  - aidenn0 13y ago
    I don't know the current state of ICC, but previously it would ignore the instruction set the CPU claimed to support and not use a large fraction of SSE instructions on non Intel CPUs that supported it. Centaur did a study where they changed their CPU ID to pretend claim to be an Intel part and they got a significant performance boost when running code compiled with ICC.
- marshray 13y ago
  > The documentation says more highly optimized for Intel® microprocessors than for non-Intel microprocessors. again and again. Not just different, inferior. No, it's "less superior". I don't see anything wrong with this, unless somehow Intel is preventing AMD from writing their own compiler and investing more into code generation for AMD chips than Intel's. > ICC exists to sell Intel processors, one should always remember that. I think it's probably more reasonable to look at it as ICC exists to ensure that Intel can ship new features, optimizations, and instructions in their chips and not be totally dependent on 3rd parties to make them available to C/C++ programmers.
copx 13y ago
I would like to add that I am not actually universally opposed to using ICC for general builds but one should carefully benchmark the resulting binary in those cases.. on a non-Intel machine. As I pointed out it is reasonable to assume that the code will run slower on non-Intel chips. Basically I just replied to the OP because I was worried about people blindly doing release builds with ICC assuming it means "higher performance for free". That maybe the case in some situations but given the background of the compiler one should always make sure.