FTC Announce Settlement With Intel

So if AMD supports the same instruction set as intel(like AVX) ,intel is able to force the non-AVX option if the AMD chip is detected?

Quote:

---

As used in this Section 2.3, “ Artificial Performance Impairment ” means an affirmative engineering or design action by Intel (but not a failure to act) that (i) degrades the performance or operation of a Specified AMD product,

(ii) is not a consequence of an Intel Product Benefit and (iii) is made intentionally to degrade the performance or operation of a Specified AMD Product. For purposes of this Section 2.3, “ Product Benefit ” shall mean any benefit, advantage, or improvement in terms of performance, operation, price, cost, manufacturability, reliability, compatibility, or ability to operate or enhance the operation of another product.

---

@ terrance
did the compiler every do "If (AMD_processor) waste_time;"
last i herd it just didnt like anything non intel

im not trying to figure out what the exact thing is thats allowed or not
i was only curious why the FTC said to do something that is of less restricting than what they have to do for the AMD settlement. and thanks to informal it seems just so the FTC can get mad at intel, if AMD dosnt (if the rule was broken again)

Intel just can't play fair. :( Who wins?

who actually cares what intel does with there own software... most programmers use MSC and GGC anyway... also you can force certain flags even on the ICC... now if intel would pay MS and force other compiler developers to do the same we would have a real case.

Well many use intel function libraries(separately) which also has this issue(Agner Fog's blog):

Quote:

---

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?

---

Quote:

---

Originally Posted by Hornet331

who acutalyl cares.. most programmers use MSC and GGC anyway... also you can force certain flags even on the ICC...

---

Why would someone use GCC for performance critical software on Windows environment, as ICC is faster? The Windows version of GCC is slower than the Linux version. On Linux GCC is about just as fast as ICC, if not even faster in some cases.

Many people care, when programs like PCMark are compiled with CPU dispatching in place, resulting in skewed benchmark results. Also, Intels math library (MKL) uses the CPU dispatching, resulting slower code for non-Intel CPUs. This has nothing to do with Intel compiler, as the library is completely separate piece of software, which is used by many projects. And there is no real equivialient to it. Again, all the software which use MKL, also use the CPU dispatching, and also have crippled performance on non-Intel CPUs.

So practically every piece of software which uses Intel compiler OR Intel Math Kernel Library suffer from this issue.

Quote:

---

Originally Posted by Calmatory

Why would someone use GCC for performance critical software on Windows environment, as ICC is faster? The Windows version of GCC is slower than the Linux version. On Linux GCC is about just as fast as ICC, if not even faster in some cases.

Many people care, when programs like PCMark are compiled with CPU dispatching in place, resulting in skewed benchmark results. Also, Intels math library (MKL) uses the CPU dispatching, resulting slower code for non-Intel CPUs. This has nothing to do with Intel compiler, as the library is completely separate piece of software, which is used by many projects. And there is no real equivialient to it. Again, all the software which use MKL, also use the CPU dispatching, and also have crippled performance on non-Intel CPUs.

So practically every piece of software which uses Intel compiler OR Intel Math Kernel Library suffer from this issue.

---

And what hinders a programmer to use ACML?
If they want to program for maximum performance they use the appropriate library for the appropriate cpu... :shrug:

The intel function libraries are the big problem like Calmatory said. And there is no indication they will "fix" this anytime soon.

Quote:

---

Originally Posted by informal

So if AMD supports the same instruction set as intel(like AVX) ,intel is able to force the non-AVX option if the AMD chip is detected?

---

No, rather, Intel is under no obligation to ENABLE the AVX pathway for any AMD chip. ;)

And that's actually reasonable, why should they have to QA every corner-case of AMD's parts as well as their own? They want to uphold certain reliability claims with the code their compiler generates. Competitors don't get a free ride.

AMD & Agner are free to write their own compiler.

The FTC said, ok, you put a big red warning box up that lets compiler users know your compiler isn't necessarily optimal for non-Intel parts, and set out $10M for software devs who claim they didn't understand this in the past, and you're good to go.

(And, as mentioned before, the AMD-Intel settlement merely says Intel won't *affirmatively* *slow down* AMD's chips (essentially, relative to base x86), not that they must optimize for them.)

so should the intel compiler just not work at all? what instructions are so idiot proof that its guaranteed to work?

Quote:

---

Originally Posted by terrace215

No, rather, Intel is under no obligation to ENABLE the AVX pathway for any AMD chip. ;)

And that's actually reasonable, why should they have to QA every corner-case of AMD's parts as well as their own? They want to uphold certain reliability claims with the code their compiler generates. Competitors don't get a free ride.

AMD & Agner are free to write their own compiler.

---

There are under no obligation to enable it, but if by specific action they disable it then they are artificially limiting the performance of AMD cpus. Feel free to attempt to spin this as a good thing, you may as well be wearing a fanboy hat.

Quote:

---

Originally Posted by MrMojoZ

There are under no obligation to enable it, but if by specific action they disable it then they are artificially limiting the performance of AMD cpus. Feel free to attempt to spin this as a good thing, you may as well be wearing a fanboy hat.

---

That's exactly how I read it too. It's AMD's(Via's) responsibility to provide full compatibility of certain instruction sets if they decide to implement them,or at least warn the customers of certain incompatibilities.

Quote:

---

Originally Posted by Hornet331

And what hinders a programmer to use ACML?
If they want to program for maximum performance they use the appropriate library for the appropriate cpu... :shrug:

---

Nothing really. But it's not the developers to blame, rather the Intel MKL and it's CPU dispatching.

In practice it is not possible to have two branches of software which use different libraries to do the same task. Nothing stops you from doing that, but tracing bugs and implementing new features is painful. It is much easier to write platform independent ANSI C and have the program run everywhere where there is a C compiler available(with libraries compiled too), yet very tiny minority of Windows software is anywhere near platform independence, due to sheer laziness and cutting costs. So no ACML for most projects.

Isn't there a CPU identifier trick that allows us to change an AMD process to a 'Genuine_Intel'? Some site did a test a year or more ago concerning this and got some very interesting results. I believe it was XBitLabs possibly (I'll have to look after work today). I'd really like to trick software into thinking my CPU is an Intel and see how everything performs. It seems there is a :banana::banana::banana::banana:ton of lost performance in a lot of software I use.

Mechromancer,on modern AMD chips it doesn't actually work.The only chip that can actually do this is Via's nano :). And the website wasn't XBit but Ars Technica and the chip was the very Nano :)

According to Agner Fog once again, it is possible to change the VendorID string via AMD's Virtualization instructions. Someone should just write a tool to do it.

Quote:

---

Originally Posted by Calmatory

According to Agner Fog once again, it is possible to change the VendorID string via AMD's Virtualization instructions. Someone should just write a tool to do it.

---

Hmm didn't catch this little tidbit ,thanks :).In any case,Mr Fog will be releasing his survey results with the Nano chip and the FakeID app he created so we'll know how much of tampering with benchmarks there is :).

Quote:

---

Originally Posted by Face

Some more on the Via talk:

http://blogs.barrons.com/techtraderd...d=yahoobarrons

---

i really hope nvidia enters the market, i just cant see them surviving in the market? sure they may be able to make chipsets now, but i dont really see that business thriving as much in the future. with a third player we may really have a race on our hands!

Quote:

---

Originally Posted by MrMojoZ

There are under no obligation to enable it, but if by specific action they disable it then they are artificially limiting the performance of AMD cpus.

---

Well, that's the question isn't it. Does:

If (Intel_CPU) {
If (AVX_extension_detected) {
optimize; }}

specifically DISABLE an AMD optimization? Or is it merely a failure to optimize for AMD, which is acceptable?

I'd suggest to you that the FTC agreement language would suggest the latter interpretation, that it is acceptable, otherwise there would be no need for a warning that "the Intel compiler may not optimize non-Intel parts even for compatible instruction set extensions". You see? If the AMD-Intel agreement prohibited that, then the Intel compiler cannot do it, so the FTC wouldn't be requiring a warning, funds, etc.

Furthermore, the whole idea that Intel's compiler team has to support AMD CPUs, especially for free, is a little odd, no? And as much as one says "compatible instruction set", well what about instruction timing differences, odd corner-case instruction sequence behavior, etc? There are many other compiler choices out there, besides.

why cant they just do,
If (AVX_extension_detected) {
optimize; }

i thought thats whats required now

Quote:

---

Originally Posted by Manicdan

why cant they just do,
If (AVX_extension_detected) {
optimize; }

i thought thats whats required now

---

Because Intel is allergic to fairplay :ROTF:

Quote:

---

Originally Posted by tifosi

Because Intel is allergic to fairplay :ROTF:

---

i think intel likes to keep amd below 30% market share. if they get to small intel will have a monopoly problem. if they get more than 40% they can start to set standards themselves and hopefully have enough backup for the risk. but at their current size it wouldnt take. if amd ever had 50% share for a few years, we would probably have some very interesting battles on which standards should and shouldnt exist, and i bet we the consumers would win in the end

Quote:

---

Originally Posted by Manicdan

i think intel likes to keep amd below 30% market share. if they get to small intel will have a monopoly problem. if they get more than 40% they can start to set standards themselves and hopefully have enough backup for the risk. but at their current size it wouldnt take. if amd ever had 50% share for a few years, we would probably have some very interesting battles on which standards should and shouldnt exist, and i bet we the consumers would win in the end

---

this

Quote:

---

Originally Posted by Manicdan

why cant they just do,
If (AVX_extension_detected) {
optimize; }

i thought thats whats required now

---

As we've been discussing, I don't think that is required by the Intel-AMD agreement.

And again, why should it be? The optimizations will not necessarily be the same for two different micro-architectures sharing an instruction set extension. Who pays for the changes and the QA time required? Intel does it for free?

What if, due to those differences in timing, a race condition in some application is exposed for an AMD CPU, and not for an Intel CPU, and the AMD CPU crashes on that app? Can you IMAGINE the shrieking that would go on? It would all be Intel's fault, of course. Deliberate underhandedness!

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?