AMD Ryzen Blender benchmark-tråden

Rätt säker jag hittat orsaken till Windows/Linux Blender soppan. Och håller i så fall med dig, skrota denna tråd och börja på en ny med rätt Blender fil och om nedan är sant får vi skrota alla Linux-resultat.

Kikar man lite på mailing-listorna för Blender så nämns att vissa ser högre resultat med Linux. De förklaringar som ges är uppenbart felaktiga, t.ex. säger vissa att Linux hanterar fler CPU-kärnor bättre vilken i vissa lägen är sant men i detta fall är det helt irrelevant då Blender är trivialt att köra på många CPU-trådar vilket gör att OS-inblandning är minimal. (En sak som ändå är cool i Linux är att de generella mutex/semaphore implementationerna använder TSX om det finns, ger en viss boost i applikationer som använder flera trådar men inte är triviala att skala, Windows gör tyvärr inte detta ännu).

Testade som sagt att köra på den laptop jag normalt jobbar på, den har endast Windows 10 installerat så när jag testade Linux tog jag bara en random "live-image" och bootade. Visade sig att frekvensskalningen inte fungerar som den ska med den Linux-image jag laddade ner, dator körs alltid på sin basfrekvens 2,2 GHz vilket bara råkade vara ungefär 30 % lägre än den frekvens jag får i Windows.

Hade redan Linux installerat, virtualiserat via VmWare under Windows 10. Ville inte köra en benchmark virtualiserad, men när jag testade så blev prestanda ~30 % högre i min virtualiserade Ubuntu Server än direkt under Win10. Att jag fått ungefär samma resultat tidigare just på denna laptop vara alltså bara en oturlig tillfällighet, kör man Linux på basfrekvens får man med några sekunders marginal samma resultat som under Windows 10... Titta aldrig riktigt på frekvenserna då jag inte tänkte köra några Blender resultat från en laptop (är inte säker på att den inte throttlar ibland, fläktarna vrålar rejält om man kör Blender).

Konstaterade däremot att både Windows och virtualiserad Linux körde på ~2,7 GHz när Blender var aktiv. Vilket inte är förvånande då det är Windows som styr frekvensskalningen i båda fallen här, virtualiserad Linux är ju egentligen bara en applikation under Windows.

Testade också några andra program som lastade alla CPU-trådar, precis som jag haft för mig så var 2,7 GHz väl lågt då andra program nådde 2,9 GHz... Varför denna skillnad?

Slog mig att jag läst något om att Haswell och senare (datorn har i7-4702MQ, så quad-core Haswell för bärbara) har en lägre "turbo-boost" när AVX/AVX2 används.

"Intel AVX instructions require more power to run. when executing these instructions, the processor may run at less than the marked frequency to maintain thermal design power (TDP) limits"

Agner Fog skriver också

"I observed an interesting phenomenon when executing 256-bit vector instructions on the Skylake. There is a warm-up period of approximately 14 µs before it can execute 256-bit vector instructions at full speed. Apparently, the upper 128-bit half of the execution units and data buses is turned off in order to save power when it is not used. As soon as the processor sees a 256-bit instruction it starts to power up the upper half. It can still execute 256-bit instructions during the warm-up period, but it does so by using the lower 128-bit units twice for every 256-bit vector. The result is that the throughput for 256-bit vectors is 4-5 times slower during this warm-up period. If you know in advance that you will need to use 256-bit instructions soon, then you can start the warm-up process by placing a dummy 256-bit instruction at a strategic place in the code. My measurements showed that the upper half of the units is shut down again after 675 µs of inactivity."

D.v.s. om det körs minst en AVX-instruktion inom 675 µs så ser man kanske lägre frekvens då mer kisel är aktiverad...

Men hade ju redan sökt på huruvida Blender hade AVX-optimeringar och det sades att så inte var fallet.

För att vara helt säker git-clonande jag Blender och byggde det. Föga oväntat visade sig att Blender beror på en lång rad andra bibliotek, vad skulle man göra utan "apt-get build-dep blender" i Debian-baserade distos... Sökte efter assembler eller compiler instricts för AVX, men fanns inget.

Hade också kollat att alla aritmetiska instruktioner för flyttal var av typen somethingss, d.v.s. scalar single precision. Vilket är fallet i Windows (kollade detta på Windows då min laptop kör detta och 'awk' fungerar lysande i Cygwin, numera även via Linux-under-Window10 maskineriet) och det stämmer helt med källkoden.

Hade däremot inte explicit sökt efter något vad som helst som använder en AVX-instruktion (inte helt lätt att göra det). Men för att utreda detta tänkte jag att varför inte bara kolla om man någonstans använder ett AVX-register. Till min förvåning använder Windows-version AVX till vad som ser ut som någon form av minneskopiering.

Det är heltkorkat på Intel CPUer då det är förenat med en kostnad att aktivera AVX + att både Windows och Linux ABI:er kräver att man ställer tillbaka tillståndet till SSE innan man returnerar från en funktion. D.v.s. AVX ska bara användas när det finns en hel del data att jobba med!

Detta är var Agner Fog har noterat

"While Intel processors have a large penalty for mixing 256-bit AVX instructions with non-AVX XMM instructions due to a mode switch (see page 131), there is no such penalty and apparently no mode switch on these AMD processors"

Varför skriver jag "Windows-versionen av Blender" ovan? Jo, till min förvåning visade sig att Linux-versionen av Blender binären innehöll en hel del vektoriserade AVX instruktioner, så vad kommer dessa ifrån. Hade det varit bibliotek borde de väl ändå ligga i en .so/.dll?

Men vi har med C++ att göra, väldigt vanligt att kod då ligger i headerfilerna!!! Och så är fallet här, orsaken att dessa optimeringar inte finns i Windows är för att de explicit kollar om man använder GCC. Windows-versionen som är förbyggd är byggd med MSVC++, inte gcc!!!

Hittade t.ex. denna sektion i Linux-versionen, detta är handoptimerad vektoriserad AVX

 3369197:       c4 c1 3d 14 d9          vunpcklpd ymm3,ymm8,ymm9
 336919c:       c4 c1 3d 15 f9          vunpckhpd ymm7,ymm8,ymm9
 33691a1:       c5 64 14 c7             vunpcklps ymm8,ymm3,ymm7
 33691a5:       c5 64 15 cf             vunpckhps ymm9,ymm3,ymm7
 33691a9:       c4 c1 3d 14 d9          vunpcklpd ymm3,ymm8,ymm9
 33691ae:       c4 c1 3d 15 f9          vunpckhpd ymm7,ymm8,ymm9
 33691b3:       c4 62 7d 1a 00          vbroadcastf128 ymm8,XMMWORD PTR [rax]
 33691b8:       c4 62 7d 1a 48 10       vbroadcastf128 ymm9,XMMWORD PTR [rax+0x10]
 33691be:       c4 62 7d 1a 50 20       vbroadcastf128 ymm10,XMMWORD PTR [rax+0x20]
 33691c4:       c4 62 7d 1a 58 30       vbroadcastf128 ymm11,XMMWORD PTR [rax+0x30]
 33691ca:       c4 63 7d 04 e0 00       vpermilps ymm12,ymm0,0x0
 33691d0:       c4 63 7d 04 e8 55       vpermilps ymm13,ymm0,0x55
 33691d6:       c4 63 7d 04 f0 aa       vpermilps ymm14,ymm0,0xaa
 33691dc:       c4 63 7d 04 f8 ff       vpermilps ymm15,ymm0,0xff
 33691e2:       c4 41 3c 59 e4          vmulps ymm12,ymm8,ymm12
 33691e7:       c4 41 34 59 ed          vmulps ymm13,ymm9,ymm13
 33691ec:       c4 41 2c 59 f6          vmulps ymm14,ymm10,ymm14
 33691f1:       c4 41 24 59 ff          vmulps ymm15,ymm11,ymm15
 33691f6:       c4 41 1c 58 e5          vaddps ymm12,ymm12,ymm13
 33691fb:       c4 41 0c 58 f7          vaddps ymm14,ymm14,ymm15
 3369200:       c4 c1 1c 58 c6          vaddps ymm0,ymm12,ymm14
 3369205:       c4 63 7d 04 e1 00       vpermilps ymm12,ymm1,0x0
 336920b:       c4 63 7d 04 e9 55       vpermilps ymm13,ymm1,0x55
 3369211:       c4 63 7d 04 f1 aa       vpermilps ymm14,ymm1,0xaa
 3369217:       c4 63 7d 04 f9 ff       vpermilps ymm15,ymm1,0xff
 336921d:       c4 41 3c 59 e4          vmulps ymm12,ymm8,ymm12
 3369222:       c4 41 34 59 ed          vmulps ymm13,ymm9,ymm13
 3369227:       c4 41 2c 59 f6          vmulps ymm14,ymm10,ymm14
 336922c:       c4 41 24 59 ff          vmulps ymm15,ymm11,ymm15
 3369231:       c4 41 1c 58 e5          vaddps ymm12,ymm12,ymm13
 3369236:       c4 41 0c 58 f7          vaddps ymm14,ymm14,ymm15
 336923b:       c4 c1 1c 58 ce          vaddps ymm1,ymm12,ymm14
 3369240:       c4 63 7d 04 e2 00       vpermilps ymm12,ymm2,0x0
 3369246:       c4 63 7d 04 ea 55       vpermilps ymm13,ymm2,0x55
 336924c:       c4 63 7d 04 f2 aa       vpermilps ymm14,ymm2,0xaa
 3369252:       c4 63 7d 04 fa ff       vpermilps ymm15,ymm2,0xff
 3369258:       c4 41 3c 59 e4          vmulps ymm12,ymm8,ymm12
 336925d:       c4 41 34 59 ed          vmulps ymm13,ymm9,ymm13
 3369262:       c4 41 2c 59 f6          vmulps ymm14,ymm10,ymm14
 3369267:       c4 41 24 59 ff          vmulps ymm15,ymm11,ymm15
 336926c:       c4 41 1c 58 e5          vaddps ymm12,ymm12,ymm13
 3369271:       c4 41 0c 58 f7          vaddps ymm14,ymm14,ymm15
 3369276:       c4 c1 1c 58 d6          vaddps ymm2,ymm12,ymm14
 336927b:       c4 63 7d 04 e3 00       vpermilps ymm12,ymm3,0x0
 3369281:       c4 63 7d 04 eb 55       vpermilps ymm13,ymm3,0x55
 3369287:       c4 63 7d 04 f3 aa       vpermilps ymm14,ymm3,0xaa
 336928d:       c4 63 7d 04 fb ff       vpermilps ymm15,ymm3,0xff
 3369293:       c4 41 3c 59 e4          vmulps ymm12,ymm8,ymm12
 3369298:       c4 41 34 59 ed          vmulps ymm13,ymm9,ymm13
 336929d:       c4 41 2c 59 f6          vmulps ymm14,ymm10,ymm14

För de som överhuvudtaget känner till något om assembler syns direkt att detta är handoptimerad kod med långa sektioner helt utan hopp, d.v.s. här presterar en CPU väldigt nära sin teoretiska kapacitet. Och suffixet är ps (inte ss) d.v.s. "packed single precision", varje instruktion utför åtta 32-bitars flyttalsoperationer parallellt.

Ovanpå det visade sig också att Blender säger åt GCC att autovektorisera om möjligt, AVX/AVX2 är tillåtet! Finns ett par ställen där GCC lyckas använda AVX bara genom att bygga Blender (som är "vanlig" C++). Svårt att tro det ger mer än några procent extra, men ändå något Windows saknar.

Vet inte om det kostar något att köra Linux virtualiserat, men för mig är ändå blender under en virtualiserad Linux 30 % snabbare än Windows 10 på i7-4702MQ. Linux-versionen använder AVX på ett konstruktivt sätt, Windows använder det knappt alls och i bästa fall påverkar det inte heller prestanda negativt! Då jag fick ungefär samma prestanda med en "native" Linux där frekvensskalning var paj och där frekvensen var ungefär 30 % lägre än den borde så verkar overhead för virtualisering vara väldigt nära noll i detta fall (vilket ändå känns rimligt då blender knappt aktiverar OS-funktioner).

Skulle säga att det vore betydligt trevligare om vi fått Zen / Broadwell-E jämförelsen på Linux-maskiner i stället, Intel har en fördel i AVX och just i detta fall verkar det som att man får en ~30 % boost! Är övertygad om att Zen också är snabbare under Linux, men går inte säga hur stor boost man ser där.

Kan tyvärr inte bidra med några värden till en ny tråd då mina "roliga" maskiner endera inte är här (speldator med 5775C är i sommarstugan). De andra kör Linux och har ingen Windows-licens till dem. Kan bidra med laptops körandes Haswell, Broadwell och Skylake (fast Skylake är Core M...)

Men i detta läge borde man nog skapa en ny tråd, förvirringen i denna borde nu vara rätt stor...

Alla dessa resultat är tagna från samma dator, en Dell XPS15 med i7-4702MQ. Är 150 samples rakt igenom.

64-bitars Window 10 / 64-bitars Blender
Rapporterad CPU-frekvens under körning är 2,69 GHz

64-bitars Window 10 / 32-bitars Blender
Rapporterad CPU-frekvens under körning är 2,75 GHz

Virtualiserad 64-bitars Ubuntu Server 16.04 / 64-bitars Blender
Rapporterad CPU-frekvens under körning är 2,69 GHz
Tid: 1:12.96

Virtualiserad 64-bitars Ubuntu Server 16.04 / 32-bitars Blender
Rapporterad CPU-frekvens under körning är 2,82 GHz
Tid: 2:02.02

Versionen av Blender påverkar alltså rätt mycket, något som verkar bero på att flera bibliotek har handoptimerade algoritmer som bara tas med när man bygger med en viss kompilator, OS och 32/64-bitar.

Intressant att 32-bitars versionen presterar något bättre än 64-bitars versionen i Windows, men 32-bitars versionen i Linux är långt efter. En snabb flukt i koden pekar på att 32-bitars Linux använder främst x87 instruktioner medan Windows kör med skalära SSE både i 32-bitars och 64-bitars versionen.

Vidare verkar 32-bitars versionen på Windows inte ha AVX-instruktionerna som 64-bitars versionen har, det förklarar möjligen skillnaden i frekvens och därmed skillnaden i prestanda.

För de som faktiskt vill köra Blender till något vettig: se till att använda 64-bitars versionen för Linux. Kör ni Windows, installera Linux via Vmware, VirtualBox eller Hyper-V då det är en relevant prestandaboost.