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. |
Intel's "cripple AMD" function - Agner Fog - 2009-12-30
Intel's - Felid - 2010-01-01
