Intel finally agrees to pay $15 to Pentium 4 owners over AMD Athlon benchmarking shenanigans

Lär artiklarna och titta på Youtube, uppenbarligen har Intel insett att det är billigare att bara "erkänna" och betala i stället för att spendera mer pengar på att faktiskt förklara vad som hänt här.

Intel har sin egen kompilator, fram till ganska nyligen så har ICC varit betydligt bättre på att använda SSE/AVX än någon annan kompilator. Microsofts MSVC++ kompilator (som följer med Visual Studio) var inte alls lika bra på just SSE runt 2000 och efter att man lanserade .Net så negligerade man sin C++ kompilator rejält fram till någon år sedan då man ansåg att framtiden var C# (idag lägger man massor med resurser bl.a. just på att få MSVC++ att bli bra på att utnyttja SSE/AVX).

Om man som företag säljer en produkt så kan köpare kräva att den fungerar på det sätt man utger den för att fungera. Intel testar bara sin kompilator på sina CPUer, så det är fullt rimligt att deras egen kompilator verifierar att den faktiskt kör på något man testa på innan den använder vissa funktioner. Tänk om man inte gjorde det och i stället för att ge dålig prestanda så kraschade programmet eller orsakade något ännu värre, då hade man definitivt blivit stämda upp till öronen.

Som påpekades i både artikeln och videon så fanns det absolut inget i själva benchmark-programmen som föredrog Intel, däremot valde man säker att kompilera sina binärer med ICC för den kompilatorn helt enkelt gav betydligt bättre prestanda än MSVC++ vid den tidpunkten. ICC var under vissa tider så överlägsen andra kompilatorer att en halvering av prestanda på något där ICC lurat ut hur man använder SSE på ett bra sätt ändå skulle vara ungefär vad MSVC++ skulle prestera, så resultatet blev då att med MSVC++ skulle AMD haft ungefär samma prestanda och P4 skulle ha haft halva. Mer "rättvist"? Tja, de som behövde bra kapacitet för vektor/matris-beräkningar på den tiden lär ju ha använt ICC för den kompilator var bäst.

Idag är det ett icke-problem. Dels jobbar Microsoft hårt på sin MSVC++ kompilator igen, dels har GCC och clang (LLVM front-end för C) blivit så bra att det inte på förhand går att säga om ett givet program blir snabbast med ICC, GCC eller clang. Risken är kanske att Intel blir anklagad för "fusk" igen då de numera har rejält med resurser tilldelade för att se till att GCC är så bra den bara kan på Intels CPUer. Man har skänkt flera saker man initialt köpt in till ICC till GCC projektet.

Man har även fått smakat på sin egen medicin. Geekbench presterar i flera test, främst flyttal, orimligt dåligt på x86 jämfört med ARM. Vissa av dessa saker har rättat i Geekbench 3, men finns fortfarande fall där folk klagat över att flyttalskapaciteten i denna benchmark är betydligt lägre på x86 än vad man får i vissa andra "riktiga" program medan motsvarande problem inte alls finns för ARM. Detta är i praktiken ett icke-problem då riktigt applikationer inte påverkas alls, ICC "problemet" var ju reellt då väldigt många använde den kompilatorn då den helt enkelt var bäst under millennieskiftet.

Och inte för att det borde göra någon skillnad för diskussionen, men var själv "drabbad" då jag körde alla mina datorer på AMD under denna tid. Såg även till att de flesta av maskinerierna på jobbet körde AMD. AMD var helt enkelt bättre än Intel under denna tid. På jobbet körde vi i.o.f.s. Linux (GCC) så var inte drabbad där.

Och om man förstår hur en modern kompilator fungerar så är det absolut inget konstigt. ICC (och även moderna varianter av GCC och LLVM) lägger ut assemblerinstruktionerna olika, man använder till och med olika uppsättningar instruktioner för att lösa samma problem, beroende på om man optimerar generellt eller om man optimerar specifikt för en viss CPU-modell.

Har kommer man tillbaka till att om det inte är en Intel CPU så har ICC ingen aning om hur ALU-konfigurationen ser ut, vad kostnaden för branchmissar är vad tiden från load-to-use är. Hur kan man då använda något annat än den mest generella versionen som naturligtvis är långsammare än vad t.ex. Sandy Bridge optimerad kod är på en CPU-design som ligger nära Sandy Bridge, men den mest generella versionen är antagligen snabbare på Bulldozer än vad Sandy Bridge optimerade versionen är då designen på dessa två skiljer sig radikalt.

Det är Intels egna kompilator, de måste ju få välja exakt vilka CPUer som de optimerar för. Är ju knappast så att Apple optimerar sin version av Clang för någon annan ARM CPU än deras egna, finns flera sådana exempel.

Sedan räcker det absolut inte med att bara veta vilka instruktioner en viss CPU är kapabel till att köra. P4 är ett väldigt bra exempel på detta då det fanns massor med instruktioner man aktivt bör undvika använda för de presterar illa. Samma sak gäller "gamla" Atom som har SSE-stöd men flyttalsdelen är så usel att det rent prestandamässigt är bättre att använda andra metoder om möjligt.

"Gamla" Atom visar också hur viktigt det är att känna till saker som ALU-beroenden och liknande. Optimerar man ordningen på instruktioner och val av generell instruktioner specifikt för denna CPU kan man i många fall få 50% bättre prestanda än kod som är optimerad för Core. Tyvärr så ger Atom-optimerad kod 10-20% sämre prestanda på Core... Numera har Intel lagt till optimering för "aktuella" Intel CPUer i t.ex. GCC, inte fullt lika bra som att specifikt optimera för en specifik modell man man kommer typiskt över 95% av en sådan optimering.

Ursprungliga Athlon gick också att optimera rätt mycket för om man specifikt kompilerade för den CPUn. Har sett så mycket som 25% bättre prestanda med GCC och "-march=i686 -mtune=athlon" mot "-march=i686", det är samma instruktioner som används (de som finns i PPro) men det första fallet använder instruktioner i en frekvens och ordning som är optimal för Athlon.

Bulldozer kan köra AVX instruktioner men det är nästan alltid bättre att använda SSE, framförallt i program som använder alla CPU-trådar.

Så vad är det folk skulle vilja ha sett i ICC? Att den ska försöka genera icke-generell kod till CPU-modeller man aldrig kört ett enda test på? Om det skulle leda till en bug eller sämre prestanda än den generella koden på någon AMD-modell, är man då skyldig att fixa felet?

Och nu jämför man kod som genererats med ICC mot patchad kod som fortfarande är byggd med ICC. Om man i stället kompilerade med t.ex. MSVC++, som stödjer AMD, men ändå får något som är långsammare än ICC med generell optimering är det då verkligen Intel kan ska skylla på?

Hade inte tid att läsa artikeln förrän nu. Min första fråga blir: har du själv läst det du själv länkar till?

Resultatet av att "lura" systemet att man har en Core2 i stället för VIA Isaiah resulterade i de flesta fall i noll skillnad, i några fall blev det långsammare i några andra blev det snabbare. Men det ledde också till att vissa applikationer slutade att fungera! Det sista visar att om du inte testar något kan du inte heller hävda att det fungerar, så Intels defensiva val av optimering och användning av avancerade funktioner för CPU-modeller de inte testat mot ser rätt vettig ut.

Enda riktigt vettiga som stod i den artikeln är detta
"Do not use Intel compiler. The GNU compiler for Linux provides optimization as good as Intel's, although the glibc function library needs to be improved. As for Windows tools, there are no alternatives."

Problemet är att MSVC++ kom så långt efter andra kompilatorer att man som Windows-användare endera fick leva med sämre prestanda på alla CPU-modeller (vilket är det som i praktiken är vanligast då det är väldigt mycket enklare att använda MSVC++ med VS än en 3:e parts kompilator) eller så använder man ICC som även med "generell" optimering ofta spöar MSVC++ men man får även fördelen av ren större boost på Intel CPUer.

I artikeln nämns ju också att Intel specifikt säger att de optimerat ICC för specifika CPU-modeller, inte för specifika instruktioner. Hur ska kunna stödja modeller de inte testat mot?

Det är ju knappast Intels uppgift att förklara att vissa benchmarks använde deras kompilator. Att ICC bara är designad för Intels egna CPU-modeller är och var absolut ingen hemlighet. ICC är en ren förlustaffär som produkt men den var viktig för Intel då det vore rätt meningslöst att lägga in nya finesser i en CPU om ingen använder dessa, ytterst få skriver saker i assembler idag så enda sättet att få saker att användas är att se till att kompilatorn använder finesserna. Intel lägger också en hel del resurser på att skriva bibliotek som drar nytta av nya saker.

Är rätt säker på att förklaringen till att flera benchmark körde med ICC, trots att industrin normalt sett körde (och kör även idag) med MSVC++ på Windows, är att man ville ha något som kunde vissa upp effekten av SSE2 (som kom med P4) och att även för AMD så var "generic" ICC ändå bättre än "optimerad" MSVC++. MSVC++ har varit rätt usel på att använda någon version av SSE fram till rätt nyligen.

Att Intel går med på detta tror jag långt mer beror på att man helt enkelt begriper sig på optimeringslära. Det är billigare att bara acceptera detta än fortsätta plöja ner pengar i advokater och andra rättegångskostnader för att förklara tekniska detaljer för jurister.

I grunden är det ju trivialt: ICC är Intels privata kompilator och man har absolut inga skyldigheter att stödja mer än de modeller man väljer att stödja. Det finns inget fusk i själva källkoden till dessa benchmarks som ger P4 en fördel, i stället så valde företagen bakom dessa benchmark att använda ICC.

ICC är gratis om du ger bort produkten eller om du vill använda den för privata projekt, så det behövs nog inga rabatter. Men är rätt övertygad om att Intel både visste om att deras kompilator användes och det är väldigt troligt att de aktivt pushade för att den skulle användas för att de ville visa effekten av SSE2.

Är däremot benchmarktillverkarens, inte Intels, ansvar att se till att programmet man levererar ger en rättvis bild. Man hade ju rimligen testat på Athlon XP (saknar SSE2) och Athlon 64 (har SSE2), borde då vara uppenbart att SSE2 inte användes om man bygger med ICC (plus att dokumentationen för ICC säger att den bara optimerar för vissa Intel modeller). Men som jag skrivit flera gånger tidigare, rätt hundra på att alternativet att använda MSVC++ för AMD hade resultera i ännu sämre prestanda (sämre än ICC "generic") och den hade överhuvudtaget inte stöd för SSE2 (inte ens på Intel) vid den tidpunkten.

Är det rimligt att man straffas för att man skapar en kompilator som är bättre än vad konkurrenterna har tillgång till? ICC är som produkt en förlustaffär för Intel, den finns enbart för att höja värde på Intels CPU-kretsar genom att väldigt tidigt erbjuda stöd för nya finesser. Sett ur det ljuset är resultatet inte helt missvisade, AMD må ha haft SSE2 men det var betydligt sannolikare att CPUn faktiskt använder SSE2 om den kom från Intel då kompilatorstödet var uselt för SSE2 bortsett från ICC.

Om vi pratar om denna tråd så har Intel aldrig blivit dömda, de har gått med på denna uppgörelse för att undvika rättegång. Ur ett kostnadsperspektiv är vore det ju totalt vansinne att ge sig in i en rättegång med advokater som kostar hundratals dollar per timme om man i stället kan undvika hela klabbet för $15 för de fåtal personer som kommer orka bry sig kräva in summan.

Att de skulle bli dömda i en rättegång kring detta känns totalt befängt, det är ju inte Intel som skapat de benchmark som visade "felaktiga" resultat. Man kan ju knappast straffa något för att ha en kompilator som är mycket bättre än konkurrenterna och man kan inte kräva att Intel ska stödja modeller de inte själva har något intresse av i sin egen produkt.

Om vi pratar om påtryckningar på OEMer tycker jag det var helt rätt att Intel blev dömda, det var att utnyttja sin dominerande ställning och domen var helt korrekt i.m.h.o. Men tråden handlar väll inte om det?

Ser inte hur det kan finnas några konspirationer kring benchmarkproblematiken:

• ICC kollade explicit om det är en Intel CPU, helt rimligt då Intel absolut inte har några skyldigheter att stödja några specifika modeller. Värdet av ICC är enbart att sälja fler Intel-kretsar så pengar man lägger på denna produkt kan man se som PR. Ingen som kräver att AMD gör reklam för Intel CPUer...

• De som tillverkar benchmark har ju själva skyldighet att se till att produkten man levererar är bra, det är benchmark-tillverkarens rykte som ska fläckas om man misslyckas med det.

• Intel har all anledning att försöka pusha ICC till de som tillverkar benchmarks som del av PR för sina produkter. Andra CPU-tillverkare borde rimligen lägga del av sin PR-budget på saker som får deras produkter att framstå i bättre dager.

Den springande punkten här är nog den andra. ICC var helt enkelt så långt före alla andra kompilatorer vid den aktuella tiden att "generic" ICC på AMD var snabbare än "optimerad" med MSVC++, ingen av kompilatorer använde SSE2 på AMD-produkter dock. Men hur kan det vara ett problem? Är ju inte Intels fel att MS kompilatorn inte hade stöd för avancerade finesser, eller? Och ingen kan ju kräva att ICC ska stödja några andra modeller än de Intel explicit väljer att stödja, det är ju deras kompilator!

?

• Intel hade en kompilator som var bättre än konkurrenterna.

• De ville inte att den skulle fungera på icke Intel-CPUer

• Andra samtida kompilatorer kunde (med rimligt arbetsinsats) inte generera SSE2

• Vissa benchmarks använda ICC

Ser överhuvudtaget inte ett problem i detta, gör du? Är inte hela poängen med PR att framhäva sina produkter och ICC existerar i stort sätt bara som PR för nya finesser i Intel-CPUer.

Google är fantastiskt, går ju att hitta release notes (som benchmarktillverkaren rimligen läst, om inte annat för att lura ut hur man slår på SSE2 optimeringar) för ICC 7.1 som var aktuell vid den tiden, första meningen:

"Intel® Compilers help make your software run at top speeds on all Intel® 32-bit processors and 64-bit Itanium® processors. Optimizations include support for Streaming SIMD Extensions 2 (SSE2) in the Intel® Pentium® 4 and Pentium-M processors and software pipelining in the Intel® Itanium® 2 processor."

Man nämner explicit två Intel modeller som det fungerar på. Har man minimal förståelse för programvara så borde man inse direkt att alla icke-triviala program ska anses inte fungera på system man inte testat den på. Är det någon som överhuvudtaget förväntade sig att ICC skulle vara testad på AMDs modeller?

Titta vad som hände när XbitLabs testade patchen som satte om CPUID på en VIA processor till att hävda att den var en Core2, program blev instabila och i vissa fall fungerade de inte alls. Hade det varit bättre om kod kompilerad med ICC varit instabil på AMD?