4 ms·

> The second problem is that buyers of AMD products demand that Intel would release their software optimized for AMD products as well, which is just nonsensical

by burnte 7y ago

> The second problem is that buyers of AMD products demand that Intel would release their software optimized for AMD products as well, which is just nonsensical. First, Intel is not required to do this and have no reason to do so - if this software doesn't work for your hardware, either buy Intel, or use something else. While Intel isn't REQUIRED to do so, it absolutely is a sensible thing to do. If my customers need something, I want to provide it to them. If my customers want me to add a feature that makes their products run well on competitors' CPUs, then its in my best interest to make that happen, if I can get the other CPU maker to give me the data I need. This makes my direct customer happy, makes me look good for prospective customers, and builds loyalty to my brand. It also makes my customer happy by making THEIR customers happy, which keeps them customers of mine.

usefulcat 7y ago
All of those points would be a lot more relevant if Intel were a software company, or if it at least got a significant portion of it's revenue from software sales. I very much doubt that's the case though.
- burnte 7y ago
  They make the compiler to make their CPUs more attractive.
headmelted 7y ago
While I would like this issue resolved I'm not sure I follow your logic at all that Intel should be the people to fix it. When there are only two viable options in a marketplace, offering improvements to make your direct competitor's product better than yours is shooting yourself in the foot. Your point about happy customers would make sense if Intel was selling all manner of service contracts and extraneous engagements with it's consumer base, but is it? I'm pretty sure the chip business is speed / cost and that's all. What's ironic is that AMD knows better than any tech company I can think of exactly what the rewards are for coming second in the chip game.
berkut 7y ago
I totally buy that Intel should use the feature flags instead of checking the CPUid name for stuff like AVX, FMA, etc... However, ICC does support several advanced optimisations whereby it literally schedules instructions based on expert knowledge of architecture cycle latency and number of ports: LLVM and GCC have similar tables for overall stats which I think AMD contribute to, but ICC can also hook in memory and cache bandwidth / latency to schedule instructions: this by definition would need to be Intel-specific, unless AMD were happy to give Intel this information. So some of the optimisations are by definition Intel-only. The question really is how fair should the fall-backs be.
- wtallis 7y ago
  > So some of the optimisations are by definition Intel-only. The benefits of those optimizations may or may not be Intel-only, but the machine code emitted by the compiler is not Intel-only.
  - berkut 7y ago
    Yes, but if you're interested in performance, it's very possible that using the wrong scheduling of instructions for those particular optimisations (very particular scheduling ones) will result in extremely bad performance due to pipeline stalls, so running the machine code on the wrong architecture (possibly even among Intel platforms) will not give good performance other than on the explicit machine it's optimised for. Keep in mind that ICC supports dynamic code paths for different marchs, so in theory you could have code for Intel 6th Gen, 7th Gen, 8th Gen, etc all dynamically switchable at run time.
    - temac 7y ago
      > extremely bad performance Given how a modern high perf processor work, I don't expect that at all. Moderately bad performance in some extremely rare cases, and comparable performance in most, is WAY more probable. Better performance in some cases is also possible. If you don't know the microarchitecture enough, you can also just look at benchmarks of Zen processors. They are vastly running code non-tuned for it, and for some loads I expect the code was actually tuned for Skylake, given all desktop Intel processors have been Skylake microarch for a non trivial number of years. It performs well on Zen.
loeg 7y ago
Intel is very much of the mindset of that it is a silicon company selling hardware and everything else is accessory to that. The software is just inducement to use the hardware. Users of the compiler are not inherently customers; they're only customers if they're using the Intel compiler on Intel CPUs. Yes, it's a weird mindset for a company that employs a lot of software engineers.

by burnte 7y ago

usefulcat 7y ago

All of those points would be a lot more relevant if Intel were a software company, or if it at least got a significant portion of it's revenue from software sales. I very much doubt that's the case though.

burnte 7y ago
They make the compiler to make their CPUs more attractive.

headmelted 7y ago

While I would like this issue resolved I'm not sure I follow your logic at all that Intel should be the people to fix it. When there are only two viable options in a marketplace, offering improvements to make your direct competitor's product better than yours is shooting yourself in the foot. Your point about happy customers would make sense if Intel was selling all manner of service contracts and extraneous engagements with it's consumer base, but is it? I'm pretty sure the chip business is speed / cost and that's all. What's ironic is that AMD knows better than any tech company I can think of exactly what the rewards are for coming second in the chip game.

berkut 7y ago

I totally buy that Intel should use the feature flags instead of checking the CPUid name for stuff like AVX, FMA, etc... However, ICC does support several advanced optimisations whereby it literally schedules instructions based on expert knowledge of architecture cycle latency and number of ports: LLVM and GCC have similar tables for overall stats which I think AMD contribute to, but ICC can also hook in memory and cache bandwidth / latency to schedule instructions: this by definition would need to be Intel-specific, unless AMD were happy to give Intel this information. So some of the optimisations are by definition Intel-only. The question really is how fair should the fall-backs be.

wtallis 7y ago
> So some of the optimisations are by definition Intel-only. The benefits of those optimizations may or may not be Intel-only, but the machine code emitted by the compiler is not Intel-only.
- berkut 7y ago
  Yes, but if you're interested in performance, it's very possible that using the wrong scheduling of instructions for those particular optimisations (very particular scheduling ones) will result in extremely bad performance due to pipeline stalls, so running the machine code on the wrong architecture (possibly even among Intel platforms) will not give good performance other than on the explicit machine it's optimised for. Keep in mind that ICC supports dynamic code paths for different marchs, so in theory you could have code for Intel 6th Gen, 7th Gen, 8th Gen, etc all dynamically switchable at run time.
  - temac 7y ago
    > extremely bad performance Given how a modern high perf processor work, I don't expect that at all. Moderately bad performance in some extremely rare cases, and comparable performance in most, is WAY more probable. Better performance in some cases is also possible. If you don't know the microarchitecture enough, you can also just look at benchmarks of Zen processors. They are vastly running code non-tuned for it, and for some loads I expect the code was actually tuned for Skylake, given all desktop Intel processors have been Skylake microarch for a non trivial number of years. It performs well on Zen.

loeg 7y ago

Intel is very much of the mindset of that it is a silicon company selling hardware and everything else is accessory to that. The software is just inducement to use the hardware. Users of the compiler are not inherently customers; they're only customers if they're using the Intel compiler on Intel CPUs. Yes, it's a weird mindset for a company that employs a lot of software engineers.