FTC Announce Settlement With Intel

Quote:

---

The Federal Trade Commission approved a settlement with Intel Corp. that resolves charges the company illegally stifled competition in the market for computer chips. Intel has agreed to provisions that will open the door to renewed competition and prevent Intel from suppressing competition in the future.

The settlement goes beyond the terms applied to Intel in previous actions against the company and will help restore competition that was lost as a result of Intel’s alleged past anticompetitive tactics. At the same time, the settlement will leave the company room to innovate and offer competitive pricing.

---

http://ftc.gov/opa/2010/08/intel.shtm


and here is the link to the agreement,

http://ftc.gov/os/adjpro/d9341/100804inteldo.pdf

a webcast for a settlement announcement? somehow, i doubt the world is holding it's breath....

Quote:

---

Originally Posted by 570091D

a webcast for a settlement announcement? somehow, i doubt the world is holding it's breath....

---

lol maybe it should...ftc just opened the door for nvidia x86!

Quote:

---

Originally Posted by god_43

lol maybe it should...ftc just opened the door for nvidia x86!

---

Maybe I'm missing something, but no where in that settlement do I see the FTC requiring Intel to license x86 to nvidia. The only reference to nvidia I saw was regarding chipsets.

Quote:

---

Originally Posted by rogueagent6

Maybe I'm missing something, but no where in that settlement do I see the FTC requiring Intel to license x86 to nvidia. The only reference to nvidia I saw was regarding chipsets.

---

ah my young friend, you skipped over the part about x86 companies allowed to change control, and their licenses do not become void. they are also allowed to form joint ventures and mergers as well.

intel must create a new license with VIA.....who owns a 16-20% share in VIA (ill give you a hint...it starts with N)? still, i wish the arrangement went further.

Quote:

---

Originally Posted by god_43

ah my young friend, you skipped over the part about x86 companies allowed to change control, and their licenses do not become void. they are also allowed to form joint ventures and mergers as well.

---

Quote:

---

B. In the event the Designated Intel Competitor undergoes a “change of control” (as defined in the relevant Designated Intel Competitor Patent Agreement) that is publicly announced or a Designated Intel Competitor otherwise notifies Respondent that it has undergone a change of control within five (5) days of such change of control:

1. for a period of thirty (30) days from the date of the change of control, Respondent shall not initiate patent litigation against the party acquiring the Designated Intel Competitor (“Acquiring Entity”) with respect to products previously manufactured by or acquired from the Designated Intel Competitor, unless the Designated Intel Competitor and/or the Acquiring Entity or another entity controlled by one of them has first filed any suit against Respondent;

2. within ten (10) days from the date of the change of control, Respondent shall offer to enter into a written, reciprocal Standstill Agreement with the Acquiring Entity, such Standstill Agreement to comprise the following terms:

a. Respondent and the Acquiring Entity shall enter into good faith negotiations regarding the future patent relationship, if any, between them;

b. to facilitate those good faith negotiations, for a period of one year from the change of control, neither Respondent nor the Acquiring Entity (or any Affiliate of either of them) shall initiate patent litigation against the other or any Affiliate thereof;

c. the Standstill Agreement shall not act as a license or provide any patent or other intellectual property rights or defenses to any person or party, either expressly or by implication, estoppel, exhaustion, license, waiver, laches or otherwise; and

d. Respondent shall afford the Acquiring Entity not less than ten (10) days from receipt of Respondent’s written offer to accept in writing the offered Standstill Agreement.

e. For purposes of this Section, “Affiliate” means any entity that is directly or indirectly controlled by, under common control with, or that controls the subject entity.

---

I saw that part, but that is just a Standstill Agreement, it's not forcing Intel to offer the new company a license, only that they have negotiate a new agreement... the negotiations could fail knowing the arrogance of these companies.

That's how I read it at least. :shrug:

Imo, Intel got off easily. This just opens up the door for competition if anything.

Quote:

---

Originally Posted by rogueagent6

I saw that part, but that is just a Standstill Agreement, it's not forcing Intel to offer the new company a license, only that they have negotiate a new agreement... the negotiations could fail knowing the arrogance of these companies.

That's how I read it at least. :shrug:

---

Yeah I see what you mean, good point.

Quote:

---

Originally Posted by god_43

lol maybe it should...ftc just opened the door for nvidia x86!

---

If you thought Intel was having a difficult time developing Larrabee, even with IP from Nvidia, cannot imagine how costly and intensive it'd be for Nvidia to produce a truly competitive x86 cpu despite having access to Via's IP (if the VIA buyout by Nvidia is what's being referred to), which is licensed from Intel.

Trying to do that might just spell the doom of Nvidia.

define competitive,
they can start small with a hybrid chip built for HTPCs where its under 100W and able to do anything. i wouldnt expect them to have something competing in top end or perf/watt battles. but it could easily work for 80% of desktop needs and get them some market share

So there is a 6 year requirement for Intel's cpus/chipset to support the PCI bus. This is the only real thing I see for nv more so then AMD. But I honestly don't think it will take 6 years before we see Fusion and Intel's version (whatever they call it) to hit the street in full force.

Quote:

---

Originally Posted by Manicdan

define competitive,
they can start small with a hybrid chip built for HTPCs where its under 100W and able to do anything. i wouldnt expect them to have something competing in top end or perf/watt battles. but it could easily work for 80% of desktop needs and get them some market share

---

Even if Nvidia bought out VIA, got a licensing agreement signed with Intel, and started really researching a hybrid cpu/gpu, do you think they'd have anything remotely ready to sell within the next 4-5 years? It's not like Nvidia has any experience with cpus, and VIA's are nothing like what's being designed and built today by AMD and Intel.

So, any competitive arena. To try to do so would simply bankrupt Nvidia. Despite their cash reserves, it'd take more than Nvidia can come up with to scratch design a cpu/gpu hybrid chip.....you can just about throw VIA's crap out the window.

Quote:

---

Originally Posted by Humminn55

If you thought Intel was having a difficult time developing Larrabee, even with IP from Nvidia, cannot imagine how costly and intensive it'd be for Nvidia to produce a truly competitive x86 cpu despite having access to Via's IP (if the VIA buyout by Nvidia is what's being referred to), which is licensed from Intel.

Trying to do that might just spell the doom of Nvidia.

---

yes i am referring to a nvidia/via merger, i am fully aware of how much the whole thing might cost them. 4-5bln to buy via, and another 4-5bln to develop something. you are assuming that nvidia has no experience with cpus. they hired transmeta employees a few years back, they have good engineers, they have a lot of experience with chipsets. they probably wont be able to compete in the high end for at least 4-5 years, but they can compete just fine in the mainstream market.

Quote:

---

Originally Posted by rogueagent6

I saw that part, but that is just a Standstill Agreement, it's not forcing Intel to offer the new company a license, only that they have negotiate a new agreement... the negotiations could fail knowing the arrogance of these companies.

That's how I read it at least. :shrug:

---

yes if they were taken over; i.e hostile take over is usually what a standstill agreement refers to. i believe a merger would not warrant this? but either way, via is now able to use gpus from other vendors.

Quote:

---

Respondent shall, within thirty (30) days after the date this Order becomes final,
offer to Via to sign written amendments to the Via Patent Agreements to:

1. extend the “Capture Period” in Sections 1.4 of the Litigation Settlement
Agreement between Via Technologies, Inc. and Intel Corporation dated
April 7, 2003, 1.3 of the Via Patent Cross License Addendum of the same
date, and 1.1 of the Via Microprocessor Addendum of the same date, to
provide that the Capture Periods end on the fifteenth yearly anniversary of
the Effective Date of those agreements;

2. confirm that under the Via Patent Agreements, Via is permitted to make,
use, sell or import Via Microprocessors that are compatible with the x86
instruction set but not pin compatible or bus compatible with Intel
Microprocessors, including such Via Microprocessors with graphics
technology designed by and supplied to Via by a third party, so long as
Via does not exceed the scope of the licenses expressly granted under or
otherwise breach the terms of those Agreements; and

3. provide that Respondent shall, upon the request of Via, publicly state that
Via is permitted to make, use, sell or import Via microprocessors that are
compatible with the x86 instruction set but not pin compatible or bus
compatible with Intel microprocessors, including such Via
microprocessors with graphics technology designed by and supplied to
Via by a third party, so long as Via does not exceed the scope of the
licenses expressly granted under or otherwise breach the terms of those
Agreements.

---

Quote:

---

Originally Posted by Russian

Imo, Intel got off easily. This just opens up the door for competition if anything.

---

i agree, and i do not believe this goes far enough to even foster competition; much more so than already.

Quote:

---

Originally Posted by god_43

yes if they were taken over; i.e hostile take over is usually what a standstill agreement refers to. i believe a merger would not warrant this? but either way, via is now able to use gpus from other vendors.

---

I think in that case, the standstill would only protect via from the party looking to take them over, i.e. hostile takeover by nvidia.

I think the FTC is referring to this:

Quote:

---

Another type of standstill agreement is an agreement whereby two or more parties agree not to deal with other parties in a particular matter for a period of time. For example, in negotiations for a merger or acquisition, the target and the purchaser may enter into an agreement where they each agree not to solicit or embark on acquisitions from or of other parties. This allows the parties to invest more heavily into the negotiation, due diligence, and details of a potential acquisition.

---

Standstill Agreement

Yeah, it's wiki, but it seems to fit what the FTC is talking about.

Intel got away EASY on this one. REALLY EASY.


I don't forsee much competition coming from this simply b/c it costs so much in R&D to develop a good x86 CPU. After NVIDIA's recent market share price crash (look over the last 2 years), they no longer have the funds to really push development on x86 AND GPUs. They have to pick one, if you ask me.

Quote:

---

Originally Posted by rogueagent6

I think in that case, the standstill would only protect via from the party looking to take them over, i.e. hostile takeover by nvidia.

I think the FTC is referring to this:



Standstill Agreement

Yeah, it's wiki, but it seems to fit what the FTC is talking about.

---

hmm i think you are right.....wow wtf, ftc couldn't even make it easy for nvidia to obtain a license...this settlement is a bunch of fail! damn i had high hopes, that the market would finally be corrected....ftc chairmen are probably sporting new expensive cars at intels expense...

Quote:

---

Originally Posted by god_43

hmm i think you are right.....wow wtf, ftc couldn't even make it easy for nvidia to obtain a license...this settlement is a bunch of fail! damn i had high hopes, that the market would finally be corrected....ftc chairmen are probably sporting new expensive cars at intels expense...

---

There is a flip side to that though, if someone were to buy out via, and intel didn't extend the x86 license to the purchasing party for any reason, it would look bad for them. They may have the cash, but I think they are walking on eggshells at the moment and know it. This is all speculation, but it will be interesting to see how it plays out. I'm with you though, I'd like to see nvidia buy out the rest of via and start producing an x86 chip, if only to force AMD and Intel to continue to innovate.

Quote:

---

Originally Posted by rogueagent6

There is a flip side to that though, if someone were to buy out via, and intel didn't extend the x86 license to the purchasing party for any reason, it would look bad for them. They may have the cash, but I think they are walking on eggshells at the moment and know it. This is all speculation, but it will be interesting to see how it plays out. I'm with you though, I'd like to see nvidia buy out the rest of via and start producing an x86 chip, if only to force AMD and Intel to continue to innovate.

---

honestly...i know we make fun of the guy but; i think nvidia ceo is the only one with balls right now because nvidia is not going to settle (at least that's what they say now). nvidia is going head first to court with Intel.

GRAAAH HUANG SMASH! EAT INTEL FOR BREAKFAST! lol i didn't know he had a tattoo....


http://i2.cdn.turner.com/money/2010/..._huang.top.jpg

He looks both worried and constipated at the same time...

Some more on the Via talk:

Quote:

---

Intel: Will FTC Deal Trigger Acquisition Of Taiwan-Based Via?

One of the basic facts of the PC microprocessor market is that there simply isn’t much real competition; there’s Intel (INTC), Advanced Micro Devices (AMD), and not much else. Often overlook in the discussion is a small Taiwan-based chip company with a license to make x86 chips called Via Technologies. But Via could turn out to be a more important player in the wake of Intel’s settlement with the Federal Trade Commission this week of antitrust charges.

Bernstein Research analyst Stacey Rasgon notes in a research report that the FTC in its analysis of the proposed consent order in the case has “explicitly called out that they are leaving the door open for a new competitor to enter the x86 space, if one were to genuinely desire to do , through an acquisition of Via.” The FTC states that the modification of the change-of-control provisions of Intel’s license with Via, as required by the proposed agreement, “opens the door to a potential joint venture or acquisition of Via and its x86 license by a strong and well-financed entrant to the x86 market.”

Via would be a way to jump stat any potential new Intel rival; the company has a market cap of just $850 million. Of course, as Rasgon points out, to truly be competitive with Intel “would require significant innovation and investment beyond simply possessing a license.”

---

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

Quote:

---

Originally Posted by Face

Some more on the Via talk:

Quote:

---

the FTC in its analysis of the proposed consent order in the case has “explicitly called out that they are leaving the door open for a new competitor to enter the x86 space, if one were to genuinely desire to do , through an acquisition of Via.”

---

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

---

So it was their intent to leave that door open, it's going to be interesting to see how it all plays out.

Agner Fog's take on the settlement:

Quote:

---

Originally Posted by Agner Fog

Out of court settlement with FTC
Yesterday, the Federal Trade Commission (FTC) announced that they are going for an out of court settlement with Intel. See their press release and proposed decision.

I will comment only on the part of the settlement that deals with Intel's compilers and function libraries. The FTC orders that Intel must inform its software customers about the CPU dispatch mechanism that leads to suboptimal performance on non-Intel CPUs. It also recognizes that certain published benchmarks were misleading. The advantage of an out-of-court settlement is that it is faster. A court battle could take so long time that the issues were obsolete before a decision was made. In a comment, the FTC explains that the purpose of the order is not punitive but remedial.

The settlement with FTC is less far-reaching than the settlement with AMD. The AMD settlement requires that Intel remove any "Artificial Performance Impairment", while the FTC settlement requires only that Intel inform their customers of what they do. This will not solve the problem, only make it more visible. The wording of the settlement is also somewhat ambiguous as to which clauses apply to both the compiler and the function libraries, and which clauses apply to the compiler only. This is unfortunate since many software developers are using the Intel function libraries without using the Intel compiler.

The FTC have asked me to testify in court about the CPU dispatching in Intel's compilers and function libraries. I will not have to do this now, of course, but I will continue to publish my findings here on my blog. I am currently doing a survey of software that is affected by the biased CPU dispatching and I am going to publish the results here soon.

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?

After all, the FTC settlement leaves the software community with more problems than we could expect after the AMD settlement. Maybe this reflects the limited power of the FTC?
Reply To This Message

---

In his previous blog post he writes about the fact that intel's Math Kernel Library (v. 10.3) has the CPU dispatch bias(still uses an inferior code path for non-Intel processors).He is doing a survey at the moment,using an application for changing CPUID that he developed for Via's x86 Nano chip(that has this capablity).He said he will publish the results of the survey soon.

Quote:

---

Originally Posted by Agner Fog

New version is still crippling Intel's competitors
Author: Agner Fog Date: 2010-06-29 04:16
Intel have released a new version of their Math Kernel Library (v. 10.3) in beta test.

I have tested the new libraries and found that the CPU dispatching works basically the same way as before. The standard math library, vector math library, short vector math library and the 64-bit version of other math kernel library functions still use an inferior code path for non-Intel processors.

I have found the following differences from previous versions:

* Many functions now have a branch for the forthcoming AVX instruction set, but still only for Intel processors. This will increase the difference in performance between Intel and AMD processors on these functions. Both Intel and AMD are planning to support AVX in 2011.

* The CPU dispatcher for the vector math library has a new branch for non-Intel processors with SSE2. Unlike the generic branch, the new non-Intel SSE2 branch is used only on non-Intel processors, and it is inferior in many cases to the branch used by Intel processors with the same instruction set. The non-Intel SSE2 branch is implemented in the 32-bit Windows version and the 32-bit Linux version, but not in the 64-bit versions of the library.

* A new Summary Statistics library uses the same CPU dispatcher as the vector math library.

Obviously, I haven't tested all functions in the library. There may be more differences that I haven't discovered. But it is clear that many functions in the new version of the library still cripples performance on non-Intel processors. I don't understand how they can do this without violating the legal settlement with AMD.

---

so the settlement with AMD should force intel to remove the inferior code for non intel cpus, so why would the FTC have them do anything different? does one settlement override the other?

Nope,it's just that FTC doesn't have the power that court has(or the contract AMD and intel made in their settlement).However,if intel does the dirty stuff again, FTC can pursue the thing to court as they wanted this time too. And if AMD wishes to,they can use the biased CPU dispatching in latest intel software as a poof of settlement breach and go to court again.

Quote:

---

Originally Posted by Manicdan

so the settlement with AMD should force intel to remove the inferior code for non intel cpus

---

No.

That settlement basically says Intel cannot do:

If (AMD_processor) waste_time;

But it is free to do:

If (Intel_processor & special_instruction_set) go_faster;

And it is under no obligation to spend its own time or money implementing and then ensuring that

If (AMD_processor & special_instruction_set) go_faster;

would actually work in all cases, never have a bug, etc.

http://download.intel.com/pressroom/..._agreement.pdf

See section 2.3.

---------

And the FTC agreement basically says this behavior is fine, as long as you agree to notify compiler customers that you take no responsibility for optimizing for AMD products even on compatible instruction sets.

In other words, if you don't like it, AMD, Agner, etc., go spend your own time & money developing, testing, and marketing your OWN compiler for any & all x86 processors.

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?

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.