AMD tillkännager orsaken till Ryzen-bugg

Intel har rätt många i sin historia, vissa väldigt allvarliga, återkallade CPUer etc..

En processor är så avancerad så skulle du simulera alla tänkbara möjligheter så skulle testningen ta hundratals år, så att buggar slinker igenom är helt oundvikligt - oavsett tillverkare. Däremot kanske de flesta löses så direkt att den stora massan inte vet om det då man helt enkelt inte märker av det.

Hur många buggar enskilda individer på ett forum vet om spelar absolut ingen roll. Det som räknas är det som faktiskt har hänt framförallt då det påverkat en produkt negativt. Om det t.ex. löses genom en mjukvarufix snabbt inpå att det släpps så är det lindrigt, går det inte att fixa utan att ändra designen (och att det påverkar fuktionen) så är det allvarligt.

Det hör inte till vanligheten att företag släpper helt nya designer och det gäller inte bara i CPU branchen, biltillverkare har sina plattformar som de formar metall omkring och kallar det nästa års modell eller en annan modell (ibland med modifikationer).

AMD är galna som släpper sin nya arkitektur på en (relativt) ny processnod och med en helt ny design. Intel undviker det som pesten då det är komplicerat att göra båda delarna samtidigt. Därav deras riktigt bra Tic-Toc strategi. AMD har heller inget val då de är på randen till att inte finnas kvar på marknaden ekonomiskt, "mindshare mässigt" och rent krasst i produkter ute i folks Datorer (räknar inte konsoler).

Om vi vidgar vyerna lite grand - förutom CPUn så kan det vara problem med chipset på moderkortet och andra allvarliga fel med. Säkerhets, funktion eller prestandamässigt. Antar att du t.ex. inte vet om att t.ex. vissa Kaby och Skylake (förmodligen bara bärbara från vissa tillverkare) har allvarliga säkerhetsbrister genom USB? http://hothardware.com/news/intel-skylake-kaby-lake-vulnerabl...

Är väldigt förvånad att det inte har uppdagats någon riktigt Allvarlig brist i Zen än, men det finns gott om tid att hitta det.

Jag är ett fan av teknologi, skiter fullkomligen om det är AMD, Nvidia, Intel eller någon anna som designar/tillverkar grejerna. Ja, jag har haft aktier i AMD. Köpte billigt, sålde nydligen, har inte någon kvar så jag känner mig knappast bunden till något. Ja, jag jobbar med säkerhet och det finns många saker som inte postas offentligt gällande t.ex. incidenten med Kaby/Sky som va nyss.

Detta gäller 128-bit FMA3 operationer. Det står FM3 i nyheten överallt. Påverkar en väldigt liten skara människor. Mer intressant verkar det som att Ryzen kan göra 4st 128-bit FMA3 operationer per cykel när man mätt latens på olika instruktioner.

Har tipsat redaktionen om några positiva nyheter om Ryzen, men inget av dessa dök upp. Ryzen nådde nära 6GHz för ~2 veckor sedan vilket är världsrekord för en 8 kärnig processor (nej Bulldozer räknas inte) samt nytt världsrekord i Cinebench 11.5. Det finns också officiella nyheter att en 3500MT divider är på gång med en ny microcode som kommer i Maj.

Tusentals?

Moderna processorer är oerhört komplexa och proppfulla med hundratals buggar trots intensiv validering. Så länge det inte är allvarliga problem som kräver modifikationer av hårdvaran (som TSX-buggen på Haswell eller FDIV-buggen på Pentium) är det inte direkt något att hetsa upp sig över.

Här är t.ex. en lista på kända buggar i Skylake: http://www.intel.com/content/dam/www/public/us/en/documents/s...

Så det var därför du främjade Skylake som också hade frysbugg i tidigare diskussioner?
Den kommer rättas till och den har hittats, precis som Skylakes bugg.

Med tanke på att det som sagt är en helt ny design från grunden, är den förvånansvärt bra.

@IceDread Skylake hade allvarlig bugg. Haswell hade TSX bugg och USB port problem. Och titta... Sandybridge (chipset) också... precis som pentium. De har haft buggar så långt man kan minnas (och det gäller AMD också).

Så lugn. Det går att fixa...
Enda jag vet som inte fixades var Haswells TSX, som fick stängas av helt istället, vilket är synd.

Helt rätt om FMA3, skickade in en rättelse om det igår men var efter kontorstid...

Däremot kan inte Zen göra 4 st 128-bitars FMA3, den kan göra 2 st 128-bitars FMA3 per cykel och 2 st 256-bitars FMA3 var annan cykel.

Zen har fyra flyttalspipelines, så den är kapabel att göra upp till 2 st multiplikationer och 2 st additioner per cykel endera med 128-bitars SIMD (vektorregister) eller med skalära heltal. FMA3 är implementerat så att rent praktiskt slår ihop två pipelines för att köra en instruktion, en implementation som skiljer sig från de flesta andra där man implementerar FMA inom en enskild pipeline.

Att det finns fel i moderna CPUer är tyvärr rätt väntat, händer i princip alla modeller idag. Om det är något som är en relevant nackdel med x86 (många saker brukar tas upp, i princip alla är i praktiken irrelevanta) så är det just att validering av en modern x86 design är hopplöst komplicerat.

AMD/Intel var nog i praktiken helt chanslösa att hänga med ARM-tillverkarna i mobilspåret, det rörde sig för fort och man var tvungen att ta fram helt nya lösningar. I ett sådant läge blir det en enorm nackdel att jobba med en plattform som tar betydligt lägre att validera jämfört med konkurrenternas design.

Haswell buggen du tänker på måste vara TSX. TSX är precis som t.ex. MPX en utökning som drar nytta av x86 lite "exotiska" sätt att koda sina instruktioner. Jag som utvecklare kan lägga in stöd för TSX i mina program och dessa program kan köras omodifierade även på modeller som inte stödjer TSX! Om en CPU inte stödjer utökningen ser den instruktionen som en NOP (No OPeration), d.v.s. inget händer.

Var därför inget direkt problem att stänga av TSX. En CPU som stödjer detta kan i vissa lägen skala lite bättre över CPU-kärnor, det är skillnaden. Tror inte Windows använder TSX i generella bibliotek, men på Linux använder alla program som är multitrådade i praktiken TSX om det finns stöd, detta då Linux standardbibliotek för trådsynkronisering har fullt TSX stöd.

I Windows går det fortfarande att använda TSX, men krävs än så länge explicit stöd i applikationen.

Har sökt rätt mycket kring exakt vad fixen för AVX gör (buggen triggades INTE när man använde AVX2 eller SSE, var specifikt AVX+HT som krävdes), har inte skrivits ett ord om det. Däremot verkar det som fixen fungerar och ingen har kunnat påvisa någon skillnad i prestanda.

Att gränsen för spel i praktiken går vid högt klockade 4C/8T beror ju främst på att inget idag existerande grafikkort är kraftigt nog att inte bli en rejäl flaskhals. SweClockers Ryzen-test visar ju att spel absolut kan dra nytta av både sex och åtta CPU-kärnor, förutsatt att flaskhalsen är CPUn (vilket blir fallet när man kör alla CPUer i 2,8 GHz). I detta fall är i7-6800K något snabbare än i7-7700K trots att den senare har 10-15 % högre IPC för heltal, vilket är det spel använder.

Så om det dyker upp högt klockade modeller med fler kärnor än fyra kommer dessa vara bättre spel CPUer än dagens CPUer om/när GPU-kraften blir tillräckligt hög.

E-serien är en extrem nischprodukt, Intel borde rimligen ha förstått det redan när den lanserades (i min mening är nischen för E-serien så smal att jag har svårt att se poängen med serien). Största problemet är att S-serien är så pass mycket högre klockad + IPC för heltalberäkningar gick upp 10-20 % med Skylake så en modell som i7-6800K är i praktiken helt värdelös när den ställs mot i7-7700K.

Och går inte att säga att Ryzen 7 generellt springer cirklar kring vare sig E-serien eller S-serien vad det gäller pris prestanda. Jämfört med E-serien är det nästan alltid sant, men finns smala nischer där E-serien är väsentligt mycket snabbare (i princip bara de fall där programmet är ordentligt AVX-optimerat, t.ex. Matlab och Matematica).

Jämfört med S-serien beror det väldigt mycket på vad man gör. Över ett ganska stort antal CPU-bundna tester, exklusive spel, fick TechPowerUp ett resultat som visar att R7 1800X och i7-7700K presterar exakt lika i genomsnitt. Är ju rätt rejäla skillnaden i vissa specifika fall, så vilken som är "bäst" beror ju helt på vad man gör med sin dator

Visa innehåll

Dold text

Tror i.o.f.s. att en rätt stor andel av SweClockers medlemmar har just spel som en av de få krävande saker de använder datorn till. Men resultatet ovan visar att alla som gör något krävande måste förstå exakt på vilket sätt just deras last är krävande för att veta vilken CPU som är bästa val.

TechPowerUp får rätt snarlikt resultat som SweClockers (båda använder GTX 1080). Med ett genomsnitt över 20 st spel får man denna skillnad i 1920x1080 med maxade inställningar

Visa innehåll

Dold text

Finns dock extremfall där skillnaden är ~50 % (till fördel för i7-7700K), finns också ett fall (Civ VI) där Ryzen 1800X är snabbare än i7-7700K.

Laddade hem Himeno Benchmark, är ju en enda C-fil som överhuvudtaget inte innehåller något utöver ANSI C kod

$ wget http://www.phoronix-test-suite.com/benchmark-files/himenobmtx...

Däremot är koden skriven på ett så pass trivialt sätt (nestlade for-loopar där variablerna inte beror av varandra) att GCC faktiskt kan automatgenerera halvdan SSE2/AVX/AVX2/FMA3. Vad man vill ha styrs enbart via flaggor till GCC, resulterande koden använder nästa bara skalära flyttal men även med sådana kan man dra nytta av AVX och FMA3.

Finns överhuvudtaget inga specialoptimeringar för Intel, programmet är inte ens initialt skrivet för att köras på x86. Det skrevs 2001, samma år som första CPUn med SSE2 lanserades.

Och det är min generella invändning kring alla "vänta på Ryzen optimeringarna", vad talar för att det kommer sådana när det i praktiken inte finns några specialoptimeringar för Core utanför extrema specialfall som Intels ICC och Intels MKL?

Lär ju knappast vara så att Ryzen inte kan köra någon FMA3 kod alls, det borde rimligen hittats vid validering. Den FMA3 kod som GCC verkar kapabel att automatiskt generera är uteslutande instruktioner med "ss" suffix (Scalar Single precision) och "sd" (Scalar Double precision). Så borde vara exakt samma instruktioner som körs på Ryzen, Haswell och Skylake då alla stödjer FMA3/AVX2.