Out of court settlement with FTC
Yesterday, the Federal Trade Commission (FTC) announced that they are going for an out of court settlement with Intel. See their press release and proposed decision.
I will comment only on the part of the settlement that deals with Intel's compilers and function libraries. The FTC orders that Intel must inform its software customers about the CPU dispatch mechanism that leads to suboptimal performance on non-Intel CPUs. It also recognizes that certain published benchmarks were misleading. The advantage of an out-of-court settlement is that it is faster. A court battle could take so long time that the issues were obsolete before a decision was made. In a comment, the FTC explains that the purpose of the order is not punitive but remedial.
The settlement with FTC is less far-reaching than the settlement with AMD. The AMD settlement requires that Intel remove any "Artificial Performance Impairment", while the FTC settlement requires only that Intel inform their customers of what they do. This will not solve the problem, only make it more visible. The wording of the settlement is also somewhat ambiguous as to which clauses apply to both the compiler and the function libraries, and which clauses apply to the compiler only. This is unfortunate since many software developers are using the Intel function libraries without using the Intel compiler.
The FTC have asked me to testify in court about the CPU dispatching in Intel's compilers and function libraries. I will not have to do this now, of course, but I will continue to publish my findings here on my blog. I am currently doing a survey
of software that is affected by the biased CPU dispatching and I am going to publish the results here soon.
Since Intel have not removed the biased CPU dispatching from their MKL library despite the settlement with AMD, and since the settlement with FTC does not require them to do so, we can expect that the problem will persist.
It is interesting that the FTC in their comment suggests that software developers can override the code dispatch mechanisms in Intel compilers and libraries. This is a technique that I have developed and described in my C++ manual. However, I doubt that commercial software developers will be happy to use such hacking techniques that rely on undocumented features.
The response of the software community will probably be to avoid Intel software products entirely. In my test of the optimizing performance of C++ compilers, the Intel compiler and the Gnu compiler for Linux shared the first place. Unfortunately, the Gnu compiler for Windows is not up to date so we still need a good replacement for the Intel compiler for Windows. It is not a profitable business to make a well optimized math function library. If we cannot use Intel's libraries then we probably have to rely on the open source community for making such libraries. The Gnu function libraries (glibc) are not very well optimized, so there is still a lot of work to do. The work of optimizing the Gnu function libraries is going very slowly and is done mainly by an Intel guy. Why don't AMD and independent programmers contribute to this work to make sure the software performs well on non-Intel processors as well?
After all, the FTC settlement leaves the software community with more problems than we could expect after the AMD settlement. Maybe this reflects the limited power of the FTC? |