Intel anklagas för missvisande jämförelse mellan Core i9-9900K och AMD Ryzen

Permalänk
Datavetare
Skrivet av Fjesa:

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

Skrivet av wowsers:

(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...

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem

@Yoshman:

Tack för att du tar dig tiden att svara utformligt, jag upskattar verkligen all information om detta då jag själv blivit rekommenderad TR för DL / ML projekt, där de flesta trådar jag läst endast nämner kärnor per gpu, antalet PCIE lanes osv, inget om performance för bla SSE eller kringliggande bibliotek. Det ska väl även nämnas att detta är i system för minimum budget, inte high performance.

Personligen så tror jag inte att det kommer att vara ett allt för stort problem i mitt fall.

känns lite fult med hela genuine intel code paths i MKL men jag förstår även att Intel inte är Non-Profit..

om du har några tips på vart man kan hitta mer information om ämnet, skicka gärna en pm.

https://blog.inten.to/hardware-for-deep-learning-current-stat...
https://www.sisoftware.co.uk/2017/09/11/numa-performance-impr...

Permalänk
Medlem
Skrivet av Yoshman:

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

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...

Försökte inte få det att låta som att jag hade invändningar till PT i det inlägget, bara påpeka varför ett blankt medel/medianvärde mestadels inte är intressant ryckt ur luften (och hur det kan medvetet används/blivit beställt), och samma gäller också medel (men detta används nog av historiska skäl).

Visa signatur

"Oh glorious cheeseburger… we bow to thee. The secrets of the universe are between the buns..."
"All my farts come straight from hell, you're already dead if you notice a smell"

Permalänk
Medlem

Det absolut bästa man kan använda i mitt tycke är en frametimegraf, då ser man direkt hur saker faktiskt kommer upplevas men då det kan vara lite abstrakt för läsare/betraktare så används det sällan av testare och ska man jämföra massvis av hårdvara blir det knepigt med fler datakurvor samtidigt, fanns någon sajt där man kunde välja hårdvara som skulle visas och man kunde som mest ha 3 frametime kurvor samtidigt, kommer dock inte ihåg var...

Skickades från m.sweclockers.com

Visa signatur

| nVidia RTX3090FE | R9 5950x | MSI x570 Unify | Ballistix sport 3000c15 32GB DR@3800c16 | Custom Loop EKWB | 9TB nvme, 3TB sata SSD | RM1000x | Creative X4 | Lian Li o11 Dynamic | Alienware aw3821dw | >Zen2 på 3-400 mobo< | >x570 VRM< | :::AMD Zen Minnesguide:::|:::AMD Zen & Zen+ Överklockningsguide:::

Permalänk
Medlem
Skrivet av wowsers:

Jag har skapat en otroligt avancerad grafisk representation över varför median blir ett problem i detta fall:
https://i.imgur.com/hKAB225.png

Detta är skälet till att stor del publikationer använder 1% och 0.1%, ...

1. Ingen publikation som jag känner till (inklusive SC) använder primärt 1%-värdet för att ranka grafikkort vid jämförelser, även om värdet presenteras. Rankningen baseras på medelvärdet.

2. De presenterade värdena är i princip alltid medelvärdet för flera körningar.

3. Du har missförstått PTs användning av medianvärdet.
Mätvärdena är medelvärdet för respektive test (tre för varje spel), och sedan har de tagit det mittersta resultatet.

Jämförelse:
Mätvärden
Första körningen: 50,00 fps medel
Andra körningen: 90,00 fps medel
Tredje körningen: 100,00 fps medel

Medelvärde totalt: 240/3 fps = 80,00 fps.
Medianvärde: 90,00 fps.
Analys:
Första körningen avvek markant från de övriga. Hur mycket ska den inverka på det presenterade testresultatet?
Den drar ner medelvärdet, men påverkar inte medianvärdet. Medianvärdet ger en representativ bild av vad man kan förvänta sig utan att påverkas av några extremvärden.
För att en medelvärdesbildning ska vara lika representativ måste man först ta bort extremvärdena.
Variationerna mellan körningarna är så stora att två värdesiffror är mer än nog. (PTs presentation med upp till två decimaler är idiotisk.)

Permalänk
Medlem
Skrivet av gabriel15:

@GuessWho:

Logiken när man sätter in ett grafikkort som konsumerar mindre effekt och lyckas få hela riggen att dra mer ström.....

Låter som ett specialfall. Men inte omöjligt.

När SweClockers testade Intel Core i9-7980XE
Effektmätning utan överklockning
Effektmätning vid överklockning

Tittar man på strömsnålaste systemet i tabellen utan överklockning så har du Pentium G3258 vid 65W under belastning i blender medan en standardklockad i9-7980XE drar 260W under blender.

Överklockad i9-7980XE drar 150W i idle och 580W i blender i det testet.

Alla systemen är testade med ett GeForce GTX 1080 i datorn.

Det är rätt tydligt att det är mer än bara grafikkortet som påverkar ett systems totala förbrukning!

Hittar man ett system där systemet, förutom grafikkortet, är strömhungrigt och sen testar grafikkort med stor skillnad i prestanda per watt så kan det gå att hitta sådana scenarion.

Vi kan mäta allt möjligt.
Hur många liter en bil drar per mil.
Hur många morötter som äts per månad i ett genomsnittligt hushåll.
En banans böjning.
Massa andra saker...

Ska vi prata logik så är det mest logiska att man mäter det man är intresserad av att veta.