Waarom topt de ene app op ~40% en de andere 100% cpu?

[Sando]

Alles wat tijd kost duurt te lang. Maar sommige dingen duren nu eenmaal lang. Dat is prima als je het gevoel hebt dat je megasnelle computer keihard voor je aan het werk is.

Ik heb dit bij zowel Win7 Pro 64 als XP 64 op mijn quad core Q6700 met 4GB geheugen.

Hier is wat goed voelt:
Renderen in 3d Studio Max: 100%
Renderen in Blender (32bit): 100%

Hier is wat fout voelt:
Renderen in After Effects: ~40%
x264 avc encoden: ~40%

Mijn CPU usage gadget zegt dat alle cores evenveel belast worden, dus het is niet zo dat die laatste voorbeelden te antiek zijn om alle cores te gebruiken.

Ik heb al geprobeert met Taskmanager en Process Explorer de priority te verhogen, maar er verandert amper wat.

Wie houdt wie voor de gek en wordt mijn processor nu echt zo onefficient gebruikt door de helft van mijn software?

[Twazerty]

Volgens mij is het eerder dat de app niet volledig gebruikt maakt van de cpu.

x264 loopt in pass1 hier ook maar op 60-70% maar pass2 hoppa naar de 100%

[Sando]

Waarom? Grapje van de programmeur? Als je de hele processor wilt gebruiken moet je een bribe sturen?

Want uitgaande van die percentages zou mijn traag updatende AE scène in theorie twee keer zo snel kunnen updaten. Dan zou die x264 pass 1 zo'n 43 - 67% sneller kunnen!

[rockmanz]

Er zijn meerdere factoren die meespelen in (mogelijk haalbare) snelheid. Denk hierbij aan gpu, geheugen, doorvoersnelheden maar ook inderdaad de cpu. In jouw voorbeelden denk ik dat het te maken heeft met harddisk doorvoersnelheden. De cpu zal vast 80mb/s kunnen verwerken maar als je harddisk maar 30 aankan (vergeet niet dat er zowel read als write plaatsvind), tja dan heeft het weinig zin om je cpu vol te belasten. Misschien eens handig om hiernaar te kijken?

[Sando]

Dat is een goed punt. Toch denk ik dat het in dit geval niet de harde schijf is.

Een AE scène zit compleet in het geheugen wanneer die voor de helft van de kracht gaat rekenen. Ik heb hier (in het ergste geval) een HD video van 5 minuten wat 6 GB aan lagarith data is welke nog geen 20 MB per seconde hoeft te lezen (6000/320) en in dit geval encode ik naar een andere schijf en toch doet x264 langzaam. Als ik een mp4 omzet naar mp4 dan zou ie maar 3 MB per seconde lezen en juist de processor belasten met nog meer decoden.

Zowel AE (CS3 iig) als x264 gebruiken de GPU niet. Mijn geheugen zit niet vol en volgens mij wordt er ook niet geswapt. De harde schijven geven ongeveer elke seconde een pruttel met afentoe een uitzondering, klinkt alsof ze 8/10e van de tijd 'niets te doen hebben'.

-edit-

Geluid AAC encoden: 20-25 %
En 1-pas VBR encoden avc: 60 - 75%.
Ik encode een filmpje van 300 MB voor mijn telefoon naar een bitrate van 0,6MBit/s. Dat is dus zeker niet mijn harde schijf, die nu eens in de 5 seconden pruttel zegt.

[ Voor 13% gewijzigd door Sando op 16-11-2009 18:12 ]

[DigiK-oz]

In een ideale wereld haalt de software de input in het geheel van disk naar het geheugen, en is er plaats in het geugen voor de output. Dan kan het programma 100% aan het werk, en aan het einde de output naar disk schrijven. Jij happy.

In de echte wereld reserveert een programmeur een "redelijke" hoeveelheid geheugen als buffer, zowel input als output. Leest de inputbuffer, processed die, en schrijft de outputbuffer. Als de buffer relatief klein is, kan het best zo zijn dat het lezen van de input 1/4 seconde duurt, het schrijven van de output ook. Zeker als de schijf gefragmenteerd is en er dus veel seeks plaatsvinden. Gevolg : 50% cpu, jij niet happy.

Een programmeur kan, zeker in een multi-tsaking OS, niet gewoon alle geheugen inpikken. Dan is er niks over voor andere (background)applicaties, en krijg je paging. Wat ook weer tot gevolg heeft dat er i/o plaatsvindt, en dus je CPU niet op 100% komt.

De applicaties die je CPU wél op 100% krijgen, hebben vrijwel zeker (veel) grotere buffers dan die andere, en dat is prima als er weinig anders naast draait. Maar dat is dus een afweging die de programmeur maakt, en het is zeker niet dom om hier wat conservatief mee om te gaan, tenzij je wéét dat je programma vrijwel altijd als enige draait.

Je zegt zelf al, het lijkt alsof de schijf 80% niks doet. Dan doet hij dus 20% wel wat, en heb je al 20% van je "verlies" verklaard. Input en output beide 20%? Dan is 40% al duidelijk toch?

Misschien dat in de programma's een optie zit om de grootte van de buffer in te stellen, zodat je met veel geheugen dit wat hoger kan zetten? Daarnaast, als het ene programma eerst 5 seconden disk leest, dan 2 seconden 100% cpu geeft, en dan weer 5 seconden schrijft, zie jij 100% CPU. Als het andere programma 12 seconden 40% CPU geeft en ondertussen leest, zijn ze tegelijk klaar. Welke is dan in jouw ogen efficiënt?

[Sando]

Duidelijk verhaal, maar dat heeft er in dit geval volgens mij echt niet mee te maken. De genoemde voorbeelden, mits niet belachelijk grote ongecomprimeerde bestanden opgegeven, hebben gewoon haast geen IO maar zijn juist zeer processor-intensief.

Ingewikkelde AE Scene, compleet in geheugen, rendert 1 minuut per frame. Er is dan amper hd activiteit, maar toch slechts 45% cpu.
x264 x86 rendert een uur van 300mb naar 200mb in 12 minuten met slechts 65%.
Andere 32bit apps, die ook processor intensief zijn, 3d studio x86 en Blender x86, renderen allebei tegen de 100%.

Terwijl ik dit tiep heb ik iets nieuws ontdekt: Als ik een pipe gebruik om ondanks mijn 32 bit avisynth toch de 64 bit x264 encoder te kunnen gebruiken, dan gaat ie bijna 2 keer zo snel, in 6 minuten klaar en 96% cpu!

Voor de ene app maakt het wel snelheidswinst en voor de andere niet? (32 vs 64 bit) Dat zou toch niet uit moeten maken.

[alt-92]

Sando schreef op dinsdag 17 november 2009 @ 02:23:

Voor de ene app maakt het wel snelheidswinst en voor de andere niet? (32 vs 64 bit) Dat zou toch niet uit moeten maken.

Ligt eraan of ie met multicore compiled is, en zo nee zal dat ook wel een reden hebben.
(64bit meer future proof, een 32bits versie die voor legacy redenen nog wordt gehanteerd moet rekening houden met oudere singlecore hardware).

[Sando]

Zijn er ook monitors of tools die kijken waar de bottleneck ligt?

Check het ge-heen-en-weer van mijn cores als ik met After Effects begin met renderen.
Deze render duurt ongeveer 16 uur, dus je kunt je voorstellen dat ik die lijntjes graag helemaal bovenaan zie. In theorie zou de snelheid bijna kunnen verdubbelen.


(idle + eerste piek = project openen + render beginnen)

[Tsurany]

Ligt voornamelijk aan de efficiëntie van het programma. Is hij wel in staat alle cores volledig te belasten? Iets kan wel multicore zijn maar als er alsnog flink wat afhankelijkheden zitten bij het rekenen of de data niet snel genoeg beschikbaar is dan blijf je met het probleem zitten. Technisch is het mogelijk, om het te programmeren is lastig.

Vaak ga je voor 32bits versie niet de code gigantisch omgooien zodat hij de volledige CPU kracht gaat gebruiken en doe je dat voor 64bit wel want daar zit toch al voor een groot deel andere code achter en daar ga je in de toekomst toch mee verder.

[Twazerty]

En bij Core i7's is het nog erger. Daar heb je 8 virtuele cores die je programma moet vullen. Zoals bekend levert HyperThreading niet altijd een performance winst maar vaak ook een verslechtering van performance. x264 met de juiste instellingen in de 2e pass legt mijn cpu helemaal lam. Gewoon 100% op 8 virtuele cores.

[Giant87]

AE CS5 gaat wel doen wat jij verlangt 64-bits only.

[Herko_ter_Horst]

Het zou best eens kunnen dat niet HD access, maar geheugen access de verklaring is voor dit CPU-gebruik.

Bij een 3D render wordt de CPU wel volledig belast, omdat er relatief weinig geheugenactiviteit plaatsvindt, maar wel veel rekenwerk. Bij een filmrender worden er veel grotere hoeveelheden data verstouwd, schat ik in.

[ Voor 5% gewijzigd door Herko_ter_Horst op 20-11-2009 18:55 ]

[Sando]

Twazerty schreef op vrijdag 20 november 2009 @ 18:46:
x264 met de juiste instellingen in de 2e pass legt mijn cpu helemaal lam. Gewoon 100% op 8 virtuele cores.

Gaaf, zo mag ik het zien! Bij mij helaas niet, wel een verbetering ten opzichte van 32bit, maar niet 100%.

Giant87 schreef op vrijdag 20 november 2009 @ 18:53:
AE CS5 gaat wel doen wat jij verlangt 64-bits only.

Ik denk dat ik die volgend jaar ga kopen of nog even tot CS6 wacht ivm licentiekosten. Ik ook zo mooi CS3 gekocht 2 maanden voor de release van CS4..

Herko_ter_Horst schreef op vrijdag 20 november 2009 @ 18:54:
Het zou best eens kunnen dat niet HD access, maar geheugen access de verklaring is voor dit CPU-gebruik.

Zou goed kunnen wat je zegt. Maar die render van 16 uur duurt anderhalf uur als ik al mijn lightwrap weghaal en precomps in de zelfde comp laat renderen.. er zit ergens duidelijk een dikke bottleneck in After Effects en ik zou graag willen zien waar het zit. Maar dat is wel erg offtopic denk ik. En een beetje onmogelijk in AE geloof ik.

[Sando]

Ik zat weer te denken aan een soortgelijk probleem, en ik had zo een dejavu gevoel dat ik half internet ging afzoeken om te zien of ik hier niet eerder over begonnen was. Uiteindelijk in het nederlands gezocht, blijkt dat dit gewoon hier op tweakers was..

Anyway, hoewel oud, is dit topic precies waar het over gaat. Het is ook nog eens mijn eigen topic, dus ik dacht dat ik hier wel even gewoon opnieuw kon posten.

Nu heb ik een aantal video's die ik even wilde omzetten naar MPEG2 ivm goede oude DVD's, en ik zat me weer te irriteren aan een trage encode (ffmpeg). Dus wat doet een goed Christen met 4 cores en genoeg geheugen, gewoon twee encodes tegelijk (ffmpeg+ffmpeg). Wordt er nog steeds niet hard genoeg gewerkt? Drie encodes! (ffmpeg+ffmpeg+hcenc) Nog steeds niet? Ik kan gewoon nog een HD-film op de achtergrond kijken, er zijn clockcycles genoeg over.

Vervolgens start ik Adobe Media Encoder erbij en start de 4e encode. Volgens mij gebruikt Adobe een MainConcept encoder voor MPEG2 (ffmpeg+ffmpeg+hcenc+mainconcept). En dan opeens stijgt de CPU usage van 30% naar 100%! Ik kan nu niet veel meer doen, de muis gaat schokkerig en browsen traag. Nu weet ik tenminste dat mijn computer bezig is.

Alle 4 encoders halen hun spul van hetzelfde (RAID)volume. Volgens mij is alleen hcenc 32 bit. Hier klopt volgens mij iets niet, en na 2 jaar kan ik nu niet meer zonder zorgen naar dromeland.

3 encodes
4e encode unpaused (check the cpu-meter, halverwege zet ik 'm aan)

[Herko_ter_Horst]

offtopic:
Je links doen het niet

Of moderne multi-core CPU's volledig gebruikt worden hangt af van twee dingen:
- kunnen (delen van) taken die de software wil uitvoeren in parallel gedaan worden én is de software ook geschreven om dit op meerdere threads te doen?
- kan de rest van het systeem (m.n. geheugen en disks) voldoende snel de informatie aanleveren waar mee gewerkt moet worden?

Als jij ziet dat met het ene programma maar 30% gebruikt wordt en met een ander programma 100%, kunnen er een aantal zaken aan de hand zijn:
- het eerste programma maakt geen gebruik van multi-threading (daar kun je van uit gaan als al het CPU gebruik op 1 core zit), het tweede wel
- het eerste programma is zó efficiënt dat de rest van het systeem het niet bij kan benen, het tweede is niet zo efficient

[Sando]

Maar zouden 3 singlethreaded programma's dan niet 3 cores vol moeten trekken?

offtopic:
Hoe moest dat ookalweer, links vanaf dropbox plaatsen... of hebben ze die feature verwijderd?

Misschien werken deze:
Link 1
Link 2

[ Voor 37% gewijzigd door Sando op 05-04-2012 14:00 ]