Let's see if they're as well-versed in law. I don't think this is completely proven territory that they're treading on.
I agree. It looks like lawyers who grew up with computers are finally taking over from the older generation. The FTC compaint is surprisingly up-to-date and well versed in technology, compared to what we've seen anywhere in the past. I wouldn't be surprised if some of them are seasoned AnandTech readers.
I'm with Cogman in that while I agree with behavior is not going to win any fuzzy-baby-bunny awards I don't see how or why it would be viewed as illegal or anti-competitive.
But I also understand that some business practices are viewed as simply being competitive (albeit asinine) when the market in question does not have any large dominating contenders but those same business practices are viewed as anti-competitive if/when used in a market which does contain a near-monopoly business.
So is this one of those cases? The legal issue here isn't so much what Intel did but rather that it was Intel (an effective monopoly, I beleive I read somewhere that is how it is legally viewed) doing it? And had Intel and AMD been more of equal marketshare competitors then this would simply be viewed as competition doing what competition does?
In this particular case, it was pretty clearly de-optimization of competitors products rather than simple non-optimization (i.e. not worrying about details of instruction scheduling on competitors products). Those who doubt it should look into the history of what Intel did.
This was with the P3 or the P4? I remember circa 1999-2000 that I had to use the PGI compilers to get could (fast) binaries for my Athlon-based cluster.
Poor Andy Grove, only the paranoid survive but for some reason they weren't paranoid enough about the government and the prospects of anti-trust reactions.
This is the point I've been trying to get across. Intels compiler is no where near being the lead compiler in the industry (and never has been). So how on earth could it be anti-competitive (The compiler aspect of things.)The CPU-ID check gives more information than checking the flags. For one knowing the uarch family allows optimizations far beyond simply turning on SSE{1,2,3}. Prefetching and cache line optimizations are important. A good compiler might dynamically disable SMT in certain processors due to replay thrash or tune loops to take advantage of Nehalem's LSD, etc.
That said, isn't the intel compiler an expensive software product designed for high performance computing? I fail to see how a product with negligible usage in the general software market can be anti-competitive. If that niche market is so important, what's stopping AMD from write their own tuned compilers?
The CPU-ID check gives more information than checking the flags. For one knowing the uarch family allows optimizations far beyond simply turning on SSE{1,2,3}. Prefetching and cache line optimizations are important. A good compiler might dynamically disable SMT in certain processors due to replay thrash or tune loops to take advantage of Nehalem's LSD, etc.
That said, isn't the intel compiler an expensive software product designed for high performance computing? I fail to see how a product with negligible usage in the general software market can be anti-competitive. If that niche market is so important, what's stopping AMD from write their own tuned compilers?
This is the point I've been trying to get across. Intels compiler is no where near being the lead compiler in the industry (and never has been). So how on earth could it be anti-competitive (The compiler aspect of things.)
Schmide, I had a big long response written up, but lost it due to a power failure. I don't really care to retype it, but here is the jist of what I was going to say.
CPUID is an x86 instruction. It is what is used to tell what instructions a CPU supports, processor family, ect. So intel would have been checking the CPUID regardless. There is no SSEy way to tell if a CPU supports SSE, it is all done through CPUID.
The other thing was that Intel doesn't advertise their compiler as a SSE compiler. They advertise it as a high performance compiler for C/C++/fortran/ect.
Finally, what Intel does with their compiler has absolutely no bearing on their license agreement with AMD. Their license trades the ability for AMD to use SSE instructions. That's it, nothing else. Their compiler was not a part of the deal. So saying that the compiler has any relation or bearing on the SSE license is ridiculous. That's I'll I'm willing to say about that. You have to realize that the software and hardware are two completely separate beasts. SSE is a hardware instruction set, not some sort of software innovation.
You might be wise to read up on what SSE actually is before you start spouting off more stuff about intels compiler not writing SSE code.
It writes it just fine, it would (in the past) just reroute the IP around the code. Dirty, yes, but in no way was it breaking the SSE instruction set or the x86 instruction set.
Uh huh... So intel doing price fixing on its own can't be considered anti-competitive...No one act, object, subsidiary can be considered anti-competitive. You must take the totality of all the acts to determine a coercive monopoly.
What do you mean yes and no. You can't determine if a CPU supports SSE (without crashing the program) without using CPUID. There is no other way. That is the only way you find out what instructions the CPU supports.Well yes and no. There are plenty of flags the determine the capabilities of an x86 processor. If you call cpuid with 0 you get the vendor ID, if you call it with 1 you receive information in 2 registers, eax contains the processor info and ecx contains the feature bits. The latter is where you determine the SSE capabilities, not the former. It would be putting the cart before the horse if you attempted to use an SSE instruction to figure out its own existence.
Orly
Read the link again, this article is in 2008, long after intel took out the CPUID code. The whole thing happened in the early 2000's (2005ish). Not only that, this is an instructional article, not a promotional article.? During the time of the CPUID block shown in the above link the big buzz was vectorization. Almost every talking point about the compiler was about how well it was able to automatically produce these instructions. As I remember it you are wrong.
They aren't blocking them. They aren't blocking them. They aren't blocking them. How many times do I have to say it before it sinks in? For them to block them, the SSE opcodes would have to literally not function on the AMD CPUs. Guess what, the GCC generates SSE code that runs on AMD cpus, MSVC generates SSE that runs on AMD CPUs, and individual asm programmers have been able to program SSE instructions that run on AMD CPUs. AMDs SSE instructions have worked just fine REGARDLESS of what intel did with their compiler.I would still beg to differ. Sounding like a broken record. AMD's license grants it the right to display it's opcode capabilities to the world and execute all code compatible with it's granted instruction set. Blocking a granted licensee, in my opinion, circumvents the purpose of the license.
Mostly because of the stuff you posted about there being an SSE function or flag to determine if SSE is there.WTH makes you think I don't understand SSE? I've coded assembly SSE FFS. Guess what? I check the cpuid 1 ecx register before spouting off about SSE opcodes. Why are you attacking me BTW? I think your ego is getting ahead of your argument.
Well, I guess we aren't really going to agree here. The compiler market is different and competitive. If Intel was to keep crippling AMD cpus in their compiler, they would only hurt their ability to sell the intel compiler.In my opinion, and apparently the opinion of the justice department lawyers, proper production of the opcodes requires the proper checks on the processor before the using of them. While more than likely technically legal, in the context of a coercive monopoly, it becomes a damming piece of the puzzle.
Comment: FTC's compiler attack on Intel is thin
Now let is try and see what the FTC is saying here.
Is the FTC saying that Intel has a duty to optimize its compiler software not only for its own processors but also for those of its competitors? And if so, which competitors should get the best treatment, because what is optimized for an AMD processor may not be as good for another x86 maker. So Intel would always be guilty of impairing someone's performance, including its own.
That does seem ridiculous. If I was being paid to create a successful processor-compiler combination I would be duty-bound to try and arrange things to my employer's best advantage and to help differentiate our product combination from those of the competition. If that meant organizing the compiler software so that procedures and the data they require flow smoothly on our processors but might incur a delay on a rival's processor, surely that is the nature of competition. Surely that is competitive rather than anticompetitive.
But wait, note the use of the word "secretly" and the phrase "failed to disclose."
It seems that the FTC is not objecting so much to fact that Intel tweaked its compiler as much as the fact that it didn't tell customers or the competition explicitly that the compiler works well with Intel processors but that it may not compile code as efficiently for other makes of processor.
The FTC's case seems to hinge on the fact that Intel said programs performed better on its processors when this was largely down to the impact of the compiler. Intel also took benefit from independent benchmark organizations that made use of the Intel compiler to create performance statistics.
But if benchmark organizations measure your products as performing well, would you choose to suppress the information?
http://www.eetimes.com/news/semi/showArticle.jhtml;?articleID=222002499
What do you mean yes and no. You can't determine if a CPU supports SSE (without crashing the program) without using CPUID. There is no other way. That is the only way you find out what instructions the CPU supports.
They aren't blocking them. They aren't blocking them. They aren't blocking them.
How many times do I have to say it before it sinks in? For them to block them, the SSE opcodes would have to literally not function on the AMD CPUs.
Guess what, the GCC generates SSE code that runs on AMD cpus, MSVC generates SSE that runs on AMD CPUs, and individual asm programmers have been able to program SSE instructions that run on AMD CPUs. AMDs SSE instructions have worked just fine REGARDLESS of what intel did with their compiler.
Would you claim that if I disable SSE code by hand for AMD processors by hand that I was blocking their granted license? No, it is crazy. Choosing not to run a competitors opcodes doesn't mean that you are stopping their opcodes from working. That is all the license permits, their right to let their opcodes work. Any other right is purely imagined.
This is all a moot point anyways, intel's compiler IS IN A DIFFERENT MARKET. They aren't the leaders in compilers making. I'll say it again. Intel is not the leader of compilers. They lag way behind in that market. Linking the two just doesn't make sense.
Mostly because of the stuff you posted about there being an SSE function or flag to determine if SSE is there.
Duh part of the SSE standards are how to determine what instructions are available on the processor. I guess adherence is only a standard when it's convenience.
If the code was valid, the entry point would check the flags and not the CPUID.
Well, I guess we aren't really going to agree here. The compiler market is different and competitive. If Intel was to keep crippling AMD cpus in their compiler, they would only hurt their ability to sell the intel compiler.
Nothing intel did prevented AMD from using SSE instructions, It may have made it harder for a few to use it, but it definitely didn't make it impossible. I would have a very different opinion if Intel had the lions share of compilers, but they don't and they haven't.
Big picture wise, I think they will get nailed by the FTC, no question. I just don't think that the compiler should be one of the reasons to nail them.