AMD komt met software om prestaties van cpu's met 24 of 32 cores te verbeteren

AMD maakt op 29 oktober de Dynamic Local Mode beschikbaar via de Ryzen Master-software, die de prestaties in met name games van de Threadripper WX-cpu's moet verbeteren. Dat werkt door cores met directe geheugentoegang prioriteit te geven.

De Threadripper 2970WX en 2990WX bestaan uit vier dies, waarvan er twee direct toegang hebben tot het geheugen. De andere twee dies staan via de Infinity Fabric-interconnect in verbinding met het geheugen, wat resulteert in latency. Applicaties die geen baat hebben bij veel cores, presteren beter als deze worden uitgevoerd door de cores die direct in verbinding staan met het geheugen. De nieuwe Dynamic Local Mode moet zorgen dat dergelijke applicaties automatisch prioriteit krijgen op de cores met directe geheugentoegang.

Volgens eigen tests van AMD levert de Dynamic Local Mode tot 47 procent winst op in games. In dat specifieke geval gaat het om Battlefield 1. In andere games is de prestatiewinst van 10 tot 18 procent. AMD geeft aan dat niet alle applicaties een prestatiewinst zullen laten zien.

De huidige Ryzen Master-software biedt al de keuze uit de opties Local Mode en Distributed Mode, voor toepassingen die respectievelijk lage latency en hoge bandbreedte vereisen. Het wisselen tussen deze modi moet handmatig en vereist een herstart. De nieuwe Dynamic Local Mode werkt zonder herstart en treedt automatisch in werking.

Dynamic Local Mode werkt als een service in Windows en is desgewenst uit te schakelen, of helemaal uit te zetten via de Ryzen Master-software. De functionaliteit is alleen bedoeld voor de Threadripper WX-processors. De Threadripper X-cpu's met maximaal zestien cores hebben twee dies, die beiden in directe verbinding staan met het geheugen.

Vanaf 29 oktober zal de Dynamic Local Mode beschikbaar zijn via een update van de AMD Ryzen Master-software. In de toekomst wil AMD de modus integreren in de chipset drivers, zodat de functionaliteit beschikbaar is zonder het installeren van de optionele Ryzen Master-software.

Op 29 oktober brengt AMD ook de Threadripper 2970WX-processor uit met 24 cores. Dat is het kleinere broertje van de Threadripper 2990WX, die in augustus uitkwam. Daarnaast brengt AMD op die dag de 2920X uit, met twaalf cores.

	Cores/threads	Snelheid/boost	Tdp	Prijs	Beschikbaarheid
Threadripper 2990WX	32/64	3,0 / 4,2GHz	250W	Onbekend	augustus
Threadripper 2970WX	24/48	3,0 / 4,2GHz	250W	$1299	29 oktober
Threadripper 2950X	16/32	3,5 / 4,4GHz	180W	Onbekend	augustus
Threadripper 2920X	12/24	3,5 / 4,3GHz	180W	$649	29 oktober

Reacties (85)

[FireDrunk]

Als AMD die logica nou gewoon open source maakt, en aan Microsoft, Apple en de Linux Open Source community vraagt de logica in te bouwen, zou ik een stuk blijer zijn.

Voor elke scheet moet je tegenwoordig tooltjes installeren om dingen aan de praat te krijgen. De hoeveelheid drivers die we moeten installeren daalt, maar de hoeveelheid Firmware management en utilities stijgt enorm.

Desalniettemin mooi dat ze hier energie in steken!

[Reactie gewijzigd door FireDrunk op 23 juli 2024 21:55]

[PhantomPotato]

Ik ben vrij zeker dat ze al een hele tijd proberen Microsoft zover te krijgen dat ze de scheduler NUMA aware maken. Linux heeft dit al, en dit is ook gewoon open source (en AMD heeft hieraan gecontribueerd).
Microsoft heeft hier gewoon nog geen antwoord op. Ze werken al zo lang met Intel CPUs dat die diep in de NT kernel zijn verwerkt.
Daarnaast "In de toekomst wil AMD de modus integreren in de chipset drivers" is al een heel initiatief. Dit had alleen gewoon door de kernel gedaan moeten worden.

[batjes]

Microsoft heeft in het verleden ook patches in Windows doorgevoerd om de prestaties van AMD te verbeteren. Zie Windows 7 en de Bulldozers.

NT zelf is niet op of voor een bepaalde architectuur geschreven. Dat "Intel CPU's diep in de kernel is verwerkt" is 1 enkele binary blob. Zelfde geld voor ARM, het enige wat MS heeft moeten doen om NT op ARM te laten werken, is een nieuwe binary blob bouwen voor ARM. De rest van de kernel staat volledig los van de architectuur, want die praat via de binary blob tegen de hardware.

NT is trouwens sinds Win7 gewoon NUMA aware: https://docs.microsoft.co...p/procthread/numa-support

Dat reddit topic klopt geen fuck van, die mensen moeten wat vaker de MSDN blogs bezoeken.

[RJG-223]

NT zelf is niet op of voor een bepaalde architectuur geschreven. Dat "Intel CPU's diep in de kernel is verwerkt" is 1 enkele binary blob. Zelfde geld voor ARM, het enige wat MS heeft moeten doen om NT op ARM te laten werken, is een nieuwe binary blob bouwen voor ARM. De rest van de kernel staat volledig los van de architectuur, want die praat via de binary blob tegen de hardware.

Wat hij bedoelt, is dat windows bij het ontwikkelen zorgvuldig getuned wordt zodat het maximaal presteert. Daardoor wordt het hele OS afhankelijk van de processoren waarop het getest wordt. Op een processor die zich iets anders gedraagt dan de processoren waarop getest is, kan dat betekenenen dat een gebruikt algoritme juist tot verkeerde keuzes van het OS leidt (in dit geval waarschijnlijk in de scheduler), en dus tot slechte performance.

NT is trouwens sinds Win7 gewoon NUMA aware

Het kan wel NUMA-aware zijn. Dat betekent nog niet dat het ook fatsoenlijk werkt voor allerlei verschillende NUMA architecturen. In dit geval werkt windows dus bagger op een Ryzen WX processor. De meest waarschijnlijke, of zelfs enige mogelijke verklaring daarvoor, is dat de NUMA-implementatie van Windows niet deugt. Dat windows technisch gesproken NUMA-aware is doet daaraan niets af. Aan de processor ligt het in ieder geval niet, want onder Linux is de performance van dezelfde software wel goed.

Dat reddit topic klopt geen fuck van, die mensen moeten wat vaker de MSDN blogs bezoeken.

Windows fanboy zeker ?

Als je iets roept, en sterke taal gebruikt, zorg er dan voor dat je weet waarover je het hebt. Ik neem aan dat je dit reddit topic bedoelt (je zegt alleen 'dat reddit topic'). Het originele artikel van de tests op windows en linux is hier.

Het is (dus) een feit dat verschillende applicaties onder windows op een Ryzen WX bijzonder slecht presteren, terwijl diezelfde applicaties onder Linux wel een goede performance hebben. Dat ligt hoogstwaarschijnlijk aan de NUMA-algoritmes in Windows (of het gebrek aan die algoritmes?).

Nu kun je kibbelen over de vraag of windows wel of niet NUMA-aware is, maar als de NUMA performance zo slecht is, dan kun je mensen niet verwijten dat ze aannemen dat windows dus niet NUMA-aware is.

Ik twijfel er niet aan dat MS dit gebrek t.z.t. zal verhelpen. Maar omdat het nog (steeds?) niet gebeurd is, is het natuurlijk logisch dat AMD dan maar zelf een workaround uitbrengt.

[Reactie gewijzigd door RJG-223 op 23 juli 2024 21:55]

[lekorque]

Het is (dus) een feit dat verschillende applicaties onder windows op een Ryzen WX bijzonder slecht presteren, terwijl diezelfde applicaties onder Linux wel een goede performance hebben. Dat ligt hoogstwaarschijnlijk aan de NUMA-algoritmes in Windows (of het gebrek aan die algoritmes?).

Ook dat is een aanname. Er zijn ontelbare factoren die invloed hebben op de performance van een applicatie, en daarnaast zijn er zoveel verschillen tussen zowel de opbouw als de omgeving van OS'en dat je een verschil in prestatie ABSOLUUT niet kunt wegschrijven naar één oorzaak.
Applicaties die op meerdere platformen beschikbaar zijn, hoeven niet per definitie dezelfde broncode te delen. Daarnaast is de compiler waarmee de binary voor het desbetreffende platform wordt gecompiled van groot belang voor de performance op een platform.
Een van de grootste oorzaken van een verschil in prestatie van een applicatie tussen twee OS'en ligt bij de developer. Een multithreading aanpak in een Windows applicatie vraagt vaak om hele andere optimalisaties dan in een Linux app. Als men "slechts" dezelfde code voor verschillende platformen heeft gecompiled, zonder platformspecifieke optimalisaties toe te voegen, dan krijg je natuurlijk verschillen in prestaties (of zelfs betrouwbaarheid).

[Iblies]

Hier is een mooie test hoe Threadripper op Linux werkt en hoe ver Intel daar op achterloopt.
https://www.phoronix.com/...em=amd-linux-2990wx&num=9

Het is in bepaalde gevallen veel goedkoper om een threadripper aan te schaffen dan een Intel.
De AMD draait bijna rondjes om de Intel.

AMD zit inderdaad eigenlijk met het kip-ei probleem. Windows werkt niet optimaal en zou beter kunnen, software-ontwikkelaars programmeren weer voor Windows, etc.
Prachtige CPU, maar OS (Windows) is nog het probleem.

[CrazyJoe]

Eh, alle benchmarks die getoond worden op de door jouw gelinkte pagina gaan over performance per dollar en dat tussen een 18 core CPU (Intel) en een 32 core CPU (AMD). Ik zie niet zo snel hoe dit een uitspraak doet over de werking van Threadripper op Linux vs de werking van I9 op Linux?

De meeste testen geven geen factor 1.8 in het voordeel van AMD, alleen de "HPC Challenge v1.5.0", "John The Ripper v1.8.0-jumbo-1: Traditional DES" en "Sysbench v2018-07-28" komen daar in de buurt. De rest komt er niet in de buurt.

Intel hoeft dus enkel een processor met meer cores voor dezelfde prijs te lanceren of de prijs van de i9 7980XE drastisch te verlagen om het verschil recht te trekken.

AMD heeft dus op dit moment een processor in de aanbieding die goed is in prijs/performance situaties, maar per core performance is nog steeds niet zo goed als bij Intel.

Dit zal waarschijnlijk nog wel even zo blijven omdat Intel moeite heeft om de 10nm process node commercieel gezien bruikbaar te maken (goede yields zijn daarvoor nodig) en dus een schaalbaarheids en dus kostprijs probleem heeft voor grote CPU's (grotere core counts zijn dus lastig commercieel te verantwoorden voor de consumer markt).

Maar Core design technisch gezien heeft AMD nog de nodige stapjes te zetten voordat ze Intel op dat gebied naar de kroon kunnen steken.

[enchion]

"The Threadripper 2990WX is launching for $1799 USD while the Core i9 7980XE retail processor at Internet retailers as of writing is $1879 USD or even above $1900 USD at some retailers."

~Zelfde prijs dus. Maw AMD maakt gehakt van de gekozen Intel CPU.
Voor die CPU zou Intel de prijs moeten halveren om de winst terug te pakken.

[Reactie gewijzigd door enchion op 23 juli 2024 21:55]

[smartsys]

Moet je ook even alle bugfixes op de Intel activeren en dan nog een keer benchen!

Heel grappig als je nu én veilig wil zijn én een ouder OS dan Windows Server 2016 wil gebruiken in combinatie met Hyper-V. Zet HyperThreading maar uit is het advies van Microsoft. Hup weg 30% van je performance.

Als je al deze performance degradaties ten nadele van Intel bij elkaar optelt en dan gaat vergelijken op IPC, dan is het verschil een flink stuk kleiner geworden.
Pak daarbij de aanzienlijk lagere prijs van een AMD én de leveringsproblemen van Intel en je kunt eigenlijk alleen maar concluderen dat Intel een serieus probleem heeft en dit voor AMD een positief effect heeft.

[PhantomPotato]

Dan is de "saving grace" van AMD weer dat de meeste servers tegenwoordig op Linux draaien (met name web en dergelijken). Zelfs Microsoft begint voor sommige services over te stappen naar, of op zijn minst ondersteunen van, Linux servers.
Workstation is Linux nog net niet zo ver op de markt, hoewel de tools toch wel goed op gang zijn gekomen (Blender, Krita, Da Vinci Resolve, VS Code etc.).

[killercow]

Begint? Het grootste deel van Microsoft's Azure cloud draait linux.
https://www.zdnet.com/article/linux-now-dominates-azure/

[GoBieN-Be]

Dat is omdat de klanten van Azure Linux als guest-OS draaien.
Microsoft zelf gebruikt Hyper-V (en dus Windows) op zijn Azure servers.

[killercow]

Bijna goed:

https://en.wikipedia.org/wiki/Microsoft_Linux_distributions

[GoBieN-Be]

Interessant.
Maar onderstaand spreken ze dan weer enkel over Hyper-V met een speciale software laag over.
https://en.wikipedia.org/wiki/Microsoft_Azure#Design

Nu ja, het ZDnet artikel ging wel degelijk over de virtuele machines die op Azure staan en niet over de Azure infrastructuur zelf.

[Toettoetdaan]

Dit dus, AMD komt hier eigenlijk met aan aanpassing aan de Windows scheduler. En dat is eigenlijk een behoorlijke sneer want dit hoort gewoon in het OS (zoals het wel in Linux zit) en is natuurlijk ook een probleem op Windows Server.

[MSalters]

Ik weeet niet waarom je er "zo zeker van bent" (dat AMD probeert om Windows NUMA-aware te krijgen).

Windows is namelijk al lang NUMA-aware. Sterker nog, sinds Windows 7 is de NUMA support uitgebreid tot > 64 cores.

Evengoed snap ik niet waarom je aanneemt dat Microsoft's support voor Intel hier iets mee te maken heeft. Kijk naar MSDN - er is niet eens de aanname dat NUMA beperkt is tot x86/x64.

[ACM]

Ook in Linux valt er performance-winst te behalen door applicaties expliciet op specifieke nodes/memory-zones te zetten in numa-opstellingen.

Daar bestaat de ondersteuning om het op applicatie-niveau te regelen al een tijdje (met de cli-tool numactl), waardoor AMD daar niet zelf meer iets voor hoeft te doen. Maar impliceren dat Linux iets automatisch doet/kan wat Windows niet doet, lijkt me wat te ver gaan, zoals @MSalters ook al aangeeft.

[killercow]

Sinds kernel 4.10 detecteerd de linux kernel automatisch en correct de ryzen cores, hun numa opstelling, de onderlingen verbdingen en toeganag tot het geheugen .Het detecteerd in de scheduler ook de threads die het wegens performance redenen wil blijven draaien op 1 setje directe numa-buren.

Windows heeft dat trucje vooralsnog anders opgelost omdat het meer de intel aanpak van cores en geheugenverdeling verwacht.

Er zijn overigens legio zaken die linux wel kan, en windows niet kan of doet. Dus waarom je dat in dit geval te ver zou vinden gaan is me een raadsel. Andersom is het vast net zo, sommige zaken zijn nu eenmaal historisch of door architectuur keuzes zo gegroeid.

[Reactie gewijzigd door killercow op 23 juli 2024 21:55]

[ACM]

Er zijn uiteraard allerlei verschillen tussen Linux en Windows, ik bedoelde met die zin juist letterlijk dit voorbeeld.

[WCA]

Ik vermoed dat dit iets is dat op OS level afgehandeld moet worden, en daardoor niet in firmware kan. Het OS doet de volledige scheduling, dus dat klinkt wel logisch.

[hooibergje]

Denk het eigenlijk niet. Het lijkt me eerder dat de CPU scheduler dit regelt, en dat is dus een laag is onder het OS. Maar ik kan er naast zitten...

[Countess]

Er is geen overkoepelende CPU scheduler die over alle cores heen kijkt. de scheduler's in je CPU zijn per core, en bekijken alleen op instructie niveau per thread (of 2 threads met SMT) hoe de uitvoer daarvan zo efficient mogelijk door de core heen kan.

Het bepalen welke thread op welke core word uitgevoerd is echt een OS taak.

[Reactie gewijzigd door Countess op 23 juli 2024 21:55]

[MSalters]

Kul. Al vanaf de eerste dual-socket systemen (met 1 core/socket) waren zowel de Windows NT scheduler als de Linux scheduler compleet in controle, zowel binnen een core als tussen cores. Een CPU zelf heeft geen enkele invloed op de scheduling. Dat kan ook praktisch niet: de CPU heeft geen lijst van runnable processen, geen idee welke processen wachten op DMA of andere I/O, etcetera.

De enige praktische uitzondering zijn hyperthreading (SMT) systemen. Daar bepaalt het OS welke 2 threads er op 1 fysieke core draaien; de CPU kan dan die 2 threads onderling schedulen. Dat is dus een extreem beperkte scheduler - en regelmatig is er niet eens iets te schedulen omdat 1 van die 2 threads staat te wachten op het geheugen (de rechtvaardiging voor SMT)

[Countess]

je zegt niks wat tegen mijn verhaal in gaat wat de windows scheduler betreft, maar je voorstelling van de scheduler in de CPU duidelijk is veel te beperkt.

er is een hele hoop te scheduler binnen een thread in een CPU. maar dat gaat dus op instructie niveau, binnen 1 thread. (edit: heb de tekst van mijn originele bericht iets aangepast om dit te verduidelijken)

als je hier kijkt naar de individual core diagram https://en.wikichip.org/w...res/sandy_bridge_(client)

dan zie je dat deze CPU tot 6 verschillende pipelines heeft, en de scheduler bepaald welke instructies wanneer in zo'n pipeline worden gestopt.

ik noemde het alleen maar om, hopelijk, bij hooibergje verwarring weg te nemen, die, zo leek het, wel wist dat CPU's een scheduler hebben, maar niet precies wist wat die deden.

[Reactie gewijzigd door Countess op 23 juli 2024 21:55]

[MSalters]

Ik zou dat geen scheduling noemen. Sowieso zijn het twee delen, instruction dispatching en instruction retirement. Je plaatje laat vooral een topografisch overzicht zien van waar de instructiestromen lopen, maar niet wanneer. Instruction dispatching is de voorkant van het proces, waarin instructies uit de instruction stream naar EU's worden gestuurd. Instruction retirement is de spannende fase - omdat de verschillende instructies niet even snel zijn komen de resultaten uit de EU's niet in de volgorde van de originele thread. Gedurende de retirement fase moet dat allemaal weer logisch gemaakt worden. Dat is dus een soort " scheduling achteraf".

[Countess]

Dat ding heet gewoon de scheduler. dat is de officiële naam. En die bestaat al sinds de eerste OoO execution CPU's. (voor intel is dat dus al sinds de pentium pro)

er is zelfs een kop in dat wikipedia article over de scheduler.
https://en.wikichip.org/w...bridge_(client)#Scheduler

retirements plannen is ook een taak van die zelfde schedular. daar zijn pipelines voor. poort 2, 3 en 4 in dit geval. Alle resultaten van instructies komen eerst terug de scheduler in, om gebruikt te worden bij volgende instructie die mogelijk er van afhankelijk waren, of om terug de cache in geplaatst te worden als ze pas veel langer nodig zijn.

Ja naar het cache schrijven is relatief traag maar daar hoef je niet op de wachten, want de schedular weet dat hij die gegevens voorlopig toch niet nodig heeft, Echter voor een soms door de pipeline heen is zijn er meerdere clocktikken overheen gegaan, en als je instructies hebt die afhankelijk zijn van de uitkomst van die som dan is het handig als je die som zo snel mogelijk doet, en voorrang heeft over andere instructies die misschien wel eerder waren, maar waarvan geen andere instructies op korte termijn afhankelijk van zijn.

Dat is het hele idee van een OoO CPU. parallel uitvoerbare delen vinden binnen een thread door het goed managen van onderlinge afhankelijkheden.

[Reactie gewijzigd door Countess op 23 juli 2024 21:55]

[goarilla]

Maar dit gaat over hoe processes gescheduled worden in een besturingssysteem.
Die bepaalt eerder dingen zoals; op welke CPU komt dit process/thread en
wanneer draait welk process en voor hoe lang.

[Countess]

dat klopt wat dit topic betreft.

origineel ging mijn reply op hooibergje erover dat hij wat verwarring had over op welk niveau de scheduler in je CPU operated. maar toen had MSalters naar aanleiding van mijn eerste uitleg verwarring over wat de scheduler in je CPU nu deed, en bleef daarin volharden.

[Reactie gewijzigd door Countess op 23 juli 2024 21:55]

[Niemand_Anders]

Ik denk dat de utility services niets anders doet dan een CPU affinity mask op het process van de game zetten. Flight Simulator / Prepar3d gebruikers doen dit al jaren om het maximale uit hun PC te halen..

Overigens is de reden hiervan dat de helft van de cores het geheugen via Infinity Fabric moet bereiken. Daar zit een lichte latency op en die overhead kun je besparen als je de cores gebruikt welke op de 'die' zitten welke direct met de memory controller zijn verbonden..

En hoewel games steeds beter overweg kunnen met meerdere cores zie ik het niet snel gebeuren dat games mee dan 12 of 16 cores gaan gebruiken. De thread synchronisatie overhead is dan gewoon te hoog om nog een acceptabele framerate te behalen..

[teacup]

Een vraag die ik heb of deze optimalisatie van processoren met grote aantallen cores zowel voor Intel als AMD matig in het OS (denk hierbij primair aan W10) is afgedekt. In dit geval zou AMD met deze tool een tandje extra zetten. AMD heeft door haar single core performance wel iets meer belang bij het beter inzetten de beschikbare cores.

De architectuur van AMD processoren is natuurlijk wel anders dan die van Intel processoren. Het OS zou voor een goede support parallel beide processorfamilies moeten afdekken. Ik verwacht niet dat dit met gemeenschappelijke code kan, want dan bereik je een ultimatumoplossing die voor geen enkele processor optimaal is.

Nu is mijn verwachting dat Microsoft, AMD en Intel intensieve uitwisseling met elkaar hebben om de interactie processor-OS zo optimaal mogelijk te krijgen. Moeten we deze tool nu lezen als een blijk van ontevredenheid van AMD over hoe, of hoe snel, Microsoft de support van AMD processoren supporteerd? Of is er een argument om deze balacering nadrukkelijk in een losse tool te willen en niet in het OS. Om eerlijk te zijn was mijn eerste reactie die van Firedrunk, een losse tool voegt ook kwetsbaarheid aan de oplossing toe.

[lenwar]

Mij lijkt dat als de CPU het zelf zou kunnen, dat hij het dan zelf ook wel zou doen. Ik ben geen specialist, maar de CPU is volgens mij niet bewust van welk OS-proces de opdracht is die hij moet verwerken.

Wat mij eerder verbaasd, is dat een stukje software zoveel invloed kan uitoefenen op iets low-level al de CPU-scheduler. Wat me nog meer verbaasd is dat het zoveel (minimaal 10% in hun eigen tests) scheelt in de FPS van de games.Ik kreeg altijd het gevoel dat een CPU maar marginaal bijdroeg hieraan.

[sonnemans]

Als ik het goed begrijp zorgt de software vooral dat de cores die het makkelijkst met het memory communiceren gebruikt worden. Bij threadripper is bij wijze van spreken niet elke core gelijk om dat ze op een andere plek, met dus een langere latency naar het memory kunnen liggen. Door de betere cores altijd te laten kiezen kun je dus idd veel winst halen

[grasnek]

De system specs en test methode staan in het originele artikel. Er werd een GTX 1080 gebruikt en de games draaiden op 1080p, daar creeër je vanzelf een CPU bottleneck mee.

[MSalters]

Dat is natuurlijk opzettelijk. Met een GPU bottleneck test je NVidia's GPU scheduler, niet AMD's CPU scheduler.

[grasnek]

Dat bedoelde ik te zeggen. Ik was lui en dacht met minder woorden af te kunnen

Je ziet dergelijke opmerkingen wel vaker van "waarom doe je een 1080Ti in een systeem en test je op 1080p om een AMD Ryzen 3 CPU te testen, dat is toch geen realistische situatie?"
Meestal in youtube comments. Daar moet je wel degelijk de volledige uitleg typen.

[FireDrunk]

Dat probeer ik ook te zeggen. Vraag juist de OS bouwers het in de 'gewone' scheduler te bouwen ipv *weer* een extra utility.

[Zer0]

Vraag juist de OS bouwers het in de 'gewone' scheduler te bouwen ipv *weer* een extra utility.

Dat lijkt me geen goed plan, dat levert alleen maar meer complexiteit in de "gewone" scheduler op, die weer invloed kan hebben op de prestaties van "gewone" CPU's, Een aparte scheduler lijkt me dan een beter idee.

[MSalters]

De bestaande scheduler is al sinds Windows 7 geschikt voor NUMA architecturen met > 64 processoren. ThreadRipper is echt niet zo extreem; een quad-socket Xeon systeem met 4x28 cores is veel exotischer.

En je wil sowieso maar 1 scheduler hebben: als Windows en deze AMD scheduler allebei proberen om een thread aan een CPU core toe te wijzen zijn er twee opties: óf ze zijn het eens (en dan is de AMD scheduler overbodig), of ze zijn het niet eens en dan wordt de thread ge-ping-ponged van de ene core naar de andere.

[RJG-223]

De bestaande scheduler is al sinds Windows 7 geschikt voor NUMA architecturen met > 64 processoren. ThreadRipper is echt niet zo extreem.

Leg dan eens uit waarom verschillende applicaties onder windows op een WX zo belabberd presteren, terwijl diezelfde applicaties onder Linux wel goede prestaties hebben (link) ?

De scheduler kan technisch gesproken wel NUMA-aware zijn, dat betekent nog niet dat de implementatie deugt. En die deugt in dit geval dus blijkbaar niet. Dat het wel goed kán, blijkt uit het feit dat Linux dit probleem niet heeft.

een quad-socket Xeon systeem met 4x28 cores is veel exotischer.

Ik ken die processor niet, maar hoogstwaarschijnlijk is dat een gewone 28-core processor, waar alle cores van een processor dezelfde geheugentoegang hebben. De individuele processoren zijn dan dus geen NUMA. De 4 processoren hebben neem ik aan elk hun privé geheugen (zodat het geheel een NUMA systeem is), en natuurlijk de mogelijkheid om elkaars geheugen te benaderen. We hebben dus 4 identieke NUMA nodes. Dat is helemaal niet exotisch. Dat is (op NUMA gebied) ongeveer zo eenvoudig als het maar mogelijk is.

Neem dan de WX: 4 NUMA nodes, met elk 8 cores. Van de 4 NUMA nodes hebben er twee géén eigen geheugen, terwijl de ander twee dat wel hebben. Dat is beslist exxotischer dan een standaad volledig-symmetrisch NUMA systeem als een quad-Xeon.

[MSalters]

[...]
Leg dan eens uit waarom verschillende applicaties onder windows op een WX zo belabberd presteren, terwijl diezelfde applicaties onder Linux wel goede prestaties hebben (link) ?

Geen geweldig artikel. "GCC 8.2 -march=native" kan je met wat moeite nog wel reverse-engineeren (" native" is een shortcut voor een verzameling host-target specifieke optimalisaties", maar de gebruikte compiler voor Windows wordt compleet niet genoemd.

Jouw aanname dat de scheduler "niet deugt" is dus al niet te trekken op bassi van dat artikel; de compiler c.q. de runtime van de compiler is minstens net zo verdacht.

Overigens kan ik niet uitsluiten dat de Windows scheduler suboptimaal is. Op een NUMA systeem is er een trade-off wanneer je besluit om tóch een sub-obtimale core te gebruiken. De relevante metrics hangen af van de exacte NUMA architectuur; de scheduler moet een tabel met weegfactoren gebruiken. Die weegfactoren varieren vermoedelijk zelfs tussen 2-socket en 4-socket Xeon setups; met een quad-die ontwerp als ThreadRipper heb je zeker nieuwe weegfactoren nodig. Dat is dus alleen data; de complexiteit van de scheduler (waar @Zer0 naar verwees) verandert niet door een andere tabel in te laden.

[mjtdevries]

De meeste quad-Xeon systemen zijn niet volledig symmetrisch. Daarbij is het eigen geheugen het snelste, naar de naastliggende xeon trager en de "verste" nog trager.
Dat lijkt me zeker zo complex als de WX.

[StefanTs]

Daarom stelt FireDrunk voor om het door de OS boeren te laten implementeren.
Vergelijkbaar met een OS dat niets van Hyperthreading snapt en daarom denkt dat het met daadwerkelijke CPU's te maken heeft. Zo zou het OS ook bewust moeten zijn van dit verschil tussen deze cores om er efficient mee om te gaan.

[Verwijderd]

Je bedoelt dat een OS numa aware moet zijn, maar dan op Core niveau, ipv op CPU niveau?
Want dat is gewoon wat het is, het geheugen is non uniform over de cores.

[egnappahz]

Jouw redenering gaat zeker op voor opensource systemen zoals linux, maar met windows werken betekent nu eenmaal met vele tooltjes werken die 3rd party zijn. Ik vrees dat AMD daar niet veel kan aan veranderen...

[multipasser]

Het zou toch cool zijn als er software was die alle cores bundelt en zich voordoet als 1 core!
Zodat alle single core apps toch volledig multicore zijn.

Ik kijk alleen al naar Aftereffects! Die sinds 2014cc GEEN multicore meer ondersteunt! Om te huilen!
Ik zit met 20cores en mijn cpu gaat naar 140% max tijdens renderen ipv de 2000% die het zou moeten halen.

[Countess]

Als berekening na elkaar moeten gebeuren (omdat bijvoorbeeld de berekening elke keer afhankelijk is van het resultaat van de vorige berekening) dan heb je niks aan multicore's. dat moet zich afspelen binnen 1 core.

En daarom is het ook niet goed mogelijk om meerdere cores zich voor te laten doen als 1.
sterker nog, dat doen cores intern eigenlijk al, met meerdere pipelines, die proberen op hele kleine schaal parallel uitvoerbare taken te vinden.

Als iets echter naar een andere core moet, dan zit daar een enorme latency penalty op (in vergelijking met binnen de eigen core blijven). Dat heeft dus alleen zin als je weet dat je redelijk onafhankelijk van elkaar die berekeningen kan doen. En dat kan een scheduler gewoon niet bedenken. die kan niet ver genoeg vooruit kijken om dat te bepalen.

[koelpasta]

Als berekening na elkaar moeten gebeuren (omdat bijvoorbeeld de berekening elke keer afhankelijk is van het resultaat van de vorige berekening) dan heb je niks aan multicore's. dat moet zich afspelen binnen 1 core.

Alleen gaat het bij after effects over rekenen aan 2D plaatjes (met wat 3D hier en daar). Daarnaast zijn er losse videoframes waar je onafhankelijk tegenaan kunt renderen. Dit zijn typisch dingen die prima te paralleliseren zijn. Dit is ook de reden waarom een GPU zo vreselijk veel parallele processors bevat.

Wat dat betreft lijkt het er eerder op dat adobe gewoon niet meegaat met de trends van de afgelopen pakumbeet 10 jaar.

[Reactie gewijzigd door koelpasta op 23 juli 2024 21:55]

[Countess]

Dat zou ik ook zeggen, maar ik reageerde meer op zijn suggestie dat er software moet komen die meerdere cores zich moet laten voordoen als 1, en waarom dat niet gaat werken.

meerdere frames is een mooi voorbeeld. een scheduler kan daar geen idee van hebben, Terwijl de developer van de software dat wel weet. Dat is echt iets dat de developer moet bepalen.

[koelpasta]

Dat zou ik ook zeggen, maar ik reageerde meer op zijn suggestie dat er software moet komen die meerdere cores zich moet laten voordoen als 1, en waarom dat niet gaat werken.

Ja, met dat verhaal ben ik het natuurlijk eens
Zo werkt dat nou eenmaal met de gangbare CPU's.

Ik vond het alleen erg raar dat notabene gebruikers van adobe videosoftware klagen over slecht gebruikte multicore architecturen. Daar lijkt iets niet helemaal lekker te zitten.

[leuk_he]

Zo te zien is aftereffects naar GPU acceleratie aan het gaan ipv van CPU multicore. Daarmee verwachten ze meer winste te kunnen halen. En meerder GPU kaarten is wellicht goedkoper dan een moederbord met tig cores.

Maar om alle soorten workload te verplaatsen naar de GPU heeft blijkbaar nog wat tijd nodig. En uiteraard moeten de gebruikers nog nieuwe hardware krijgen die een recente GPU kaart heeft ipv heel veel cores die ze voorheen konden gebruiken.

Dat zelfde zie je ook bij games hoor, dat ze beperkt zijn door de videokaart, en na een aantal cores niet meer schalen.

[Luuk1983]

Daar heb je tegenwoordig toch je GPU voor? Die is daar veel sneller en beter in dan de CPU.

[flippy]

dat is ook niet 1 core, dat zijn er duizenden.

[Mentox]

Een CUDA core is eigelijk niet echt een core: https://www.youtube.com/watch?v=x-N6pjBbyY0

[Vincenz0]

Zo werkt het natuurlijk niet, je kan niet magisch van meerdere cores 1 core maken.

[StefanTs]

En hoe ga je een enkele thread dan verdelen over meerdere cores? Het probleem is dat code afhankelijk is van de uitkomst van voorgaande code en je dat zodoende niet parallel kunt uitvoeren.

Als ik 2*2*2 wil uitrekenen doe ik eerst 2*2=4 en dan 4*2 =8. Ik kan 4*2 niet uitvoeren voor ik uberhaupt weet dat 2*2 4 is.

En dan zullen er vast wel kleine verbeteringen mogelijk zijn in specifieke gevallen. Als het bv 2*2*2*2 is kan ik 2*2 uitrekenen parallel aan 2*2 en vervolgens het resultaat van beide vermenigvuldigen. Dan heb ik 3 stappen ipv 4 waarvan de eerste 2 paralllel kunnen en ik dus 2 keer zo snel klaar ben. Ervanuitgaande dat elke stap even lang duurt. Maar om dat soort situaties probleemloos te herkennen is ook weer lastig en kost ook weer rekenkracht. Helemaal als je veel cores wilt benutten.

Volgens mij wilde NEC zoiets jaren geleden eens doen maar daar heb ik nooit meer wat van gehoord.

[TimNomivaas]

Als je dat doet krijg je volgens mij:

2*2 =4 en 2*2 =4
4+4 =8
2*8 =16

Dus nog steeds 4 stappen, maar de eerste 2 wel tegelijk.

[StefanTs]

Dat is in tijd toch een stap minder. Maar waarom 4+4 en dan 2*8? Gewoon 4*4=16.

Los daarvan is het natuurlijk gewoon een versimpeling en lijkt het punt me duidelijk

[Osiummaster]

Multi-core voert instructies uit die niet van elkaar afhankelijk zijn. Het is voor de CPU niet mogelijk om te weten welke instructies van elkaar afhankelijk zijn voordat hij deze uitgevoerd heeft. Het is aan Adobe om aan te geven wat er van elkaar afhankelijk is en wat niet. Dat kan de CPU niet zomaar gaan bepalen

Misschien zou het mogelijk zijn om dmv machine learning per programma heel veel tests uit te voeren, om uit te vinden welke instructies van elkaar afhankelijk zijn en welke naast elkaar uitgevoerd kunnen worden, en nog steeds hetzelfde resultaat geven. Op deze manier kan het automatisch multi-core geschreven worden

Dit zou echter geen universele oplossing zijn omdat er per programma uitgebreid getest zou moeten worden en er nog steeds zouden er onverwachte bugs kunnen verschijnen in dit machine learning gebeuren waardoor je hele programma stuk kan gaan.

[maratropa]

AE is idd goed veranderd. 8700k is nu de beste keuze. Maar er komen steeds meer gpu effecten in dus de snelheid komt weer terug

[MSalters]

Het zou toch cool zijn als er software was die alle cores bundelt en zich voordoet als 1 core!
Zodat alle single core apps toch volledig multicore zijn.

Tot op zekere hoogte is dat mogelijk - en al 25 jaar!

De Intel Pentium (de originele, opvolger van de 486) was de eerste x86 CPU met 2 Execution Units die in parallel konden draaien. Inmiddels is het al mogelijk om met 5 of 6 Execution Units tegelijk aan een thread te werken.

Alleen: we kunnen tegenwoordig ook wel 40 of meer Execution Units op een enkele CPU kwijt. En zoveel kunnen er niet tegelijk aan 1 thread werken - de complexiteit wordt dan veel te groot. Elke EU moet checken of zijn resultaten niet in strijd zijn met de resultaten van een andere EU, die in thread-volgorde eerder een resultaat moest produceren. Met 5 EU's per core heb je dus maar 5x4=20 checks, met 10 heb je al 10x9=90 checks. Dat is geen verdubbeling, dat is 450% meer checks.

Vandaar dus dat we 8-core CPU's hebben die elk 6 EU's hebben.

[Sidiox]

Ligt het aan mij of klinkt dit heel erg als de Core Lasso software? Doet me ook heel erg denken aan wat Wendell van L1tech heeft laten zien met betrekking tot NUMA en UMA. (aanrader om te kijken als je wat meer kennis over de gevolgen van deze memory Access dingetjes wil zien op prestaties)

[Countess]

Dat werkt allemaal op het zelfde vlak idd. Maar de bedoeling hiervan is dat het kan zonder dat je er naar om hoeft te kijken, of zelfs maar iets van af hoeft te weten.

[winwiz]

Mee eens, Wendell heeft laten zien dat dit een significante prestatie winst kan geven.

[grasnek]

"Volgens eigen tests van AMD levert de Dynamic Local Mode tot 47 procent winst op in games."

Ik vraag me altijd af waarom juist een aantal games en een benchmark als voorbeeld genomen worden bij dit soort CPUs. Hoeveel mensen gamen nou werkelijk op 48 of 64 thread CPUs? Daar koop je dit soort hardware toch helemaal niet voor? Ik vraag me echt af waarom AMD niet voorbeelden voor de daadwerkelijke doelgroep geeft. Behalve wat tech channels als LTT die het voor de grap / views doen denk ik niet dat gamers je markt zijn.

[mstx]

Omdat de software die van alle cores gebruik maakt al prima werkt. Op een workstation zul je ook sporadisch software gebruiken die niet alle cores benut of wil je soms een potje gamen en daar is dit voor bedoeld, dus ook logisch dat ze daar de benchmarkresultaten van tonen.

[Countess]

AMD heeft zelfs expliciet gezegd dat de WX series niet bedoeld is voor gamers.

Maar het is wel precies die workload die hier het meeste baad bij heeft. en ik denk dat er genoeg mensen zijn die hun workstations van overdag s'avonds gebruiken om te gamen.

[ro8in]

Ik heb een Core i7-6700k en heb eigenlijk nooit een game de 100% van een core zien gebruiken. Ik vraag me dan al jaren af wat voor nut een cpu nou nog heeft voor games. Volgens mij heb je met een gemiddelde i5 meer dan zat voor bijna alle games. Ik vraag me dan ook sterk af wat deze 48% winst inhoud? Hebben ze het hier nou echt over 48% meer FPS, want dat zou echt enorm zijn.

[Countess]

het is vooral enorm omdat het hiervoor enorm mis ging doordat de threads van de games van elkaar gescheduled werden, terwijl bij gaming er ,relatief tot andere workloads, vaak tussen threads word gesynced en ze minder voorspelbare geheugen reads hebben.

[renslmf23]

Misschien dat ze hebben getest op een hele lage resolutie. Daardoor speelt de gpu bijna geen rol meer, en is het voornamelijk de cpu die de bottleneck is. Dan is 48% fps-winst dus niet zo gek.

[ro8in]

Ja of geheel zonder gpu en alleen als een benchtest. Maarja dat is dan totaal niet realistisch in werkelijkheid heb je volgens mij echt 0% winst dan.

[misterbennie]

Er is getest met een GTX 1080 op 1080P
Een resolutie waar heel veel mensen nog op gamen.
De CPU wordt daarbij de bottleneck, dus is je winst > 0%.
Wanneer de GPU de bottleneck wordt, is je winst waarschijnlijk 0% omdat je de processor niet voor 100% belast.

[ro8in]

Hoe is je cpu de bottleneck met een GTX 1080 op 1080p? Kan de gpu dan sneller frames verwerken dan de cpu kan aanleveren?

[misterbennie]

Omdat de GPU (in vele spelen) sneller kan renderen dan een "trage" processor data aan kan leveren.
Dus is de CPU de bottleneck.
Ga naar 720P en de CPU wordt nog meer de bottleneck.

Uit het originele artikel:

Footnotes:
1. Testing by AMD Performance Labs as of 10/4/2018. Results presented in order of Dynamic Local Mode OFF vs. ON (% difference). All games tested at 1920x1080 with the graphics API and in-game graphics preset noted.

• Far Cry 5 (DirectX 11/Ultra): 48 FPS vs. 53 FPS (10% faster);
• PUBG (DirectX 11/Ultra): 99 FPS vs. 111 FPS (12% faster);
• Battlefield 1 (DirectX 12/Ultra): 136 FPS vs. 200 FPS (47% faster);
• Alien: Isolation (DirectX® 11/Ultra): 199 FPS vs. 234 FPS (18% faster);
• Unreal Engine Compile Time: 954 seconds vs. 810 seconds (15% faster);
• Rodinia HPC Benchmark Duration: 4.25 vs. 3.36 (21% faster).


System configuration: AMD Ryzen Threadripper Reference Motherboard, AMD Ryzen Threadripper 2990WX, 4x8GB DDR4-3200, GeForce GTX 1080 (driver 399.24), Samsung 850 Pro SSD, Windows 10 Pro x64 (RS4). Results may vary with drivers and system configuration.

[Reactie gewijzigd door misterbennie op 23 juli 2024 21:55]

[computerjunky]

Een 7700k wat momenteel toch wel DE gaming cpu is idd al een bottleneck voor een gtx 1080 en zelfs in veel gevallen een 1070TI.
Dit komt deels door de enorme hoeveelheid data er te verwerken is en deels doordat games nog niet goed alle cores/threads benutten en de load niet goed verdeeld is.
Soms kan simpelweg vsync echter het probleem oplossen doordat dit de frames limiteerd maar als je een 144 hz scherm wil vullen gaat dit natuurlijk niet helpen.

https://www.youtube.com/watch?v=dt5CNi0aEpI skip naar iets van 3 min 45 om wat ergernissen te voorkomen hehe.

[Reactie gewijzigd door computerjunky op 23 juli 2024 21:55]

[Umbrah]

Het wisselt ook wel eens per game, en er zijn ook mensen die meer doen dan gamen. Sommigen hebben op hun tweede scherm netflix er naast (handig als ze over beurten nadenken), sommigen multiboxen, anderen streamen weer, en anderen spelen games met 800+ AI-gestuurde agents die een dergelijke werkset hebben dat ze niet in de GPU passen.

[computerjunky]

Dat zal je ook nooit zien omdat microsoft deze load spread over de cores qua weergave en dus geen accuraat beeld geven.

Zo gfeeft een game op 4 cores nooit meer een load als 50% totale cpu load plus een paar % overhead op een 8 threadded cpuvoor windows enz. en een 2 core game zal je niet boven de 25% plus wat overhead zien gaan op een 8 thread an 50% op een cpu als de i5 4 core no ht.

Dit is precies waarom mensen al tig jaar denken dat hun cpu helemaal geen bottleneck is maar het in werkelijkheid soms wel is.
Je 6700k is voor een 1070 waarschijnlijk al een bottleneck op stock specs. mijn 3770k op 4.6 ghz is het namelijk ook al voor mijn 1070 hij is echter alleen niet long term stabiel op 4.7 en ik moet dan ook upgraden. Hangt ook af van de game natuurlijk sommige zijn heel erg cpu afhankelijk en andere helemaal niet.

[Rataplan_]

Geen idee, maar kan je in geval van windows niet doen op basis van cpu affinity van een proces? Daar zijn toch al legio tooltjes voor om dat automatisch te regelen?

[tapkcir]

Software voor CPU? Software = bugs.

[blorf]

Inderdaad twijfelachtig. Wat software doet kan hardware in alle gevallen sneller. Maar het kan wel achteraf aangepast worden. Daaruit zijn bepaalde negatieve conclusies te trekken in m.b.t. de consistentie van de hardware. Is het wel af?

[hans3702]

Ik denk dat je juist blij moet zijn met deze software, waardoor er op een CPU correcties mogelijk zijn.
Ook Intel heeft zo iets en dit is de microcode die in de (intel) bios zit en die via windows 10 na geladen kan worden. Hierbij is het dus oa mogelijk om de lekken in het CPU ontwerp te fixen. Of zoals nu bij deze AMD WX de werking te optimaliseren voor een specifieke workload.

En Microcode wordt vooral gebruikt in processors die veel en complexe instructies hebben (CISC-processors). Het decoderen en uitvoeren van instructies is bij deze processors te complex om in de hardware te implementeren.

Bron: https://nl.wikipedia.org/wiki/Microcode

[hamsteg]

En hoe denk je dat de CPU draait dan? Ook in chip zit gewoon software. Afhankelijk van de processor is dit firmware of bij goedkope mass-volume units is dit in chip ingebakken als "hardware code".

[Zwartoog]

Mwah, hardware kan net zo goed hoor:
https://en.wikipedia.org/wiki/Pentium_FDIV_bug

[SCS2]

Begrijp ik het goed, als ik denk dat AMD kan optimaliseren omdat zij beter weten welke cores het beste tegelijk kunnen draaien?
- bijv. beter ruimtelijk verdeeld, zodat de warmte beter wordt verspreid en hogere clock mogelijk is.
- of welke core kwa verbinding logisch dichter bij elkaar staan en beter samen kunnen werken?
bijv. door dezelfde cache te gebruiken.

Zijn alle aangeboden threads gelijk?
Geven programma's door wat beter op een aparte kern kan draaien, of het bijv. een zware berekening wordt?
De AMD scheduler(?) moet toch ook info hebben om een goede beslissing te nemen?