Agner`s CPU blog

Software optimization resources | E-mail subscription to this blog | www.agner.org

Intel's
Author: Deng Date: 2016-12-11 20:43
Recently I tested the inteldispatchpatch.zip (2014-07-30) in asmlib on MKL library in Intel Parallel Studio 2015 Update 3.
It gave me error like "Intel MKL ERROR: CPU 1 is not supported." on AMD servers. (from mkl_blas_xdgemv ()). If removing the 'dispatchpatch64.o' during linking, the MKL works on AMD servers.

It seems to me that the dispatch does not work on newer Intel MKL. do you know more way how to patch it correct?
Agner Fog wrote:

inhahe wrote:
I think it's arguable whether or not Intel crippled AMD via an "affirmative engineering or design action" as opposed to a "failure to act" (as distinguished in the settlement).
Checking for vendor ID is an affirmative action. The grey area is whether they are optimizing for specific CPU models or for specific instruction sets. There is only one case where they distinguish between different CPU models that have the same instruction set, namely Pentium 4 versus Pentium M. In most cases, however, they use the same code path for both, or the two paths are identical or almost identical. The distinction may be unimportant from a technical point of view, but it may give Intel a legal excuse for claiming that they are optimizing for specific CPU models.
I doubt Intel can be required to optimize specifically for a CPU that's not theirs
The settlement doesn't require that.
Another reason it's a gray area is that it's possible that the code path optimizations they took were obvious and would likely apply to any modern x86 CPU (though the fact that AMD and Intel are the only two players in the game sort of makes it beg the question),
Most optimizations are indeed obvious applications of the available instruction set. If you have SSE2 you can do four additions in one instruction. That's an obvious thing to do regardless of CPU model. Don't forget there is a third player, VIA. Their chips are fast enough for being relevant here.
given the small excerpt of the settlement shown, it seems possible to me that what they *actually* did is make something up that will sate AMD's lawyers while at the same time leaving the door open for them to either continue the same practice, or cease the practice (if it's too obviously anti-competitive or if they explicitly said they'd cease it elsewhere) but instate similar and/or related practices in the future, on account of the fact that those practices can easily be classified as "failures to act." [...] However, if the decisions for how and when to use SSE instructions are intricately tied in with the rest of their code path algorithm (and possibly rely on internal structure of the CPU design), then the caveats I brought up earlier still apply.
Yes, they will probably be able to claim that. From a merely technical perspective, I think it's a bad idea to make different code paths for two processors that support the same instruction set based on whether a particular instruction runs a little faster on one than on the other. If you consider the time it takes to develop a complete program plus the time it takes to market it, then it is likely that the processors you optimized for will be obsolete for your most demanding customers before the time your software peaks on the market. My advise would certainly be to optimize for the newest processor, but make sure you maintain compatibility with older processors.

But of course Intel compiler engineers are not obliged to listen to my advice if doing otherwise enables them to harm their competitors.

In any case, whether not supporting optimizations on AMD's CPUs was an affirmative design decision to undermine AMD machines or merely a failure to act (to benefit AMD machines), either way, it's clearly wrong for them to publish benchmarks to OEMs, etc. comparing AMD CPUs to Intel CPUs using their own compiler that specifically optimizes for Intel CPUs (based on Vendor ID no less!, but either way) and not for AMD CPUs. It's misleading, and according to the UTC, even when specifically confronted with the issue they would habitually either mislead or directly lie about the cause for the speed difference and whether it could be solved. So *that's* the part that's really devious, and I can see why the FTC sued them. I *hate* companies like that. Incidentally, though, all companies are companies like that.
Fortunately, not all companies are like that. I am sure this case has harmed Intel's reputation. They can be damn sure that their next compiler version will be thoroughly scrutinized. Hopefully, they will take their reputation into account when they design the next compiler version and function libraries.
 
thread Intel's "cripple AMD" function new - Agner Fog - 2009-12-30
reply Intel's new - Felid - 2010-01-01
replythread Intel's "cripple AMD" function new - inhahe - 2010-01-03
last replythread Intel's new - Agner Fog - 2010-01-04
replythread Intel's compiler is the best? new - Weber - 2010-01-04
last reply Intel's compiler is the best? new - Agner Fog - 2010-01-09
reply Intel article new - Agner Fog - 2010-01-22
last reply Intel's - Deng - 2016-12-11
replythread Web Parallels new - Jeff Craig - 2010-01-04
last replythread More Parallels new - Agner Fog - 2010-01-23
reply Early Examples new - Yuhong Bao - 2010-02-01
last reply More Parallels new - Yuhong Bao - 2010-02-20
replythread New CPUID manipulation program new - Agner Fog - 2010-01-22
replythread CPUID manipulation through virtualization new - Andrew Lofthouse - 2010-08-16
reply CPUID manipulation through virtualization new - Agner Fog - 2010-08-16
replythread CPUID manipulation program for AMD new - Agner - 2010-10-01
last replythread CPUID manipulation program for AMD new - Ralf - 2012-01-30
last reply CPUID manipulation program for AMD new - Agner - 2012-01-31
last reply CPUID manipulation through virtualization new - akshay - 2015-07-08
last replythread New CPUID manipulation program new - AVK - 2011-02-09
last reply New CPUID manipulation program new - Agner - 2011-02-09
reply AMD Blog on compilers/benchmarch new - margaret lewis - 2010-02-01
replythread New version is still crippling Intel's competitors new - Agner Fog - 2010-06-29
last reply New version is still crippling Intel's competitors new - granyte - 2014-09-16
reply Out of court settlement with FTC new - Agner Fog - 2010-08-05
reply AMD library contains Intel's cripple-AMD function! new - Agner Fog - 2010-08-11
replythread Common math programs are affected new - Agner Fog - 2010-08-20
last reply Preliminary test results for Matlab new - Agner Fog - 2010-09-16
reply Overview of CPU dispatching in Intel software new - Agner Fog - 2010-08-23
replythread New Intel compiler version - still the same! new - Agner Fog - 2010-09-22
reply GCC now has support for function dispatch new - Jean-Luc - 2010-09-27
replythread Intel compiler question new - James Russell - 2010-10-11
last reply Intel compiler question new - Agner - 2010-10-12
reply New Intel compiler version - still the same! new - Don Kretsch - 2010-11-29
last replythread New Intel compiler version - still the same! new - Daniel - 2011-12-23
last replythread New Intel compiler version - still the same! new - Agner - 2011-12-25
last replythread New Intel compiler version - still the same! new - Stanley Theamer - 2012-02-12
last reply New Intel compiler version - still the same! new - Stretcho - 2012-03-14
replythread Still no library that is optimal on all processors new - Agner - 2012-04-18
replythread Still no library that is optimal on all processors new - Guest - 2012-05-17
last replythread Still no library that is optimal on all processors new - Agner - 2012-05-17
last replythread Still no library that is optimal on all processors new - David - 2012-05-19
last replythread Still no library that is optimal on all processors new - Agner - 2012-05-20
last reply Still no library that is optimal on all processors new - Bubba_Hotepp - 2012-06-16
last replythread Still no library that is optimal on all processors new - Marat Dukhan - 2013-05-20
last replythread Still no library that is optimal on all processors new - Agner - 2013-05-21
last replythread This is still going on, wow just wow new - Vuurdraak - 2016-11-10
last replythread This is still going on, wow just wow new - Agner - 2016-11-10
last replythread This is still going on, wow just wow new - Vuurdraak - 2016-11-11
last replythread This is still going on, wow just wow new - Denis - 2017-01-02
last replythread This is still going on, wow just wow new - Agner - 2017-01-02
replythread RYZEN thoughts? new - Noob programmer - 2017-03-10
last replythread RYZEN thoughts? new - Chromatix - 2017-03-16
last replythread RYZEN thoughts? new - Peter - 2017-04-11
reply RYZEN thoughts? new - Agner - 2017-04-12
last reply RYZEN thoughts? new - itsmydamnation - 2017-04-21
last reply This is still going on, wow just wow new - Naoki Shibata - 2017-07-19
last replythread A long history of legal antitrust battles new - Agner - 2017-07-27
last reply A long history of legal antitrust battles new - Jorcy Neto - 2017-07-27