More Intel dirt cleaned by the FTC

Part 3: Disclosures, burdens of proof, and compilers

THE LAST PART of SemiAccurate’s look at the Intel/FTC settlement examines some of the worst accusations against Intel. Compiler tricks, technical openness, and a watchdog. Intel could be seriously hamstrung by some of these remedies, and worse yet, they could be the ones hamstringing themselves.

Changes, Handcuffs and Burdens of Proof

Section V. is one of the most interesting, it puts some serious handcuffs on Intel. All while forcing them to dig a hole deep enough for light not to reach the bottom. And sit there. Smiling. What V. says is that any time Intel makes a change, basically any change, that degrades the performance of another competitor, Intel has to prove that it was done for technically beneficial reasons.

Remember the part about PCIe changes that allegedly hamstrung Nvidia GPUs? Well, if that happens again, the burden of proof is now on Intel to show why they did it. Mother hen is getting jittery from all that Red Bull, and is looking for someone to hit. Hard. Intel has to climb out of the hole, feed the hen Valium, and then dance. Fast. And look pretty while doing it, or WHAM.

This part could very well do something very unfortunate, make Intel gun-shy. If you recall what happened to IBM, some would say deservedly, when they had their famous consent decree, the same thing just happened to Intel. If the company starts second guessing itself, innovation quickly stops, and products suffer. Intel could very well cut it’s own competitive throat, and that would be a shame.

You won’t find many people from AMD, Via and Nvidia crying over it though. Most of Intel’s competitors and many allies will tell you that this is far too lenient a fate for Chipzilla. Intel probably doesn’t agree, but this is their settlement, and believe it or not, it is better than a protracted legal fight that ends up in the same place. Or worse. Very likely worse actually. If anything kills Intel, this will be it, anything else they can just write a check for. A few billion here and there is not real pain, but a mother hen with a baseball bat is.

Disclosure and Openness

Moving on to part VI., we get into the disclosure agreements, another key point of the settlement. It basically mandates that Intel give it’s competitors roadmaps and technical details about the interfaces to it’s products. There are a few things unsaid, and a few more called out that are rather extraordinary.

In VI. A., it says that Intel must not give out inaccurate or misleading roadmaps. This is singled out, and goes to great length to say that Intel must be honest about these things. Like warning labels on forks that say, “Do not stick in eye”, you have to wonder what prompted such a verbose disclosure. Not that Intel would ever play games about these things, that would be, err, modern business.

Further, Intel has to release four more yearly roadmaps detailing all their interfaces to their competition, NDA’s permitted. In addition, Intel has to answer any questions about the roadmap and interfaces, honestly, and in a timely manner. Intel does not have to provide competitors with samples, updates, or anything else they don’t want to do for lawful business reasons.

One thing stands out in VI. B. 3., the sentence, ….”stating that such Competitor is developing a Relevant GPU that is intended to connect, and would be capable of connecting, to a Mainstream Microprocessor via a Required Interface”. Any guess as to who might have lobbied for this section of the settlement?

Compilers and Dirty Tricks

Part VII is all about compilers, and it lays into Intel for all the things they have been denying but everyone knows they do. It basically makes some Intel products come with a warning label that makes European cigarette packs look tame. Additionally, it creates a fund to allow people duped by Intel’s compiler numbers to recompile their software at Intel’s expense.

Much of this was covered in the AMD settlement, but the solution is simple, Intel can do what they want with their compilers, but they must prominently state that the compiler may not be optimized for any other manufacturer’s CPU. Intel has to tell all it’s compiler customers this, and can not represent or imply that the their compilers are necessarily fair to others. You have to wonder why this would be called out so specifically.

No, actually, you don’t. The backstory, which Intel flatly denies, is that Intel compilers go out of their way to deoptimize code on non-Intel CPUs. They say it was done because Intel can’t test all their competitors products on their compilers, but somehow every other compiler maker out there seems to manage such testing.

The way this was done in the past explicitly violates Intel’s own methodology for determining CPU functionality. Strangely enough, this was only detrimental to code run on other manufacturer’s CPUs. As we said, Intel denies this, but a couple of minutes with a hex editor to change a statement similar to “If Intel CPU, then X” to, “If not Intel CPU, then X” shows startling performance differences. But no crashes. Shock.

Why this is problematic is that Intel would put it’s compilers out there, and get software used in prominent benchmarks to compile with it. Then the ‘fair’ industry consortium benchmark is immediately biased against AMD and Via. Intel plays innocent and looks all pouty when accused. Sadly, a lot of enterprise customers were not aware of this inbuilt bias, and that seems to have been Intel’s intention.

Not only do the compilers need a big warning label now, but the FTC and the settlement call out several benchmarks for being complicit. In Section VII, they make Intel put a warning label that in part calls out SYSmark, MobileMark, and others. It is a pretty stunning disclosure of how Intel gamed the system for years, while hamstringing AMD, Via, Transmeta and others.

“Software and workloads used in performance tests may have been optimized for performance only on Intel microprocessors. Performance tests, such as SYSmark and MobileMark, are measured using specific computer systems, components, software, operations, and functions. Any change to any of those factors may cause the results to vary. You should consult other information and performance tests to assist you in fully evaluation your contemplated purchase, including the performance of that product when combined with other products.” Scary stuff, eh kids?

To make matters worse yet, part VIII. states that Intel has to make a fund that pays compiler customers expenses in recompiling their wares with something else. If you want to to apply for some of the $10 million “Intel Compiler Reimbursement Program”, you too can be paid to redo your code. If you used the Intel compiler in the past.  Some restrictions may apply.  See Intel’s Compiler Reimbursement Program fine print for further details.

It is a shame that Intel has to be tarred and feathered, then paraded through town in stockades like this. Warning labels, paying people to recompile, and explicit orders to be honest? Other than a mound of evidence and simple tests to prove that Intel was far from fair in their protestations, what did they do to deserve this? These ‘unfair’ redresses fix a problem that ‘wasn’t there’, and will level the playing field a lot.

Mother Hens, Baseball Bats, and Watchdogs

The last and probably harshest remedy is in part IX, the mother hen on a caffeine jag. It says that the Commission may appoint one or more technical consultants to look over and monitor Intel, and Intel has to pay for it. The cap is $2 million, so it won’t break the Intel piggy bank. That sum can be burned through in a few hours at ‘enforced consultant rates’, just ask Novell about how SCO’s bankruptcy is going.

As we said at the opening of these stories, Intel now has someone, hopefully independent, watching over them, and they know it. If any of their competitors think something is amiss, there is now a mother hen with a baseball bat and lots of caffeine waiting to apply the learning rod to them. Intel has been accused of a lot of things, but stupidity is not one of them.

With any luck, Intel will clean up it’s act and play fair. Instead of using underhanded and unfair business practices, which they still claim they do not do, they can compete on merit. If they don’t, cluck, cluck, shake, cluck, WHAM. If Intel does buckle down and put all their engineering resources to the task of doing the best job possible, I feel bad for their competition.

If there is one company that has every piece of the semiconductor puzzle in place, the engineering resources to do things no one else can, and hopefully the management will, it is Intel. Engineering disclosure, sales restrictions, disclosures, warning labels, and jittery hens notwithstanding, Intel can win on merit. Hopefully they will actually try and do just that for the next six years, as the alternative is quite unpleasant.S|A

Editor’s note:  This analysis is based upon the proposed FTC settlement document.  There is a 30 day review and comment period after which modifications may be made, rare, and the document finalized and implemented.

The following two tabs change content below.

Charlie Demerjian

Roving engine of chaos and snide remarks at SemiAccurate
Charlie Demerjian is the founder of Stone Arch Networking Services and SemiAccurate.com. SemiAccurate.com is a technology news site; addressing hardware design, software selection, customization, securing and maintenance, with over one million views per month. He is a technologist and analyst specializing in semiconductors, system and network architecture. As head writer of SemiAccurate.com, he regularly advises writers, analysts, and industry executives on technical matters and long lead industry trends. Charlie is also available through Guidepoint and Mosaic. FullyAccurate