Skrivet av Xeonist:
Nej, lackmustestet ligger i om det finns minst 1 applikation som kan hantera OSet väl. Om så är fallet ligger svagheten hos dom andra applikationerna!!
Du missar helt poängen.
Tar man en applikation som är funktionellt identisk på alla OS och endast använder grundläggande OS-tjänster som i sig inte ger något orättvis fördel för ett specifikt OS, så måste alla skillnader i t.ex. skalbarhet med CPU-kärnor komma från skillnader i OS.
GB4 är ett sådant exempel. 7zip är ett annat sådan exempel
Sedan finns exempel på applikation som har en viss skalning med CPU-kärnor, men som i något läge faller av p.g.a. endera begränsningar i applikationen eller, som i fallet x264 är kanske mer troligt, man börjar slå i gränsen för hur mycket parallellism som finns att utnyttja. I sådana fall uppför sig applikationen rätt lika oavsett OS
Är en TR-2990WX som används i båda fallen ovan, samt det handlar om desktop Windows 10.
Skrivet av Xeonist:
Nej då, det har jag inte missat. Men det är som att säga att Windows (eller Linux) har tillgång till hårddisken som RAM. Det som händer när man börjar använda systemminnet med en GPU renderare är att prestandan hamnar någonstans runt 10%-20%, precis samma sak som händer när du börjar skyffla internminne till en hårddisk/SSD.
Det är i.o.f.s. något som tillkom med Pascal, där kan GPU precis som CPU använda disken som swap-space. Men att jämföra access mot RAM över PCIe är inte jämförbart med swap, inte ens mot swap på NVMe.
Bandbredd mot RAM är ett par heltalsfaktorer högre jämfört med bandbredd över x16 PCIe 3.0, bandbredd mot disk är mer än en tiopotens lägre.
Latens mot RAM är ungefär en tiopotens lägre jämfört med latens över PCIe, latens mot en flashbaserad NVMe som bäst lite mer än två tiopotenser högre.
Fast bandbredd är inte problemet här, vore det så skulle vi se väldigt fin prestandaskalning med RAM-bandbredd. Renderingsprogram uppvisar nästan ingen skalning alls med RAM-bandbredd!
Trolleritricket i detta fall är datalokalitet. Oavsett om man jobbar mot CPU eller GPU med datamängder som mäts i GB måste beräkningen delas upp i väsentligt mindre delproblem.
En modern CPU (eller GPU som används för GPGPU) måste ha problem små nog för att få plats i cache, annars presterar den bedrövligt.
Jensen Huang har rätt stora problem mot investerar om det är så att RTX-serien faktiskt inte är kapabel till "final rendering" av dagens Hollywood produktioner. Detta då han explicit hävdade att Quadro-serien fixar detta under höstens lansering av de korten på Siggraph.
För husbruk räcker konsumentserien av RTX-serien hur bra som helst. De är fullt kapabla att rendera scener som inte till fullo får plats i VRAM då det stödet är automatiskt sedan Pascal och CUDA 8 (man är garanterad att minst CUDA 10 används om det överhuvudtaget går att köra på RTX-korten).
Låter det vara osagt hur mycket det används (eller ens kommer användas) i renderingsprogram, men en viktig nyhet i CUDA 10 (som kommer även kommer tidigare Nvidia kort till gagn) är tillägg till programmeringsmodellen för att bättre stödja uppgiftsparallella problem (ray-tracing är i grunden uppgiftsparallellt, MIMD, medan rendering i grunden är dataparallellt, SIMD).
Turing (egentligen Volta då det är samma SMs där) har bättre HW-stöd för MIMD men även Pascal får en knuff för sådant om man utnyttjar CUDA 10 på rätt sätt.
Skrivet av Xeonist:
Fast jag har ju bevisat för dig att så inte är fallet. Jag är ärligt talat helt ointresserad av GB, men om du säger att GB visar att Windows inte ger mig full tillgång till min hårdvaruprestanda så har jag ju bevisat för dig att det inte är sant.
Har noterat ditt ointresse i GB. Tror fortfarande att poängen som jag försökte göra här helt missade målet, se första stycket.
Men har totalt missat det bevis du skulle ha för att styrka att motsatsen gäller. För någon där åldern kanske börjar ta ut sin rätt på uppmärksamheten, peka gärna ut exakt vad det beviset består i. Tack på förhand.
Skrivet av Xeonist:
Så du menar att du helt kan utesluta kompilatorn som körs? Att det är den som inte kan tillgodogöra sig all hårdvara?
My bad här! Borde självklart att förklarat att kompilatorfallet är extra intressant just då C/C++ kompilatorer är enkeltrådade.
Sättet att använda flera CPU-kärnor uppnås enbart genom att flera filer kompilerar samtidigt, vilket betyder att kompilatorn själv är helt ute ur ekvationen när det kommer till skalbarhet över kärnor och är enbart en funktion av hur väl OS kan schemalägga många samtidigt körande, helt oberoende, program. Till skillnad från t.ex. rendering så använder dock kompilatorer rätt mycket OS-tjänster, primärt i form av filsystemtjänster.
Skrivet av Xeonist:
Hur lång tid tar det att kompilera ett program idag? Det kanske inte är relevant att öka prestandan i kompilatorn, det kanske helt enkelt inte är relevant om det tar 20 minuter eller 40 minuter att kompilera ett program, medans det i allra högsta grad är relevant om det tar 40 dagar eller 36 dagar att rendera en filmscen. I det ena fallet är en prestandaökning på 100% ointressant eftersom kostnaden för den extra beräkningstiden är försumbar, i det andra fallet är en prestandaökning på 10% i alla högsta grad relevant eftersom kostnaden för den beräkningstiden är påtaglig.
Med dagens test-drivna utveckling är kompileringstiden högst relevant då man kompilerar om (delar av) sitt program väldigt många gånger under en arbetsdag. Till skillnad från rendering som går alldeles utmärkt att köra som bakgrundsjobb är det man gör som programmerar den av ens interaktiva flöde (ungefär som modellering för filmskapade).
Kompileringstider är därför mer kritiska idag än de var innan TDD blev normen. Tar man C++ (då det är språket som används i de kompilatortester som refererats här) ligger det riktigt mycket fokus på att driva standarden för språket i en riktning som ger lägre kompileringstider. Långa kompileringstider i C++ är ett jätteproblem för företag som Google, Facebook, Microsoft m.fl.
Skrivet av Xeonist:
Jag säller samma fråga igen, hur kommer det sig att du helt utesluter Indigo Renderer?
???
Tog ju specifikt upp det som ett exempel på renderingsprogram som uppvisar bättre prestanda under Linux på system med icke-uniform latens mot RAM (NUMA-system). D.v.s. trots att det är ett renderingsprogram finns en skillnad, det är "trots" då renderingsprogram är urtypen för embarrassingly parallel vilket är den klart enklaste typen av program att skala över CPU-kärnor då flaskhalsen varken är synkronisering mellan trådar (en OS-tjänst, men behövs knappt vid rendering) eller filoperationer (annat exempel på OS-tjänst som inte heller är en relevant flaskhals vid rendering).
Enda OS:et behöver göra vid rendering är att schemalägga programtrådar. Enda "elaka" Indigo Renderer verkar göra är en viss "over-commit" av OS-trådar kontra antalet CPU-trådar. Ett icke-problem för Linux (och MacOS), men finns en rätt specifik optimering i desktop-Windows (som är en väldigt bra idé för program som kräver låg latens!) som gör att OS-trådarna hoppar runt väldigt mycket mellan CPU-trådar om man har "over-commit" av trådar som alla vill ha 100 % CPU.
Skrivet av Xeonist:
Fast att det skulle finnas några såna skillnader mellan Windows-versioner är har man ju sedan länge "debunkat" (förutom dom skillnader som dom olika licenserna innebär).
Då är det svårt att förklara dels varför Microsoft Windows Internals hävdar att det finns relevanta skillnad och varför de jämförelser t.ex. Phoronix gjort visar att server-versionen ligger närmare Linux i skalbarhet jämfört med desktop Windows 10.
En uppenbar skillnad som definitivt påverkar skalbarhet över kärnor är att längden på en time-slice är tio gånger längre i server-versionen av Windows. Inte ett bra val om man behöver låg latens, men är helt klart vettigt om målet är att maximera "throughput".
Skrivet av Xeonist:
Eller menar du att dina test i Indigo Render ger olika resultat om du kör dom på Windows Pro/Enterprise eller om du kör dom på Windows Server?
Men vänta nu, du började med att säga att felet låg hos Microsoft Windows (din fråga var, parafraserat, "vem kör sån här hårdvara på Windows.."), nu säger du att det inte ligger hos Windows?
Har aldrig hävdat att det finns någon sådan skillnad mellan server/desktop-Windows. för just Indigo. Enda jag sagt om detta program är att trots att det handlar om rendering så har desktop-Windows problem med detta (vilket står i kontrast mot andra renderingsprogram jag sett, generellt fungerar rendering bra under desktop Windows).
Har aldrig sett någon köra Indigo på server-Windows. Men finns jämförelser mellan desktop-Windows och Linux, rätt stor prestandaskillnad på system med många CPU-kärnor och NUMA -> problemen under Windows är ett OS-problem, inte ett problem med Indigo, då det presterar som förväntat under Linux (och går att göra manuell handpåläggning som till stor del fixar problemet även under Windows).
