Nieuw systeem. CPU wordt onvolledig gebruikt.

[CaptJackSparrow]

Ik heb eerder dit jaar een nieuw systeem gebouwd van:

pricewatch: Gigabyte GA-A75M-UD2H
pricewatch: AMD A8-3870K Black Edition
pricewatch: Corsair Vengeance CMZ8GX3M2A1866C9B (2x4GB dual-channel)

Een quad-core op 3GHz moet een redelijke prestatie kunnen leveren en vergeleken met het oude systeem verwacht ik dat dan ook goed te merken.

Het rare is echter dat als ik bijv. een foto bewerk of met WinRAR iets inpak er maar iets van 30-40% van de CPU gebruikt wordt volgens de grafieken in taakbeheer. Zelfs niet één core wordt vol belast. Soms wordt wel één core wat hoger belast maar nooit 100%.

Het zijn operaties waarbij slechts weinig HD activiteit plaatsvindt (HD-ledje gaat niet fel branden) en dat kan de bottleneck dan ook niet zijn. Het geheugen is 1866 DDR3 en ik kan me dan ook niet voorstellen dat daar een doorvoercapaciteitsprobleem zou zijn.

Met Prime95 gaan wel alle 4 de cores probleemloos naar 100%.

Laatste chipset en andere drivers. Geen gekke dingen in apparaatbeheer. BIOS staat volgens mij goed. Alle POST meldingen zijn in orde,

De enige term waarmee ik er met Google iets over vind is 'underutilize' maar dan steeds met specifieke niet gangbare toepassingen lijkt het. Ook niet met oplossingen. Met andere zoektermen kom je bijna altijd uit bij het probleem van 100% CPU load hebben terwijl dat juist niet moet.

Dit is een vreemd en onverwacht probleem. Weet iemand hier meer over?

[Fordox]

je hardeschijf is wel degelijk een bottleneck.
deze moet eerst naar de positie toe, de data lezen en dan nog doorgeven. als je een ssd hebt zie je ook wel dat je processor belasting omhoog gaat.

daanaast heb je intern nog andere databussen, zoals je ht link en je NB. het zijn allemaal kleine dingetjes die ervoor zorgen dat je processor niet 100% word gebruikt.

prime95 word wel 100%gebruikt gezien dit geen random data is. dit is allemaal data die achterelkaar staat en dus snel uitgelezen word, en meestal ook net in de cache van je cpu past waardoor dit gelijk toegepast kan worden zonder memory/interface/hdd bottlenecks.

het ligt dus net aan je applicatie en andere hardware hoe snel je systeem van data voorzien kan worden om te berekenen. schaf eerst een ssd aan en je ziet duidelijke verschillen.

wat je kunt doen is je NB en je HTT multipliers omhoog afstellen in de bios om het net iets sneller te krijgen, maar om echt de bottleneck eruit te halen moet je strict werken met ssd's en al je hdd's weg doen. dan heb je nog steeds vast wel ergens een bottleneck (kan ook aan de ssd liggen, dus haal een goed snelle of zet er 2 in raid 0) en komt je cpu praktisch nooit op 100%.

ik heb zelf hetzelfde geheugen als jou, ook een hardeschijf, maar dan een fx-8150 op de 990fx chipset en ik heb mijn processor in normaal gebruik niet hoger gezien als 40%. dit komt echt puur om mijn hardeschijf, als ik deze vervang kom ik misschien een keer richting de 80%.

wat ook niet slecht is om te weten, is dat sommige applicaties geen multicores ondersteunen. dus zet je taakbeheer ernaast en je ziet dat niet elke core precies even zwaar word gebruikt (kan verschillen tussen de 90% load en 3% load). het is dus maar net hoe goed de OS en de applicatie de ondersteuning hebben voor jou processor en chipset. hieronder valt dus ook dat je je chipset drivers altijd up-to-date moet hebben.

hierbij heb ik denk ik alles wel behandeld dat je moet weten
kortom, interne bussen overklokken, een ssd aanschaffen, de goede applicaties en drivers gebruiken en je ziet je processor gebruik wel omhoog gaan

[C.Hariri]

Winrar, en fotobewerken in mindere mate, is erg afhankelijk van hoe snel je data van en naar je hardeschijf kunt halen. Denk dat er iets mis is met je hdd lampje . In linux hebben we gelukkig een HDD meter (iops), netzoals je een CPU metertje hebt dat aangeeft hoeveel % die belast is.

[ Voor 26% gewijzigd door C.Hariri op 08-04-2012 23:30 ]

[CaptJackSparrow]

De harde schijf kan natuurlijk EEN bottleneck zijn bij bepaalde operaties maar als ik bijv. ruis uit een foto laat halen met Neat Image dan hoeft daarbij geen (significante) schijf I/O te worden gedaan. Dat heb ik dan ook gecheckt met Sysinternals File Monitor. Daar helpt een SSD niet bij. Ook bij WinRAR kun je schijf-I/O minder belangrijk maken door de compressie op maximaal te zetten. Als schijf-I/O de bottleneck zou zijn mag je ook verwachten het ledje fel te zien branden (wat het ook inderdaad doet als de schijf in andere situaties wel flink belast wordt) maar dat doet het dus niet.

Op mijn oude systeem zat de single core bij dergelijke operaties dan ook op de 100% maar bij deze gaat zelfs niet één core naar 100%. Ik snap/weet dat een applicatie geen multipele cores kan ondersteunen maar dan zou ik toch wel verwachten om één core vol belast te zien worden maar ook dat niet.

Prime95 geeft 100% op alle cores met alle drie de testen. Ook de 'Blend' test die veel RAM test. Daaruit leid ik af dat het met die geheugendoorvoer waarschijnlijk toch ook wel goed zal zitten.

[redfoxert]

Hou je er rekening mee dat er bijna geen "normale" huis-tuin-keuken software is die geoptimaliseerd is voor het gebruiken van meerdere cores?

[CaptJackSparrow]

Ja. Dat heb ik al aangegeven. Als er maar één core vol gebruikt zou worden zou ik al 'tevreden' zijn.

[NSG]

4 cores op 25% of 1 enkele op 100%, wat boeit dat nou ?

[weebl15]

Windows kan een single threaded applicatie ook verdelen over meerdere cores. Bij mijn dual core laptop heb ik bijvoorbeeld dat als ik een programma start dat 100% CPU vreet (zelf geprogrammeerd programma), dat deze dan beide cores met 50% belast.

[ Voor 3% gewijzigd door weebl15 op 08-04-2012 23:43 ]

[3dfx]

Anders test je toch gewoon met bijvoorbeeld 1 core om te kijken wat er dan gebeurt?

Dat kan je instellen m.b.v. MSCONFIG:
-klik op Start>uitvoeren, type 'msconfig', gevolgd door enter.

Dan op tabblad 'computer opstarten' de knop 'geavanceerde opties' aanklikken en in dat scherm aangeven hoeveel processoren je wilt gebruiken, en reboot.

[weebl15]

Desnoods affiniteit van je applicatie instellen dat hij maar een core gebruikt. Dit kan in Windows taakbeheer.

[ Voor 24% gewijzigd door weebl15 op 08-04-2012 23:51 ]

[Fordox]

Zoals ik al zei, het is maar net hoe je hardware ondersteund wordt en dat de interne databussen ook een rol spelen. Dit heb ik allemaal ook al uitgebreid behandeld in mijn lap tekst
Maar ondersteuning van de hardware bedoel ik ook op de manier hoe de programmas worden verdeeld om te berekenen. Dit ligt aan windows en aan je drivers.

Volgens mij moet alles nu wel duidelijk zijn toch?

[CaptJackSparrow]

weebl15 schreef op zondag 08 april 2012 @ 23:50:
Desnoods affiniteit van je applicatie instellen dat hij maar een core gebruikt. Dit kan in Windows taakbeheer.

Die affinity is inderdaad interessant. Als ik met Irfanview bijv. een Auto Adjust Colours laat verrichten wat puur in het geheugen moet kunnen plaatsvinden dan is dat met gebruik van één core, geforceerd met de affinity, in iets van 6 seconden gebeurd en gaat die core ook naar 100%. Laat ik twee cores gebruiken dan gaan die beide lang niet naar 100% en duurt het 9-10 seconden.

Met WinRAR hetzelfde. Een directory met foto's laten inpakken geeft kort na het starten met 1 core een verwachte tijdsduur van 2:18 met de core tegen de 100% en met 2 cores 4:40.

Wonderlijk dat de interne 'load-balancing' mechanismen van Windows hier contraproductief lijken te werken.

[CaptJackSparrow]

Zo te zien koppel ik met die affiniteit een proces vast aan een absoluut core-nummer. Dat zou niet handig zijn want dan ben je niet efficiënt bezig zodra je twee CPU-intensieve processen opstart die je (ooit? - wordt dat permanent onthouden?) aan dezelfde core gekoppeld zou hebben. Ik had verwacht dat applicaties die niet ontworpen zijn voor meerdere cores gewoon door Windows aan een enkele core zouden worden toegewezen maar dat verschillende processen automatisch toegekend zouden worden aan 'vrije'/laag belaste cores om een zo efficiënt mogelijk gebruik te maken van alle cores als er meerdere processen tegelijk actief zijn. Dat lijkt mij de meest logische manier om met single-core processen om te gaan in een multi-core systeem.

Ik maak me toch sterk dat er een manier moet zijn om dat zo geregeld te kunnen krijgen. Daar moeten toch allang oplossingen voor gevonden zijn? Er moet toch een utility te maken zijn die dat automatisch doet?

Weet iemand of die er zijn en waar die te vinden zijn of dat dit een extra insteloptie van Windows is?

[Verwijderd]

imagecfg -u ...

en als je dat tooltje niet meer kunt vinden, is Application Compatibility Toolkit ook een mogelijkheid

[CaptJackSparrow]

Wat ik er van lees lijkt dat imagecfg tooltje processen ook statisch aan een absoluut core-nummer te koppelen. Dat zoek ik niet. Ik wil dat processen automatisch aan een enkele core toegewezen worden maar dat dit elk van de vier cores kan zijn afhankelijk van welke core het minst belast is bijvoorbeeld. Meer dynamisch dus en veel efficiënter.

En met die Application Compatibility Toolkit moet je voor elke applicatie apart definiëren dat die maar 1 core mag gebruiken? En is dat dan wel dynamisch over alle cores of ook statisch aan een vaste core gekoppeld?

Ik ben werkelijk verbijsterd dat dit zo slecht geregeld lijkt te zijn.

Ik had verwacht dat (single core) processen automatisch efficiënt en dynamisch aan individuele cores toegewezen zouden worden. Ik zou verwachten dat multi-core-capable processen zich als zodanig aan het OS zouden kunnen presenteren zodat het OS 'weet' dat zo'n proces toegang mag krijgen tot meerdere cores.

Maar zo gaat het dus niet?

[Herko_ter_Horst]

Welk probleem ben je nu aan het oplossen? Gaan de taken die je uitvoert traag? Of zit je puur te kijken naar wat grafiekjes?

Het is hoe dan ook bij normaal gebruik niet nodig om CPU/core affiniteiten in te stellen, dat moet je inderdaad gewoon het OS laten regelen. Dat doet Windows ook gewoon.

Het meest waarschijnlijk is dat je nieuwe CPU simpelweg niet meer de bottleneck is, maar een ander deel van het systeem. Dus tenzij applicaties echt veel langzamer draaien dan je zou mogen verwachten, zou ik me geen zorgen maken.

[CaptJackSparrow]

Herko_ter_Horst schreef op maandag 09 april 2012 @ 01:58:
Dus tenzij applicaties echt veel langzamer draaien dan je zou mogen verwachten, zou ik me geen zorgen maken.

Zoals je hierboven hebt kunnen lezen doen ze dat inderdaad.

[C.Hariri]

Heeft met context switches te maken: elk process/thread mag een tijdje dingen uitvoeren. Totdat het process zelf aangeeft dit niet meer wil gebruiken of om bepaalde (bij OS) tijd (quanta), zal het OS zelf bepaalt welke thread recht heeft op de CPU tijd. Als het proces dan op een andere core wordt gezet dan moet oa. het TLB worden overgezet/opnieuw worden opgebouwt. En dat kost veel tijd.

[Verwijderd]

CaptJackSparrow schreef op maandag 09 april 2012 @ 01:45:
Wat ik er van lees lijkt dat imagecfg tooltje processen ook statisch aan een absoluut core-nummer te koppelen. Dat zoek ik niet.

Daarom moet je dan ook imagecfg -u en niet imagecfg -a gebruiken.

Lees je uberhaupt wel?


imagecfg -a zet de affinity zoals gewenst in de image load config directory van de .exe (en voegt die directory toe aan als de .exe er nog geen had)

imagecfg -u zet de 'IMAGE_FILE_UP_SYSTEM_ONLY' flag in de COFF header van de .exe

[Marando]

redfoxert schreef op zondag 08 april 2012 @ 23:40:
Hou je er rekening mee dat er bijna geen "normale" huis-tuin-keuken software is die geoptimaliseerd is voor het gebruiken van meerdere cores?

Eindelijk het goeie antwoord!

[Fordox]

Marando schreef op dinsdag 10 april 2012 @ 08:24:
[...]

Eindelijk het goeie antwoord!

eindelijk? ik zei het ook al in de eerste post

wat ook niet slecht is om te weten, is dat sommige applicaties geen multicores ondersteunen.

[CaptJackSparrow]

Helaas wist ik dat allang en heb ik ook beschreven dat ik niet verwacht dat applicaties meerdere cores gebruiken. Daar gaat dit topic dus niet over. Maar ik verwacht wel dat ze één core voor 100% moeten kunnen gebruiken. Daar is ondertussen ook al iets bereikt. Dat staat ook al in het topic.

[Fordox]

windows doet dat met opzet. 1 core applicaties worden nog steeds verspreid over meerdere cores om de over all belasting te verminderen. als je een programma draait zie je ook dat alle load ongeveer constant blijft, en als je naar de cores kijkt kun je de load simpelweg op tellen.

je wilt ook niet 1 core volledig benutten en de rest laten idlen. is slecht voor zowel warmte ontwikkeling als de core in die cpu.

het is zo, en je kunt er niet veel tegen doen. de vraag is of je dat ook wel wilt, alle belasting op 1 core zetten of alles netjes verdelen?

[CaptJackSparrow]

Ik heb ook al beschreven dat ik wel degelijk prestatiewinst zie als ik een proces door één core laat uitvoeren. Dat wil ik dus wel degelijk. Ik wil alleen dan Windows dat op een slimme manier voor me regelt zodat ik dat niet handmatig hoef te doen met kans op situaties dat twee processen door dezelfde core gedaan zouden worden terwijl er vrije cores zijn. Dat heb ik ook al beschreven.

Ik kan geen enkele goede reden bedenken waarom dat niet zou kunnen. Ik zoek nu dus een manier om dat zo geregeld te krijgen zonder dat ik voor elke applicatie allerlei instellingen moet gaan maken. Ik zoek óf een instelling van Windows die dat regelt óf een utility die dat doet.

[Verwijderd]

je hebt een quad-core CPU.

Winrar gebruikt 1 core 100%, winrar zou dus een cpu gebruik van 25 moeten hebben.
je geeft aan rond de 30 te hebebn bij Winrar, dat is gewoon prima dus.
winrar gebruikt de cpu nog niet optimaal, maar als je van dezelfde schijf leest en schrijft is het sowieso al langzamer

[ApC_IcE]

Verwijderd schreef op dinsdag 10 april 2012 @ 15:53:
je hebt een quad-core CPU.

Winrar gebruikt 1 core 100%, winrar zou dus een cpu gebruik van 25 moeten hebben.
je geeft aan rond de 30 te hebebn bij Winrar, dat is gewoon prima dus.
winrar gebruikt de cpu nog niet optimaal, maar als je van dezelfde schijf leest en schrijft is het sowieso al langzamer

lees jij wel?
hij zegt dat als ie 1 core gebruikt voor 100% gaat het bijna 2 keer zo snel (met winrar) ipv 25% op 4 cores.
Dat wilt hij efficiënt maken. Alleen voor het 'slijtage' verhaal en 'hitte' verhaal kan ik wel iets indenken. maar daar zul je alleen achter komen als je eens begint met bepaalde programma's aan bepaalde cores toewijzen..
ik volg dit nog (verder geen tips)

[TERW_DAN]

Voor slijtage hoef je echt niet bang te zijn. Het maakt voor de core natuurlijk niet zo heel veel uit of z'n broertjes nu wel of niet ook wat te doen hebben.

[MORCIK]

CaptJackSparrow schreef op maandag 09 april 2012 @ 00:24:
Die affinity is inderdaad interessant. Als ik met Irfanview bijv. een Auto Adjust Colours laat verrichten wat puur in het geheugen moet kunnen plaatsvinden dan is dat met gebruik van één core, geforceerd met de affinity, in iets van 6 seconden gebeurd en gaat die core ook naar 100%. Laat ik twee cores gebruiken dan gaan die beide lang niet naar 100% en duurt het 9-10 seconden.

Met WinRAR hetzelfde. Een directory met foto's laten inpakken geeft kort na het starten met 1 core een verwachte tijdsduur van 2:18 met de core tegen de 100% en met 2 cores 4:40.

Wonderlijk dat de interne 'load-balancing' mechanismen van Windows hier contraproductief lijken te werken.

Opmerkelijke conclusies. Ik heb zelf ook de proef op de som genomen, maar bij mij is het precies andersom:

WinRAR x64 3.93

Inpakken van 4GB aan data op SSD-schijf (max. compressie) met multicore ruim 13 minuten. Single core met aanpassing d.m.v. affinity ruim 27 min.

Irfanview ga ik ook zo proberen.

[MORCIK]

Irfanview 4.27

Auto adjust colors van een RAW-file duurt consequent 11 à 12 seconden single of multicore. Zelfs als de belasting verdeeld wordt over meerdere cores, wat overigens willekeurig lijkt te gebeuren.

[CaptJackSparrow]

Dat van WinRAR kan kloppen. Uit de version history:

Version 3.90

1. WinRAR version for Windows x64 is available. If you use
Windows x64, it is strongly recommended to install 64 bit
WinRAR version. It provides a higher performance and better
shell integration than 32 bit version.

2. RAR compression speed is improved for multi-core
and multi-CPU systems. This improvement is most noticeable
in Windows Vista and Windows 7 operating systems.

Ik gebruik een beduidend oudere versie die nog geen multi-core ondersteuning heeft. De versie die jij gebruikt is dus geen goede testkandidaat voor het testen van single-core applicaties in een multi-core systeem.

[revertive]

CaptJackSparrow schreef op dinsdag 10 april 2012 @ 20:08:
Dat van WinRAR kan kloppen. Uit de version history:


[...]


Ik gebruik een beduidend oudere versie die nog geen multi-core ondersteuning heeft. De versie die jij gebruikt is dus geen goede testkandidaat voor het testen van single-core applicaties in een multi-core systeem.

Je gebruikt dus expres een oudere versie van winrar die geen ondersteuning heeft voor jou multi-core CPU? En dan open je een topic dat o.a. winrar je multi-core CPU niet volledig gebruikt?

[Verwijderd]

CaptJackSparrow schreef op dinsdag 10 april 2012 @ 20:08:
Dat van WinRAR kan kloppen. Uit de version history:


[...]


Ik gebruik een beduidend oudere versie die nog geen multi-core ondersteuning heeft. De versie die jij gebruikt is dus geen goede testkandidaat voor het testen van single-core applicaties in een multi-core systeem.

Volgens mij is de versie die jij gebruikt geen goede testkandidaat aangezien in jouw versie de multi core niet voldoende/juist presteert. Dan lijkt het me sowieso niet representatief.

[ Voor 10% gewijzigd door Verwijderd op 10-04-2012 20:20 ]

[CaptJackSparrow]

De versie van WinRAR die ik gebruik is gewoon de versie die ik geïnstalleerd heb staan en is, naar nu blijkt, dus goed te gebruiken als representatief voor single core applicaties in een multi-core systeem.

Dat een nieuwere versie de prestatie van WinRAR kan verbeteren is vanzelfsprekend blijkt nu maar dat verandert niet dat het beheer van single core applicaties niet optimaal lijkt te zijn.

Ik gebruik ook versie 4.27 van Irfanview maar deed het met een .JPG bestand. Irfanview gebruikt allerlei plug-ins en met name voor bijv. RAW ondersteuning van Canon moet je zelfs DLLs van Canon geïnstalleerd hebben staan. Als daar ergens multi-core ondersteuning in zit dan geldt daarvoor hetzelfde als voor WinRAR.

[RyuuPro]

CaptJackSparrow schreef op dinsdag 10 april 2012 @ 20:32:De versie van WinRAR die ik gebruik is gewoon de versie die ik geïnstalleerd heb staan en is, naar nu blijkt, dus goed te gebruiken als representatief voor single core applicaties in een multi-core systeem.

Dat een nieuwere versie de prestatie van WinRAR kan verbeteren is vanzelfsprekend blijkt nu maar dat verandert niet dat het beheer van single core applicaties niet optimaal lijkt te zijn.

Verouderd. Dus als zij ondertussen (neem een random versie tussen jouw versie en de 1e 64-bits ondersteuning in) ergens 20% winst hebben gevonden op de single core is de jouwe nog steeds representatief?

Lijkt me niet dus.

[MORCIK]

CaptJackSparrow schreef op dinsdag 10 april 2012 @ 20:32:
Ik gebruik ook versie 4.27 van Irfanview maar deed het met een .JPG bestand. Irfanview gebruikt allerlei plug-ins en met name voor bijv. RAW ondersteuning van Canon moet je zelfs DLLs van Canon geïnstalleerd hebben staan. Als daar ergens multi-core ondersteuning in zit dan geldt daarvoor hetzelfde als voor WinRAR.

Nu ook met een .jpg geprobeerd met dezelfde grootte (21MP) als de RAW-file. Wederom 11 à 12 seconden, zowel single als multicore. Kennelijk heeft de kleurbewerking geen invloed als het plaatje eenmaal geladen is in Irfanview, ongeacht de bestandsindeling.

[Craven]

CaptJackSparrow schreef op dinsdag 10 april 2012 @ 20:32:
De versie van WinRAR die ik gebruik is gewoon de versie die ik geïnstalleerd heb staan en is, naar nu blijkt, dus goed te gebruiken als representatief voor single core applicaties in een multi-core systeem.

Dat een nieuwere versie de prestatie van WinRAR kan verbeteren is vanzelfsprekend blijkt nu maar dat verandert niet dat het beheer van single core applicaties niet optimaal lijkt te zijn.

Ik gebruik ook versie 4.27 van Irfanview maar deed het met een .JPG bestand. Irfanview gebruikt allerlei plug-ins en met name voor bijv. RAW ondersteuning van Canon moet je zelfs DLLs van Canon geïnstalleerd hebben staan. Als daar ergens multi-core ondersteuning in zit dan geldt daarvoor hetzelfde als voor WinRAR.

Allemaal leuk en aardig maar wat wil je nou bereiken met dit topic? Eerst hebben we het over een probleem dat je cpu niet volledig belast word door verschillende applicaties. Waar o.a. winrar bij zit. Dit blijkt vervolgens een applicatie specifiek probleem te zijn en er is een (soort van) workaround beschikbaar met imagecfg naar ik begrijp. Maar er komt bij winrar naar voren dat een nieuwe versie het probleem ook oplost.

Hierna gaat de discussie over naar de geschiktheid van de applicatie voor de tests die je uitvoert.

By all means, ik vind het een interessante discussie om te voeren. Maar wat is het nu precies wat je wilt bereiken? Het oplossen van je probleem dat je cpu niet volledig gebruikt word. Of het testen performance van multicore processoren in Windows? Of iets totaal anders? Als je dat niet duidelijk maakt gaat dit topic namelijk in rap tempo een grote zooi van miscommunicatie worden.

[Verwijderd]

Mensen die niet lezen...

Craven schreef op woensdag 11 april 2012 @ 00:02:
Eerst hebben we het over een probleem dat je cpu niet volledig belast word door verschillende applicaties.

Nee daar hebben we het niet over. Er is geen probleem om Winrar 50% van telkens twee cores, of 25% van telkens vier cores te laten innemen. Dat is de maximum load die je kan bereiken met een single-threaded applicatie, de cpu wordt dus volledig (zo goed mogelijk) belast.

Het probleem waar het wel over gaat is dat als een single-threaded applicatie verdeeld wordt over cores (opeenvolgend door verschillende cores uitgevoerd wordt), dat minder performantie geeft dan als je alles (geforceerd) op één core houdt.

Dit blijkt vervolgens een applicatie specifiek probleem te zijn

Dat is het niet. Het probleem speelt met veel/alle single-threaded applicaties.

Het geneuzel hierboven over welke versie van Winrar gebruikt moet worden is totaal niet relevant; het mag echter duidelijk zijn dat als je performantie van single-threaded applicaties onderzoekt, het best dom is om dan met nieuwere versies van Winrar welk applicatie dan ook af te komen die wel multi-threaded zijn. Je kan wel bijdehand stellen om een multi-core versie te gebruiken maar:

a) daarmee weet je alsnog de oorzaak van of oplossing voor het performance probleem niet;
b) hopen applicaties hébben gewoon geen multi-threaded implementaties.


En ten slotte, wat TS wil is een instelling of tool die ervoor zorgt dat de Windows scheduler single-threaded applicaties niet (constant) van de ene naar de andere core migreert (spelen met affinity is geen goeie optie omdat je wel de scheduler zelf de mogelijkheid wil geven om een proces aan een core toe te wijzen). Ik vrees echter toch dat per-applicatie instellen toch de enige beschikbare methode is.

[MORCIK]

Craven schreef op woensdag 11 april 2012 @ 00:02:
By all means, ik vind het een interessante discussie om te voeren. Maar wat is het nu precies wat je wilt bereiken? Het oplossen van je probleem dat je cpu niet volledig gebruikt word. Of het testen performance van multicore processoren in Windows? Of iets totaal anders? Als je dat niet duidelijk maakt gaat dit topic namelijk in rap tempo een grote zooi van miscommunicatie worden.

Bij hem gaat de performance van een singlecore-applicatie omlaag als deze verdeeld wordt over de verschillende cores. Als hij 1 core afdwingt werkt deze sneller. Aangezien niet alle applicaties multicore ondersteunen wil hij een workaround om singlecore-applicaties op 1 core te laten draaien, en dit automatisch indelen op de core die het minst belast is.

Ik heb inmiddels een test gedaan met het encoden van video met ffmpeg. 2 minuten en 5 seconden zowel single als multicore. Tot dusver heb ik geen vertraging als een singlecore-applicatie verdeeld wordt over meerdere cores, iets waar TS wel last van lijkt te hebben.

[Verwijderd]

Het is wellicht handig om bij benchmarks ook te vermelden welke cpu je hebt. Iets als een i5/i7 b.v. heeft een turbo mode waarbij een core automatisch overklokt als het de enige is die iets te doen heeft - dus als een proces geforceerd wordt op die ene core b.v. Het mag logisch zijn dat vier cores aan 2 GHz elk 25% belast dan sowieso trager gaan zijn dan één core aan 2.5 GHz 100% belast.

[MORCIK]

Verwijderd schreef op woensdag 11 april 2012 @ 00:30:
Iets als een i5/i7 b.v. heeft een turbo mode waarbij een core automatisch overklokt als het de enige is die iets te doen heeft

Nooit geweten. Ik heb inderdaad een i7. De tijden die ik gemeten heb komen in geval van single en multicore exact met elkaar overeen.

[MORCIK]

Nog een test:

Mcafee Virusscan Enterprise 8.7.0i. Scanengine 64 bit, versie 5400.1158

Scannen van C:\Program Files (x86) op SSD-hardeschijf met multicore:

9 minuten en 19 seconden

Single core:

9 minuten en 19 seconden

De resultaten zijn echt exact hetzelfde. Tot nu toe heb ik de problemen van TS niet kunnen reconstrueren.

[Craven]

Verwijderd schreef op woensdag 11 april 2012 @ 00:24:
Verhaal...

MORCIK schreef op woensdag 11 april 2012 @ 00:27:
[...]
Verhaal...

Excusez moi. Met alle goede bedoelingen. Maar ik had schijnbaar een te lange dag.

Zal vanavond is kijken wat mijn HTPC hiermee doet. Dat is een oude amd tri-core dus geen turbo mode maar wel flinke snelle ssd erin.

[CH4OS]

MORCIK schreef op woensdag 11 april 2012 @ 01:14:
Nog een test:

Mcafee Virusscan Enterprise 8.7.0i. Scanengine 64 bit, versie 5400.1158

Scannen van C:\Program Files (x86) op SSD-hardeschijf met multicore:

9 minuten en 19 seconden

Single core:

9 minuten en 19 seconden

De resultaten zijn echt exact hetzelfde. Tot nu toe heb ik de problemen van TS niet kunnen reconstrueren.

Zou zeggen; trek je conclusie. Je kan er toch wel vanuit gaan dat de AV die je gebruikt gewoon singlethreaded is, zoals nog altijd zo'n beetje élk programma.

[MORCIK]

CptChaos schreef op woensdag 11 april 2012 @ 19:33:
[...]
Zou zeggen; trek je conclusie. Je kan er toch wel vanuit gaan dat de AV die je gebruikt gewoon singlethreaded is, zoals nog altijd zo'n beetje élk programma.

Dat was ook mijn conclusie en daarmee een prima test. Het is natuurlijk vreemd dat TS een verminderde performance heeft als de taken over de cores verdeeld worden.

[visblegamer]

Ik heb hier de zelfde processor en geheugen

Met een asus F1A55-M LE ik merk dat me pc sneller wil maar omdat er een langzame 160gig sata schijf inzit kan dat niet maar hier loopt die lekker

[Verwijderd]

Heel misschien dat je hier iets aan hebt.