FTC Announce Settlement With Intel

Quote:

---

Originally Posted by Manicdan

whats the point of standards like AVX, if your going to try and build stuff to not be 100% compatible with it.
should the software compaines be hurt because they have to deal with unreliable performance, or have to specifically deal with different instructions, adding to their cost

what would the ideal solution be for the software companies?

---

Use a different compiler? The question is, must (and also, why should) the Intel Compiler folks spend their time optimizing & testing their compiler output for non-Intel processors? For free? AMD, Via, etc just get to enjoy the fruits of the IC team's labors?

Maybe AMD should offer to pay Intel's compiler team? Or Microsoft's? Or spend money helping improve gcc?

I realize that at first glance, it's easy to be filled with poutrage: "Why not just check for the AVX bit alone!!!!!!?????111" But if you think about it, there's more involved, the chips and their behavior are not identical, making that change could actually lead to degraded amd performance or worse in some corner case (and so imagine Intel's concerns about what a historically litigious AMD would do in that event), Intel is not a charity, there are other compilers available, blah blah blah.

Quote:

---

Originally Posted by Manicdan

what would the ideal solution be for the software companies?

---

One platform, just like console where the hardware is everywhere the same. :p:

Quote:

---

Originally Posted by terrace215

Maybe AMD should offer to pay Intel's compiler team? Or Microsoft's? Or spend money helping improve gcc?

---

ahhh the power of having the "almost" monopoly of the x86 architecture.... getting to dictate which compiler should a developer use :yepp:

Quote:

---

Originally Posted by terrace215

Use a different compiler? The question is, must (and also, why should) the Intel Compiler folks spend their time optimizing & testing their compiler output for non-Intel processors? For free? AMD, Via, etc just get to enjoy the fruits of the IC team's labors?

Maybe AMD should offer to pay Intel's compiler team? Or Microsoft's? Or spend money helping improve gcc?

I realize that at first glance, it's easy to be filled with poutrage: "Why not just check for the AVX bit alone!!!!!!?????111" But if you think about it, there's more involved, the chips and their behavior are not identical, making that change could actually lead to degraded amd performance or worse in some corner case, Intel is not a charity, there are other compilers available, blah blah blah.

---

i dont think intel would take amds money and optimize their code. i would bet this is much less about intel offering a great tool, and more about preventing the opposition from gaining any grounds. the more people that use intels compiler, the easier it is for them to hold down the competition.

my opinion is to ban intel and AMD from making a compiler, and have a third party make and test the code, and can accept resources (tricks for their arch) from either party, but not cash. the cost should be covered when paying for things like visual studios. in the end the cost is the same, since intel can spend less on their compiler and reduce the cost of cpus (even if its just by pennies).

Quote:

---

Originally Posted by Hornet331

One platform, just like console where the hardware is everywhere the same. :p:

---

i think that would be a monoploy

but imagine if were talking about trains and tracks. AMD and intel make tracks, but intel also makes a train that can go 5mph faster on their tracks. next thing you know the train you bought crashes into your shop cause the tracks at your shop are by AMD. you call and intel says, o we were able to get that speed increase at a slight risk that you would derail on others tracks, sorry for the death of your employees. i bet they would respond "there f-ing trains, its suppose to work on any train track!!"

You asked for the ideal solution for the software developers, and thats it. You don't need to make a train analogy cause it sucks... same of all the car analogies.

If you have only one platform if a fixed set of hardware, it is software developer haven because they know exactly what they can do and what not, which bugs the hardware has and how they can work around it.

Quote:

---

Originally Posted by Manicdan

i dont think intel would take amds money and optimize their code. i would bet this is much less about intel offering a great tool, and more about preventing the opposition from gaining any grounds. the more people that use intels compiler, the easier it is for them to hold down the competition.

my opinion is to ban intel and AMD from making a compiler, and have a third party make and test the code, and can accept resources (tricks for their arch) from either party, but not cash. the cost should be covered when paying for things like visual studios. in the end the cost is the same, since intel can spend less on their compiler and reduce the cost of cpus (even if its just by pennies).

---

If you're going to ban Intel and AMD from making compilers, why not ban them from making GPUs, as well? Chipsets? Drivers? Who is the bureaucrat in charge of all this banning? Ah, I know the perfect person: Neelie Kroes. ;)

I don't know why there is even a debate about Intel not enabling certain features for AMD CPU's. Obviously there are reliability questions in doing so, and reliability is paramount.

You want to dispute that? Cyrex. End of discussion. They made Intel CPU clones and were the AMD of the early 90's, and you know what? Programs that ran on Intel CPUs would sometimes not work on Cyrex CPUs because not all x86 is created equal. Then, again in the 90's, AMD came out and they too had some stability issues that came about from not being exactly the same as Intel. The only company with an x86 license who I'm not aware of running into this issue is VIA, and I actually wouldn't be surprised if they had but I just didn't hear about it.

So that's twice in recent history that it has turned out other manufacturers were not up to snuff, yet some people think Intel must put their own rep (==money) on the line to claim that AMD is? It just doesn't make sense. Now if AMD offered money to Intel to fully pay to have the compiler tested then sure, I would say it is fair to force Intel to enable the optimizations because they do have such a large portion of the market, but failing that...

It's Cyrix and I'm not sure I've heard that their x86 implementation had any issues.

Quote:

---

Originally Posted by terrace215

If you're going to ban Intel and AMD from making compilers, why not ban them from making GPUs, as well? Chipsets? Drivers? Who is the bureaucrat in charge of all this banning? Ah, I know the perfect person: Neelie Kroes. ;)

---

way to take a simple idea and blow it to stupid proportions

intel made compilers, and is now forced to change that cause they did it wrong. its a simple conflict of interest and if you remove that conflict, the problem can be removed.

you say they should use other compilers as the ideal solutions. so why get mad if they just simply dont, or cant, make their own compiler?

Quote:

---

Originally Posted by Serra

I don't know why there is even a debate about Intel not enabling certain features for AMD CPU's. Obviously there are reliability questions in doing so, and reliability is paramount.

You want to dispute that? Cyrex. Beginning of discussion.

---

you mean the company that didnt have an x86 license?;)

AMD and intel x86 implementations are virtually identical in terms of binary compatibility. x86_64 has some memory architecture differences but they are handled by the OS and are mostly trivial.

to back up the fact that these cpu's are binary compatible, 80% of c/c++ code today uses SSE2. you dont see 80% of applications crashing on AMD or via hardware because it is not from intel. if i had the time i could test every x86 instruction on both AMD and intel cpu's in kernel mode and i dont think i would be able to find an instruction that didnt work. dont forget that AVX can be up to 60x faster than x87. it's not very smart for a compiler to only run it on select processors.

Quote:

---

Originally Posted by informal

It's Cyrix and I'm not sure I've heard that their x86 implementation had any issues.

---

They had some big issues. I was reminded of this because I was working with some people just earlier today who were in charge of major distributions for the US government and they were talking about how many software issues they had with Cyrix processors, which is not to mention the blatent hardware issues (eg. plug in an old soundblaster card and it kills your machine if you're using a Cyrix processor).

Quote:

---

Originally Posted by Chumbucket843

you mean the company that didnt have an x86 license?;)

AMD and intel x86 implementations are virtually identical in terms of binary compatibility. x86_64 has some memory architecture differences but they are handled by the OS and are mostly trivial.

to back up the fact that these cpu's are binary compatible, 80% of c/c++ code today uses SSE2. you dont see 80% of applications crashing on AMD or via hardware because it is not from intel. if i had the time i could test every x86 instruction on both AMD and intel cpu's in kernel mode and i dont think i would be able to find an instruction that didnt work. dont forget that AVX can be up to 60x faster than x87. it's not very smart for a compiler to only run it on select processors.

---

True enough that they didn't, but a license is just a piece of paper for lawyers... not a golden ticket to perfect implementation. Back then it was a lot easier to copy a design than it is now.

AMD and Intel may be virtually identical, but the case is that if there is ANY difference whatsoever that could hinder performance or stability Intel would be actively shooting themselves in the foot to allow it because they'll be sued out the wazoo for causing instability in AMD systems. "Mostly trivial" issues can cost you hundreds of millions of dollars if they happen to come up during a custom application on a mainframe, and can lose you an enterprise as a customer if you make them think you are unreliable. This issue goes well beyond the occasional blue screen that a single user may have if they do one bizarre thing... businesses use computers in ways most consumers aren't even aware of, running all kinds of crazy custom apps... and if it turns out that it runs wonky...

TBH AMD shouldn't even want the options turned on if they're untested. Not forcing Intel to enable everything could save AMD a lot of money if it turns out that some of those features could, in the most bizarre usage scenarios, cause massive instability... if it turns out that those scenarios come up in a mainframe application... or even the next version of Windows.

i have no problem with intel keeping there crummy compiler, the main thing was that they did not tell devs that non intel cpus would be gimped. hence the 10mln fund.

Quote:

---

Originally Posted by informal

It's Cyrix and I'm not sure I've heard that their x86 implementation had any issues.

---

Well, among other issues, there was one bug that caused a 20%-30% performance degradation with a Cyrix 6x86 chip under Windows NT:

http://www.realworldtech.com/altcpu/...aq/faq4of7.htm

Quote:

---

Microsoft did, however, discover a bug in the Cyrix 6x86 processor during stress testing of NT 4.0 that caused the operating system to crash. To guarantee Windows NT 4.0 stability, a workaround was developed by both companies. In the workaround, the chip's internal cache operating mode is changed from write-back to write-through when a problematic 6x86 is discovered. The result is a performance degradation of approximately 20%-30%.

---

Also, the Cyrix 6x86 by default did not respond to the CPUID instruction. To detect it properly (and identify it as a Pentium-class processor) programmers had to use special code for Cyrix processors, which many programmers opted not to do.

Though the 6x86 had many architectural features matching a P6 Pentium Pro such as out-of-order execution, it did not implement certain Pentium (P5)-supported instructions, which caused it to not truly be Pentium-compatible. This caused issues with software that relied on these instructions, including the Creative Soundblaster AWE64 drivers. Also, while its integer execution was much stronger than a Pentium of similar clockspeed, its FPU was much weaker, which became important when Quake became a popular game.

I remember overclocking a Cyrix III in a BE6-II to 650mhz or something and it running worse than a celeron 366 in quake 3... :p

Quote:

---

Originally Posted by STEvil

I remember overclocking a Cyrix III in a BE6-II to 650mhz or something and it running worse than a celeron 366 in quake 3... :p

---

lol yeah i had a cyrix as well, every time i played heroes of might and magic, it kept crapping out.

Optimization is different from running the code in question at all. Yes, there will be codes that are customized to be hardware specific, then again, AVX is AVX... or for that matter, take any other such instruction set. Optimization is done in order to tailor a specific code to run faster on a given piece of hardware. Thanks to difference in architecture the given code may run fast or slow on one particular processor, and that is acceptable as it is but common sense. Here, the compiler is simply not running that piece of code, even if support for the same is present and that's what is wrong.

What i'm suggesting is:

if AVX {
if Intel {}
else {}
}

Something like this would not be too hard to do... only changing a few lines here and there :P Then again, it may drastically reduce the gap in performance, which is why perhaps Intel is not doing so. The current scenario should be seen as "disabling" features, rather than "lack of optimization... The latter is a pretty weak argument! I don't think any judge with any percentage of common sense will agree with this to be "lack of optimization." Then again, US lawmakers and the justice system have disappointed people a fair bit :P Not that the situation is any better in my country, but we are third world no matter what our darned ministers say...

Quote:

---

Originally Posted by tifosi

AVX is AVX... or for that matter, take any other such instruction set.

---

EXACTLY CORRECT.

If Intel has an "enhanced instruction set" then there is an issue. But if they claim to adhere to the published instruction set they need to correctly support that for all chips OR PROVIDE A HUGE WARNING MENTIONING THAT THEIR COMPILER DOES NOT SUPPORT THE STANDARD. It is not a question of optimization unless Intel has added undocumented enhancements to that published instruction set. In which case their chip doesn't properly support that instruction set.

If a CPU supports an instruction set then it will return a positive answer when queried about whether it supports that instruction set. It is not Intel's responsibility to test whether the chip truly supports the instruction set. It is up to the chip creator to verify support of that instruction set before they allow the chip to answer in the positive to that query.

It is naive to pretend that this is an issue of Intel not wanting or needing to test. It is also naive to pretend that this is an issue of "optimization" when it is merely a question of supporting a documented and published set of instructions.

EDIT: In truth the compiler developers don't really need to do extensive testing of each and every CPU. They do need to certify that their compiler correctly supports the instruction sets. (I.e., the CPU hardware people should have already ensured that the hardware supports the instruction set.) Of course in the real world they WILL do the testing; but theoretically they do not need to.

Although it is unlikely they will test every CPU they have ever made... they will just test relevant chip architectures and in truth they are not really testing the chips they are testing their compiler. In other words the confidence in the hardware is higher than the confidence in the software. The hardware goes through much more extensive testing and validation procedures than the software.