4 ms·

..only on Intel chips. It deliberately generates code that runs slow on non-Intel CPUs: http://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler#Criticism http://en

by copx 13y ago

..only on Intel chips. It deliberately generates code that runs slow on non-Intel CPUs: http://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler#Criticism http://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler#Criticis... As an AMD user I really hope most programmers know this by now. If you make a build for the general public as opposed to only targeting Intel machines, please don't use ICC.

berkut 13y ago
Not since 2010 it doesn't: http://www.hardware.fr/articles/847-1/impact-compilateurs-architectures-cpu-x86-x64.html http://www.hardware.fr/articles/847-1/impact-compilateurs-ar... It can generate code which when run on AMD is faster than GCC and MSVC.
- 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.

by copx 13y ago

berkut 13y ago

Not since 2010 it doesn't: http://www.hardware.fr/articles/847-1/impact-compilateurs-architectures-cpu-x86-x64.html http://www.hardware.fr/articles/847-1/impact-compilateurs-ar... It can generate code which when run on AMD is faster than GCC and MSVC.

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.