Vad jag vet så skall detta vara en moot-point om man kör openBLAS ? efter lite efterforskning så verkar boven mer vara i en specifik algoritm i LAPACK, lite missvisande men hur som helst så verkar det vara mjukvaru-relaterat.
https://www.reddit.com/r/Amd/comments/6vq3zg/ryzen_numpy_and_...
https://community.amd.com/thread/228619
Det som sägs om MKL i den tråden stämmer inte. Så länge man har data som får plats i cache på Zen så finns det inget BLAS som presterar bättre på AMD eller Intels CPUer än MKL.
Problemet uppstår när man börjar trilla ur cache. I det läget har MKL (av skäl som borde vara uppenbar givet att det är Intel som tillverkar MKL) överhuvudtaget inga specialoptimeringar för AMDs-modeller, medan man handoptimerar saker för varje enskild Intel-modell.
Det som nog ställer till det lite extra här är att Intels CPUer brukar nästan alltid gå att pressa ur lite extra ur i fall där man trillar ur cache genom att använda sig av prefetch-hintar. Läser man AMDs optimeringsmanual för Zen står: "Avoid software prefetch".
MKL använder definitivt explicita prefetch anrop för stora matriser! Gissningsvis gör inte OpenBLAS det om man konfiguerar det för Zen, vilket kan förklara varför det biblioteket presterar bättre på stora matriser (men MKL presterar alltså bättre även på Zen för små, väldigt nära teoretisk max).
Kör man med välskrivna bibliotek når man oftast >90 % teoretisk max så länge data kan hålla sig inom cache, det täcker i rätt stor andel av problemen utanför HPC-scenen. Teoretisk max är
8 DP / 16 SP per cykel hos Zen (SSE eller AVX, kvittar, på mitt eget Ryzen-system får jag dock nästan alltid runt 5-10 % bättre prestanda med SSE mot AVX, i Linux kan man utnyttja det genom att patcha kärnan så att AVX-stöd inte annonseras ut)
16 DP / 32 SP per cykel hos Skylake (AVX)
32 DP / 64 SP per cykel hos Skylake-X (AVX-512)
DP=64-bitars flyttal
SP=32-bitars flyttal
(varning för sarkasm med den mängd alkohol detta inlägg skrevs med)
Jag har skapat en otroligt avancerad grafisk representation över varför median blir ett problemn i detta fall:
https://i.imgur.com/hKAB225.png
Detta är skälet till att stor del publikationer använder 1% och 0.1%, detta gör att man ser potentiellt stutter som kan ha större inverkan på upplevelsen än vad bara ett genomsnitt eller median kan framföra.
Och med tanke på att de flesta publikationer som använder 1% och 0.1% istället för normaldistrubition skulle spridningen bli större om man skulle använda median, vilket då skulle var för och nackdel samtidigt för Intel (som i regel har mycket högre highs och något lägre lows).
Så det finns nog inget "rätt" sätt att räkna detta, bara bättre och sämre beroende på situation, och bäst imo är normaldistrubition vilket oftast komprimerar ett helt spektra ner till en enda kolumn/rad i graferna som publikationerna använder.
Nu ska jag dock inte stressa mina resterande 10 hjärnceller något mer och får önska trevlig helg till alla.
Tror du helt missar vad min invändning var då. Invändningen var att GN insinuerade att PT skulle vara inkompetenta även när det kommer till statistik (inte bara i val av CPU-kylare och val av prestandaprofil). Pekade då på att GN säger att deras 0,1 % och 1 % är just 0,1 och 1 percentilen.
Råder inget tvivel kring vad en percentil är och något som 0,1 % och 1 % percentil används specifikt för att påvisa de fall du har i graferna. Så vitt jag vet har inte statistikerna ansett att aritmetiskt genomsnitt av de X högsta/lägsta mätpunkterna skulle ha något generellt användbar statistik relevans.
I 0,1 % fallet kommer man ju se "frame drops" om de händer oftare än en gång per tusen renderade scener, vilket är precis vad man vill få fram.
Tar man i stället medelvärdet räcker det med att en enda scen i hela sekvensen hoppar till, något som kan ske helt slumpmässigt utan att på något sätt vara "typiskt". Det kommer ändå påverka 0,1 % siffran så som GN beskriver att de beräknar den då det kommer vara väldigt få mätvärden i detta medelvärde -> det visar nödvändigtvis vad man vill visa.
Vid 100 FPS i en 2 minuter lång sekvens beräknas 0,1 % "low mean" (eller vad man borde kalla det) är det faktiskt bara 12 mätpunkter.
Visst kan det vara så att "low mean" är vettigt, men i så fall ska man inte kalla det 0,1 % percentilen för det är det inte.
Givet den uppföljande videon från GN (länkad ovan av @tellus82) tycker jag ändå det låter som GN rätt mycket inser att deras kritik mot PT nog varit obefogad i de flesta fall.
Det har inte gått rätt till i detta fall, men är i min mening bara Intel som ska ha skit. PT har på det stora hela gjort ett riktigt bra jobb och är ju inte alls osannolikt att användning av "game mode" även för 2700X just var något Intel beställde.
Så jag har aldrig försvarat Intel i denna soppa. Däremot verkade det ju rätt mycket som alla inkompetensanklagelser mot PT var rätt ogrundade (de anlitas ju även av AMD och en lång rad andra företag, så något måste de ju göra rätt)!
Finns ju en bonus med den här resan: nu har man i alla fall en rapport där samma Zen-modell i 4C/8T samt 8C/16T konfiguration jämförs i en lång rad spel. Ger ju en insikt i hur mycket fler än fyra kärnor kan användas i ett gäng olika speltitlar.
Vad det gäller rapporten som helhet: man har säkert mätt rätt, men det är Intel som valt vilka titlar som ska testas -> de har knappast valt de titlar där i9-9900K presterar relativt sett dåligt...
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer