Performance interactie tussen cores en GPU op een i7 (4770K)

[Specy]

Ik ben bezig met een audio-programma dat moet gaan draaien op een i7 4770K processor met DDR3 1600 geheugen. Ik loop tegen een probleem aan met een mij nog onbekende, over de CPU cores gedeelde resource die de performance van andere cores beinvloed als ik op 1 core iets zwaars ga draaien.

Situatie:

• OS: Windows 7, 32 bit
• Cores 0+1: Leeg
• Cores 2+3: Audioprocessing (HyperThreading gebruikmakend van gedeelde memory cache)
• Cores 4+5: Audioprocessing (HyperThreading gebruikmakend van gedeelde memory cache)
• Cores 6+7: Chrome voor de GUI, webserver (onderdeel van mijn eigen proces), WDM (Windows Device Manager).

Nu gebeuren er wat vreemde dingen die ik niet goed kan verklaren.

• Chrome met een leeg scherm: Ik kan mijn processing draaien met een extra latency van iets boven de 1 ms bovenop wat ik nodig heb voor processing (3.4 ms). Totale latency 5 ms.
• Chrome waarin ik via JavaScript in canvassen teken (1920x1080 scherm volledig gevuld met 60 fps, CPU load op core 7 tegen de 100%): Als de CPU load op cores 2,3,4,5 laag is werkt alles prima, als die hoger wordt (rond de 50%) moet ik mijn extra latency verhogen naar 3 ms.
• Animaties in Chrome via GPU, of wijzigen van de size van meerdere canvassen: Dit geeft ongeacht de CPU load op cores 2,3,4,5 grote hiccups in de audio. Zelfs 10 ms extra latency helpt weinig.
• Animaties in Chrome zonder GPU: Minder problematisch dan met GPU, maar nog steeds veel meer latency nodig dan tijdens het tekenen waarbij de CPU load al tegen de 100% aan zit.

Daarbij zie ik op cores 2 en 4 dat de gerapporteerde CPU load in TaskManager flink stijgt tijdens animaties. Zet ik mijn eigen software uit dan is op die cores de CPU load 0%, ook tijdens animaties.

DPC timings lijken goed (tot zo'n 130 us, geen uitschieters te zien op het moment dat de audio hakkelt).


Ik kan nu een hoop dingen gaan testen (ik wil o.a. gaan kijken wat er gebeurt als ik op core 6/7 iets draai wat grote blokken geheugen kopieert om te kijken of de memory bandwidth het probleem is), maar mocht iemand hier dit probleem kennen en weten of vermoeden wat de oorzaak kan zijn dan zou dat mij flink kunnen helpen.

De GPU zit overigens in de processor, dat kon wel eens relevant zijn...

[farlane]

Kan het iets met het frequentiethrottling te maken hebben waardoor sommige cores naar een lagere snelheid worden gezet als je met Chrome een core voltrekt?
In any event, Windows is niet realtime enzo maar dat zul je vaker hebben gehoord.

[Specy]

Ik heb een monitorprogramma gedraaid om te zien wat er gebeurt met de snelheid per core en die verandert niet. Dus dat is het 'm niet.

Dat tweede weet ik uiteraard, punt is dat zonder Chrome het gewoon goed draait dus als ik erachter kom wat Chrome uitspookt waardoor de overige cores in de problemen komen (ik gok op geheugen...) het vast op te lossen is.

[farlane]

Is het Chrome die die processortijd gebruikt of zijn het kernel (drivers) die het doen? Daarnaast, als Chrome het kan kunnen andere applicaties het ook ( maar ik geloof dat je daar (semi)controle over hebt? )

Met een beetje pech blijf je hier tegenaanlopen; heb je er nu omheen gewerkt kan het met een update zomaar weer anders worden : Het blijft een beetje pleisters plakken.

[Caelorum]

Kan best zijn dat de gfx driver een extra thread/core er bij pakt en zo de rest dwars gaat zitten.

[PrisonerOfPain]

De enige manier dat je hier echt achter gaat komen is door je hele systeem te profilen met xperf. Het is een vrij harige tool overigens, maar ik denk dat je niet veel andere opties hebt

[Specy]

@farlane: Zover ik kan zien neemt niemand de processortijd in beslag maar wordt de code die draait trager. Als ik niets draai op cores 2-5 en dezelfde animaties in Chrome gebruik is er alleen CPU load op cores 6 en 7, wat klopt met de ingestelde affiniteit.

@Caelorum: Ik ben er dus vrij zeker van dat het dat niet is.

@PrisonerOfPain: Ah, die kende ik niet! Heb net wat gelezen en het klinkt alsof ik hiermee verder moet kunnen komen. Als alternatief zat ik aan VTune te denken, maar dir programma lijkt voor de issues waar ik mee zit beter geschikt.

[PrisonerOfPain]

Specy schreef op zondag 30 maart 2014 @ 03:31:
@PrisonerOfPain: Ah, die kende ik niet! Heb net wat gelezen en het klinkt alsof ik hiermee verder moet kunnen komen. Als alternatief zat ik aan VTune te denken, maar dir programma lijkt voor de issues waar ik mee zit beter geschikt.

xperf is meer voor problemen die het hele systeem betrekken, vtune is voor een process tegelijk

[Specy]

PrisonerOfPain schreef op zondag 30 maart 2014 @ 16:01:
[...]


xperf is meer voor problemen die het hele systeem betrekken, vtune is voor een process tegelijk

Ik gok dat ik ze beide moet gaan gebruiken. Met xperf uitzoeken wat er in grote lijnen gebeurt en indien nodig met vtune vinden waar in mijn eigen code ik resources gebruik die soms niet beschikbaar of traag zijn. Ideaal zou zijn als ik daar omheen kan werken *en* in de browser het gebruik van die resources kan verminderen.

[Gomez12]

Sidenote : Persoonlijk zou ik nooit Chrome (of een andere auto-updatend iets) gaan gebruiken op een tijdskritische server.

Als het team van Chrome morgen besluit om een wijziging door te voeren die performance kost, maar voor de gebruiker beter overkomt, dan ben jij bij de volgende reboot de lul, want jouw audio-progje krijgt dan niet meer de gewenste performance.

[EfBe]

klinkt als memory bottleneck of cache flush door context switching op een core omdat de GPU oriented code op core 2-3 wat gaat doen (het zijn tenslotte threads, en de threads die de GPU driver opstart kun jij niet op een core pinpointen). Memory bottleneck kan komen omdat je code erg memory intensief is en wanneer daar een andere memory intensieve thread bijkomt de weg naar de processor te traag wordt en deze dus gaat wachten op IO. Dit is niet zo snel het geval overigens, maar ik weet niet hoeveel memory (MB/s) jouw code minimaal nodig heeft om binnen de latency te blijven.

[Specy]

en de threads die de GPU driver opstart kun jij niet op een core pinpointen

Hm, dat zou veel kunnen verklaren. Mijn code zou niet zo veel memory moeten gebruiken, en ik verwachtte eigenlijk dat het in de cache zou blijven zitten. Maar het valt wel op dat, bij gebruik van core 2+3 en 4+5, de cores die meestal als eerste al het geheugen accessen (2 en 4) een spike geven in CPU gebruik, en de andere 2 (3 en 5) niet.

[PrisonerOfPain]

EfBe schreef op maandag 31 maart 2014 @ 10:03:
klinkt als memory bottleneck of cache flush door context switching op een core omdat de GPU oriented code op core 2-3 wat gaat doen (het zijn tenslotte threads, en de threads die de GPU driver opstart kun jij niet op een core pinpointen).

Wat een onzin, er heeft nog niemand iets concreets geprofiled en jij komt al met suggesties aan? Verder cost een cache-flush niet iets in de orde van milliseconde groot, maar goed.

[ytterx]

Uhm ik zie dat je Windows 7 32 bit draait? Zit je geheugen niet vol? (3.5 GB max voor windows 32bit)
Je geheugen kan nog zo snel zijn maar als het vol zit gaat Windows gewoon swappen en dat is altijd traag.

[Neverwinterx]

Ben toch benieuwd of de oorzaak niet is dat die GPU embedded is in de CPU en daardoor indirect de CPU ook belast door memory sharing e.d. Kan je er een aparte GPU insteken en zorgen dat Chrome die aparte GPU gebruikt) en kijken of je nog altijd hetzelfde effect ziet?

[Specy]

Neverwinterx schreef op maandag 31 maart 2014 @ 20:03:
Ben toch benieuwd of de oorzaak niet is dat die GPU embedded is in de CPU en daardoor indirect de CPU ook belast door memory sharing e.d. Kan je er een aparte GPU insteken en zorgen dat Chrome die aparte GPU gebruikt) en kijken of je nog altijd hetzelfde effect ziet?

Ik moet nog gaan profilen (er is wat anders tussendoor gekomen vandaag), maar dit zou heel goed kunnen. We hebben in Chrome de GPU (hardware acceleration) uitgeschakeld en dat lijkt wel te schelen.

Ik heb ook wat andere code klaarstaan die grote blokken geheugen kopieert om te kijken of dat een vergelijkbaar probleem veroorzaakt.

[Specy]

ytterx schreef op maandag 31 maart 2014 @ 19:10:
Uhm ik zie dat je Windows 7 32 bit draait? Zit je geheugen niet vol? (3.5 GB max voor windows 32bit)
Je geheugen kan nog zo snel zijn maar als het vol zit gaat Windows gewoon swappen en dat is altijd traag.

Nee, meer dan de helft is nog vrij en dat zou ook een heel ander soort effecten opleveren. Overigens valt wel op dat swipen in de GUI voor oplopend en dan plotseling weer droppend geheugengebruik zorgt (zo'n 16 MB verschil) dus daar zit wel iets niet lekker.

[Specy]

Nog steeds geen tijd gehad om te profilen, maar ik heb even snel een stukje code geschreven wat op een core die verder niet in gebruik is een groot blok geheugen continu kopieert, en de performance van de andere cores viel direct in elkaar. Dus dat lijkt het wel te zijn (wellicht is het niet het enige, maar geheugenbandbreedte is zeker een bottleneck).

Overigens had ik dat - gezien hoe mijn code werkt - niet verwacht, dus ik vermoed dat er iets mis gaat met caching (bijv. veelvouden van 64 kB die niet tegelijk in de cache kunnen zitten).

[farlane]

Begrijp ik nu trouwens goed dat je van het UI in .NET bent afgestapt, maar dat je het nu in de browser doet? Had je daar een betere performance verwacht dan van een .NET UI? ( Uit dit Real-time applicatie en .NET GUI: Gaat dat goed? draadje zeg maar )

Native is zo veel vetter

[ Voor 18% gewijzigd door farlane op 01-04-2014 23:38 ]

[Specy]

farlane schreef op dinsdag 01 april 2014 @ 23:37:
Begrijp ik nu trouwens goed dat je van het UI in .NET bent afgestapt, maar dat je het nu in de browser doet? Had je daar een betere performance verwacht dan van een .NET UI? ( Uit dit Real-time applicatie en .NET GUI: Gaat dat goed? draadje zeg maar )

Native is zo veel vetter

Ik had sowieso ook een remote interface nodig die op veel verschillende devices kon draaien, dus ik dacht laat ik dit eerst eens uitproberen - met als fallback-screnario een C++ interface, en HTML5 voor remote clients. Die .NET interface zou alleen voor op het apparaat zelf gebruikt worden en op andere Windows-systemen, de HTML5-variant draait op vrijwel alles. Overigens lijkt de CPU load helemaal geen issue te zijn: Als ik in de browser alles teken, wat trouwens in JavaScript met per-pixel manipulatie met lookup tables voor fading-effecten nog full-screen lukt met 60 fps op een 1920x1080 scherm, dan kan ik de CPU load tot tegen de 100% opkrikken vrijwel zonder dat de audio gaat hakkelen (ik heb 2 ms extra latency nodig). Maar met een stukje C++ code dat geheugen kopieert gaat het volledig mis en kan de processing de inkomende data niet eens meer bijhouden.

[MSalters]

EfBe schreef op maandag 31 maart 2014 @ 10:03:
klinkt als memory bottleneck of cache flush door context switching op een core omdat de GPU oriented code op core 2-3 wat gaat doen (het zijn tenslotte threads, en de threads die de GPU driver opstart kun jij niet op een core pinpointen).

Niet expliciet, maar omdat cores 0 en 1 idle zijn terwijl 2 en 3 dat niet zijn zou het me hogelijk verbazen als Windows die GPU threads op cores 2 en 3 zou pinnen. Uberhaupt zo het me verbazen als iemand die threads zou pinnen. Mijn verwachting is dat de GPU threads op cores 0 en 1 draaien omdat die beschikbaar zijn.