Windows 7 krijgt performance-hotfix voor AMD Bulldozer-chips

Microsoft heeft op Patch Tuesday, de tweede dinsdag van de maand, waarop updates voor Windows-systemen worden verspreid, een patch vrijgegeven die de prestaties van systemen met AMD's Bulldozer-processor moeten verbeteren.

De update werd als hotfix beschikbaar gesteld, maar lijkt inmiddels niet meer te downloaden. Wat de reden achter het gedeeltelijk terugtrekken van de hotfix is, maakt Microsoft niet bekend. Wie de update wel heeft bemachtigd en geïnstalleerd op een Windows 7-systeem of een Windows Server 2008 R2-systeem met een AMD FX-processor aan boord, moet volgens Microsoft prestatieverbeteringen bemerken.

De update moet onder meer de samenwerking met de Bulldozer-smt-methode verbeteren. De prestaties van AMD's nieuwste vlaggenschipprocessors, de FX-serie met AMD's nieuwe Bulldozer-architectuur aan boord, vielen echter tegen volgens legio reviews. Dat zou deels te wijten zijn aan de manier waarop Windows taken aan de verschillende beschikbare threads in de Bulldozer-processor toewijst. Bulldozer maakt gebruik van modules met twee gedeeltelijke cores; Windows zou niet correct omgaan met de nieuwe smt-feature.

Tweakers.net installeerde de update eveneens op een FX-testsysteem, waarna bleek dat de snelheidswinst gemiddeld op slechts 1 procent uitkomt. Enkele benchmarks bleken zelfs aanzienlijk trager afgerond te worden na installatie van de hotfix.

Benchmark	FX-8150	FX-8150 met hotfix	Verschil
Cinebench OpenGL	58,2fps	58,8fps	1,1%
Cinebench 1cpu	1,01p	1,03p	2%
Cinebench xcpu	5,95p	6p	1%
PCMark 7	4014p	4072p	1,4%
3DMark Vantage	17736p	18011p	1,6%
3DMark11	4980p	4991p	0,2%
Photoshop	15s	16,9s	-12,9%
Premiere	220,2s	226,4s	-2,8%
Lightroom	70,8s	73,1s	-3,2%
Handbrake	55,5s	54,5s	1,8%
Winrar	37,4s	38,2s	-2%
Quickpar	261s	261s	0%
Gemiddeld verschil			-0,2%

Games	FX-8150	FX-8150 met hotfix	Verschil
Farcry avg	93,8fps	92,3fps	-1,5%
Farcry min	74,8fps	73,4fps	-1,5%
AvP avg	57,3fps	57,1fps	-0,4%
AvP min	35fps	35,7fps	2%
Stalker avg	78,3fps	79,2fps	0,6%
Stalker min	44,5fps	45,8fps	3,1%
Gemiddeld verschil			0,4%

Reacties (74)

[hugoy]

Hoewel de woordkeuze klopt bij de eerste tabel (gemiddeld verschil is 1%) moet er wel opgelet worden dat het 1% LANGZAMER is, tel maar na ((1,1+2+1+1,4+1,6+0,2-12,9-2,8-3,2+1,8-2)/12)= -1%, de hotfix werkt dus negatief volgens deze benchmarks, mits er niet iets fout is overgenomen in deze tabel.

[wiskid]

Geweldig dit: Je geeft het gemiddelde van een fruitmand weer en zegt dan dat de kwaliteit van de appels +2% is en de peren -3%, dan is de uitkomst -1%?

Hoeveel appels waren er en hoeveel peren? Wat gebruik ik het meest? Waar licht mijn voor keur?

Ik weet niet, maar procenten op tellen en delen door elkaar is over het algemeen een niet zo beste manier van rekenen. Zeker niet als het over appels en peren gaat. Als het nu over alle programma's een negatief resultaat was geweest dan had je kunnen spreken van een snelheidswinst van -1%. Maar nu? Er zijn een aantal applicaties die een winst van 10% of meer laten zien.

http://ht4u.net/news/2485..._ergebnisse_enttaeuschen/

[hugoy]

Als je niet aangeeft of je peren of appels belangrijker vindt, en je hebt er evenveel, dan kun je stellen dat de gemiddelde kwaliteit -0,5% ten opzichte van het gemiddeld dus (dus NIET -1%).

Daarbovenop komt ook nog eens dat ik in dit geval appels (synthetische benchmarks) minder belangrijk vind dan peren (praktijk benchmarks), dan zou de score nog veel negatiever uit moeten vallen.
Aangezien de synthetische benchmarks allemaal positief zijn, en bij de praktijk benchmarks slechts één matig positief is, met een enorme negatieve uitschieter in een toch wel zéér veel gebruikt programma.

Dus kun je wel degelijk stellen dat de fruitmand vóór deze aanpassing beter was dan na, aangezien je een 1% lekkerdere ananas niet proeft, maar een 13% zuurdere sinaasappel als onsmakelijk wordt ervaren.

Dat je een andere bron aanhaalt waar blijkbaar positieve uitschieters naar +10% zijn doet natuurlijk niet af aan het feit dat de gegevens van T.net niet juist verwerkt zijn.

[Korben]

Vreemd verhaal van AMD. Windows draait al jaaaaaren prima op smt-processoren (Intel Pentium 4, Core i-reeks, Xeons), en nu komt AMD met een nieuwe processor, en dan zou het probleem aan Windows liggen.

[roy-t]

Windows zou niet correct omgaan met de nieuwe smt-feature.

Volgens mij is het vooral tweakers.net wat dit beweert dan AMD of Microsoft zelf. Wel is het zo dat AMDs Bulldozers gebaat zijn bij een andere scheduling strategie. Microsoft heeft ooit voor Windows XP ook een update gemaakt waardoor bij het herkennen van processoren met HT er ook een andere techniek gebruikt wordt (eerst schedulen op de echte cores en daarna pas op de virtuele ipv ze allemaal gelijk te behandelen) en dat heeft toen ook wat snelheidswinst opgeleverd. Bij AMD is het echter nog ingewikkelder. Je kunt targetten op 1 thread per module, dan heeft elke thread de integer en floating point units helemaal voor zichzelf maar dan zal Turbo niet gebruikt kunnen worden. Je kunt ook zoveel mogelijk threads per module proberen te doen, dan is er een hoge turbo maar worden de int en float modules van de module gedeeld. Het zal per taak uitmaken wat nu echt beter is en dat maakt waarschijnlijk waarom er zowel uitschieters naar boven als naar onder zijn. Wel is het voor de energiezuinigheid handing om zo min mogelijk modules aan te hebben. Keuzes, keuzes, keuzes dus. Ik ben benieuwd welke tacktiek er nu in deze patch zit en of deze verschilt als je op een batterij werkt of niet.

[robvanwijk]

Je kunt targetten op 1 thread per module, dan heeft elke thread de integer en floating point units helemaal voor zichzelf

Eén van de grote verschillen tussen "AMD hyperthreading" (Bulldozer) en "Intel hyperthreading" (Core) is nou juist dat in Bulldozer elke core zijn eigen integer units heeft.
Hoe het precies zit met de floating point units weet ik niet; het zijn er twee voor twee cores, die tot een dubbel-brede AVX-unit gecombineerd kunnen worden. Dus als (minstens) één van de threads met AVX bezig is (én meer dan de helft van de cycles een AVX instructie kan beginnen) , dan zullen ze elkaar in de weg zitten, het is me niet helemaal duidelijk of ze last van elkaar hebben als ze alleen "gewone" floating point instructies gebruken.
Overigens delen twee cores in een module ook andere dingen zoals de instructies decoder en de L2 cache, beide zou performance negatief kunnen beïnvloeden.

Keuzes, keuzes, keuzes

Zou het niet mogelijk moeten zijn om dit aan te passen aan de hand van het power profile; maximum battery life -> zo min mogelijk modules actief, maximum performance -> zo min mogelijk twee threads op één module.

Overigens, om het extra "interessant" te maken kunnen twee threads die veel communiceren (omdat ze bij hetzelfde process horen bijvoorbeeld) er juist voordeel bij hebben om een module (en dus L2) te delen... Het is echt niet zo dat ze bij Microsoft hebben zitten slapen of dat iemand dit op een vrijdagmiddagje in elkaar geprutst heeft; het probleem is aanzienlijk lastiger dan je op het eerste gezicht zou verwachten.

[Stannieman]

"Ik ben benieuwd welke tacktiek er nu in deze patch zit en of deze verschilt als je op een batterij werkt of niet."

Ze zouden het kunnen koppelen aan de energiebeheer/power control instellingen die je in configuratiescherm vindt, al betwijfel ik dat, want dan kan je daar duizenden dingen gaan instoppen.

[Madrox]

Het probleem is dat deze chip maar 1 FPU per module heeft. Daar zit de grootste angel.

Each module features two integer cores and a shared floating point core.
Het begin van alle ellende...

[Reactie gewijzigd door Madrox op 24 juli 2024 08:43]

[computerjunky]

helemaal mee eens en dat allemaal om ruimte te besparen voor een hogere clock...
hoop dat de volgende rev gewoon 8 cores zijn zonder gedeelde onzin.

[A Noniem]

Het ontwerp van AMD steekt toch wel ff iets anders in mekaar dan de Intel Processoren.

[Bauknecht]

Je hebt Symmetric Multiprocessing, hetgeen jij het over hebt en Simultaneous Multithreading, waar de patch en het artikel om draaien.

[Korben]

Ik heb het over de Pentium 4 met HyperThreading. HyperThreading is een implementatie van Simultaneous Multithreading. Bepaalde Xeon-modellen en Core i-serie modellen hebben dat ook. Het werd door Windows al vanaf Windows XP (en wellicht eerder) ondersteund.

[mae-t.net]

Draait al jaren prima... Maar ik maak me sterk dat er voor bijvoorbeeld hyperthreading op de P4 (toen ook een nieuw en afwijkend concept) ook wel hier en daar wat gefinetuned zal zijn geworden.

[Reactie gewijzigd door mae-t.net op 24 juli 2024 08:43]

[Stannieman]

Dan hoop ik dat hij is teruggetrokken omdat er ergens toch iets niet goed zit met de update (waardoor de prestatiewinst toch zo goed als niks blijkt te zijn).
Als mijn hoop waarheid blijkt te zijn komt hij later waarschijnlijk alsnog uit met merkbaardere verbeteringen, al zou ik niet meteen een prestatiewinst van meer dan 5% verwachten met een update alleen.

KB article:
http://support.microsoft.com/kb/2592546

[Reactie gewijzigd door Stannieman op 24 juli 2024 08:43]

[wildhagen]

Op diverse mailinglists voor ICT-beheerders/professionals wordt gemeld dat de patch om twee redenen is teruggetrokken:

1) In bepaalde scenarios zou de performance dramatisch achteruit gaan.
2) Er zijn stabiliteitsproblemen gemeld na installatie van deze patch (BSOD's en applicatiecrashes)

Microsoft zou deze issues nu "under investigation" hebben.

[Astennu]

De verschillen onder windows 8 waren wel wat groter.
En hier noteer je vaak een groter verlies dan de winst. Dus ik vraag me af of het helemaal goed getest is.

Wat de hotfix zou moeten doen is de Scheulder vertellen dat hij voor bv 4 threads elke thread op een module moet zetten. Dus ipv 4 threads op 2 modules te laten draaien de 4 threads over de 4 modules verdelen.

[Verwijderd]

Wat de hotfix zou moeten doen is de Scheulder vertellen dat hij voor bv 4 threads elke thread op een module moet zetten. Dus ipv 4 threads op 2 modules te laten draaien de 4 threads over de 4 modules verdelen.

Neen, het werkt omgekeerd. AMD wil zo veel mogelijk threads op zo min mogelijk modules draaien, zodat ze die modules hoger kunnen klokken.

Gezien elk paar cores de decoder en floating-point unit in een module moeten delen werkt dat echter niet altijd voordelig.

[Stannieman]

Eigenlijk zou de scheduler moeten kijken naar welke instructies de threads daadwerkelijk uitvoeren.
Als 2 threads bv. elk integer berekeningen doen en slechts 1 ervan de floating point nodig heeft, dan mogen ze op 1 module. Hierdoor kan de klok van deze module omhoog mits die van de andere modules omlaag kan -> betere performance.

Als de 2 threads echter beide de floating point nodig hebben krijgen ze best elk hun aparte module voor de beste performance, omdat ze anders elkaar in de weg lopen.
In dit geval moeten er natuurlijk nog afwegingen gemaakt worden:
Als de 2 threads de FPU niet zo intensief gebruiken waardoor de FPU met die 2 threads nog niet volledig belast wordt, dan kunnen ze alsnog 1 module met hogere klok delen.
Dan is er nog een afweging. Als de 2 threads de FPU wel volledig belasten en de FPU een kleine bottleneck vormt, wat is dan het beste? Beide threads op 1 hoger geklokte module en een kleine bottleneck? Of beide threads op een aparte module zonder bottleneck maar een iets lagere klok.

Je ziet, als je een beetje begint na te denken en je ziet waar een goede scheduler allemaal rekening mee moet houden, dan is het allemaal zo eenvoudig nog niet.
Komt nog bij dat de scheduler van windows dus niet enkel bulldozers moet schedulen maar ook nog een ton andere chips.

[Verwijderd]

De scheduler van het besturingssysteem heeft geen informatie over wat voor instructies elke thread bevat. In theorie is dat wel mogelijk omdat de processor telllers bevat voor profiling-tools, maar deze statistieken bijhouden is heel wat werk en de scheduler dient zo snel mogelijk te zijn. Bovendien kan een applicatie zelf op een thread verschillende taken uitvoeren en dus kan het soort instructies van de ene op het andere moment sterk veranderen!

En inderdaad het lijkt me geen goed idee om software (of het nu de applicatie of het besturinssysteem is) zo sterk afhankelijk te maken van de hardware. Als de volgende architectuur van AMD er anders uitziet zou Microsoft de scheduler weer moeten aanpassen en wordt het weer logger.

Het is AMD's eigen schuld dat ze een architectuur hebben gecreëerd die zo gevoelig is voor scheduling-details. Een gelijkaardig verhaal speelt zich af met hun ASF voorstel. Dat werkt in theorie goed met hun architectuur maar enkel wanneer de software zich ervoor in bochten wringt. Gelukkig lijken ze die plannen te laten vallen hebben nadat Intel en IBM een veel krachtiger en generiek vorm van hardware transactional memory hebben voorgesteld.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 08:43]

[TD-er]

De scheduler moet inderdaad zo snel mogelijk zijn, maar er is niets op tegen om heel simpele statistieken bij te houden en bij een volgende taskswitch daar rekening mee te houden.
Je hoeft niet meteen bij elke taskswitch de theoretisch beste keus te maken, maar als een proces meerdere threads gebruikt kun je bijvoorbeeld al aannames maken dat ze geheugenblokken delen, dus cache-technisch zo dicht mogelijk bij elkaar plaatsen (vooral van belang bij meerdere CPU-sockets).
En wanneer een paar threads de afgelopen X taskswitches vrijwel alle beschikbare CPU-tijd gebruikt hebben, zet ze dan elk op een andere core. Als dan extra cores aangezet moeten worden en de turbo terugvalt, dan is dat maar zo. De turbo zal geen factor 2 zijn van de normale performance, dus is een 2e core erbij zetten netto sneller.
Zo kun je in de scheduler wel een aantal zaken bij houden, die nu ook al bekend zijn en aan de hand daarvan op de achtergrond een andere scheduling-strategie toekennen. Dan is het werkelijke schedulen alsnog heel snel, maar kan het netto-resultaat wel beter zijn.

[Amorac]

Zover ik had begrepen wil AMD dat threads die met elkaar te maken hebben (ie van het zelfde programma) zoveel mogelijk op dezelfde module werkt zodat de integer units sneller met elkaar kunnen lullen.

2 programma's die beide maar 1 thread hebben mag wat AMD betreft op 2 apparte modules verwerkt worden.

[Astennu]

Mmh dat is dan niet slim. Leuk dat je clocks hoger zijn maar de performance zakt dan toch in omdat je veel moet delen.

[Verwijderd]

Jullie gebruiken wel een vreemde methode om het gemiddelde verschil te bepalen...

Als ik de verschilpercentages optel en deel door het aantal benchmarks komt ik toch op slechtere waardes uit.

[robvanwijk]

Mijns inziens moet je de verschillen ook niet optellen en delen door N, maar met elkaar vermenigvuldigen en tot de 1/Nde macht verheffen.

Rekenkundig gemiddelde:
(1.101+1.020+1.010+1.014+1.016+1.002+0.871+0.972+0.968+1.018+0.980+1.000)/12=0.997666667
(0.985+0.985+0.994+1.020+1.006+1.031)/6=1.0035
Oftewel -0,2% en +0,4%

Meetkundig gemiddelde:
(1.101*1.020*1.010*1.014*1.016*1.002*0.871*0.972*0.968*1.018*0.980*1.000)^(1/12)=0.996368885
(0.985*0.985*0.994*1.020*1.006*1.031)^(1/6)=1.00335036
Oftewel -0,4% en +0,3%

Nog even met WolframAlpha spelen geeft
Harmonic Mean -0,5% en +0,3%
RootMeanSquare -0,1% en +0.4%

Ter vergelijking, het artikel claimt +1% en +0,9%; ik heb werkelijk geen idee op welke manier je moet middelen om dat eruit te krijgen. Overigens, ik zeg niet dat al deze manieren van middelen zinnig zijn in dit geval, het was een poging om te "reverse engineeren" welk gemiddelde is gebruikt. Je mag het trouwens ook beschouwen als een demonstratie van "lies, damn lies and statistics", of gewoon om te laten zien dat het hoe dan ook weinig scheelt; de grootste absolute waarde die erbij staat is een half procent...

[Reactie gewijzigd door robvanwijk op 24 juli 2024 08:43]

[humbug]

En waarom is jou methode in dit geval beter dan het rekenkundig gemiddelde? Er zijn vele methoden om een gemiddelde te bepalen, maar het rekenkundig gemiddelde is een redelijke standaard methode die door veel mensen (ook die zonder opleiding in de statistiek) goed te begrijpen is. Ik zie eigenlijk geen reden om daar op een website van af te wijken.

Maar dat de cijfers van Tweakers (zoals wel vaker) met een korreltje zout genomen moeten worden lijkt duidelijk. Men schrijft namelijk al "Gemiddeld verschil". Je moet dan dus de absolute waarde (het verschil) van de afwijkingen nemen. (net zoals de afstand tussen twee plaatsen nooit negatief kan zijn is een verschil altijd positief) Gezien er 12 waarnemingen zijn en Photoshop al een afwijking van 12,9% heeft is een gemiddelde afwijking van 1% compleet onmogelijk. (12,9/12 > 1 )

Maar men heeft dus gewoon de afwijkingen opgeteld en gedeeld door het aantal waarnemingen. Hierbij vergetend dat de ene test meer tijd in beslag neemt dan de andere en wat men eigenlijk meet. De conclusie is dus dat dit een hele rare "test" is die weer eens afbreuk doet aan het idee dat tweakers.net "echt wel" weet hoe men een test uitvoert. Dat is namelijk niet op deze manier.

[mae-t.net]

Met je laatste alinea, geef je meteen antwoord op je eerste. Niet alle test- en rekenmethdes zijn op elke situatie van toepassing.

[robvanwijk]

Excuses voor de late reactie, maar:

En waarom is jou methode in dit geval beter dan het rekenkundig gemiddelde?

1) Ik zeg niet welke beter is, alleen dat er ófwel een rekenfout is gemaakt, ófwel een ontzettend vreemd "gemiddelde" is gebruikt, want de berekening komt gewoon niet uit...
2) Ik denk inderdaad dat meetkundig gemiddelde of misschien harmonisch het "beste" gemiddelde is, zie de reactie van n-i-x en deze regel uit je eigen post

Hierbij vergetend dat de ene test meer tijd in beslag neemt dan de andere en wat men eigenlijk meet.

als verklaring waarom dat een betere maatstaf is.

het rekenkundig gemiddelde is een redelijke standaard methode die door veel mensen (ook die zonder opleiding in de statistiek) goed te begrijpen is

Ik hoop dat dit niet al te arrogant overkomt, maar ik heb liever dat er een getal wordt geproduceerd dat daadwerkelijk iets zinnigs zegt dan dat iemand zonder opleiding in statistiek begrijpt hoe dat getal berekend is.

Men schrijft namelijk al "Gemiddeld verschil". Je moet dan dus de absolute waarde (het verschil) van de afwijkingen nemen. (net zoals de afstand tussen twee plaatsen nooit negatief kan zijn is een verschil altijd positief) Gezien er 12 waarnemingen zijn en Photoshop al een afwijking van 12,9% heeft is een gemiddelde afwijking van 1% compleet onmogelijk. (12,9/12 > 1)

Bedoel je nou dat het gemiddelde van +10 en -10 gelijk is aan het gemiddelde van 10 en 10, oftewel 10...!? Ik mag toch hopen dat je zelf snapt dat dit complete onzin is en aangezien je zelf al aantoont dat dit niet is wat het artikel gedaan heeft... waarom schrijf je dit überhaupt?

Maar men heeft dus gewoon de afwijkingen opgeteld en gedeeld door het aantal waarnemingen.

Ehm nee, dat is rekenkundig gemiddelde en dan zou er -0,2% en +0,4% uit moeten komen, terwijl het artikel +1% en +0,9% noemt.

[Reactie gewijzigd door robvanwijk op 24 juli 2024 08:43]

[n-i-x]

Zou het niet zinvoller zijn om het harmonisch te bepalen? Uiteindelijk gaat het tenslotte om de tijd die je computer nodig heeft om een taak uit te voeren, en die is evenredig met snelheid^-1.

[de_nille]

Waren de test op een clean instal van een systeem uitgevoerd, of op een reeds vervuilde windows omgeving? Want als je gewoon de scores van vroeger vergelijkt met deze kan je dit fenomeen ook soms zien zonder patch.

[bbob]

In de praktijk als je een patch hebt gaat het nooit om een clean install maar om draaiende systemen lijkt me.

[mad_max234]

Patch kan je on the fly bij de instal laten uitvoeren of gelijk na de instal. Dan spreken we nog steeds van clean instal en geen vervuilt systeem.

[ioor]

Dat is niet wat er bedoeld wordt........een draaiend systeem is in dit geval een systeem wat al in gebruik is.....dus dat kan NOOIT een clean install zijn...

[KoploperMau]

Ik wilde net zeggen, al deze verschillen kunnen ook optreden bij iets anders. Photoshop kan zomaar dezelfde snelheid hebben als je het nog een keertje doet...

[Verwijderd]

Wat denk je nu zelf? Dat ze bij tweakers een stelletje retards zijn? Ze weten echt wel hoe ze moeten benchen hier, dus ga er maar gewoon vanuit dat deze scores representatief zijn .

[dirkjesdirk]

Hier een test van nt4u.net. Het resultaat is daar niet veel beter. Enkele procentjes in de plus met een enkele uitschieter naar boven (die heeft t.net dan niet) en tegelijk ook enkele procentjes in de min met uitschieters naar beneden. Het lijkt er dus op dat of de hotfix nog niet klaar is of het is gewoonweg niet mogelijk.

Opvallende resultaten:
siencemark: + 10%
PC Mark7: + 14%!
PC Mark 5: - 1,5%
Winrar: - 16%

Vooral PC mark7 wijkt overigens wel af van de score van T.net (+ 1,4%). Dat is wel erg vreemd en ook wel groot verschil. Kan de tester dat verklaren?

[Reactie gewijzigd door dirkjesdirk op 24 juli 2024 08:43]

[Xanaroth]

Ziet er apart uit. Vooral gezien de test setups daar (mid/high end voor de moederborden en ook de grafische kaarten, dus niet puur cpu-gericht zoals je soms ziet).

[freaq]

de bulldozer patch van microsoft is inmiddels offline gehaald volgends VR-zone
LINK- http://vr-zone.com/articl...threaded-patch/14267.html

[Quindor]

Huh? Ze hebben een systeem gepakt (Wat wellicht al geïnstalleerd was) hebben hier alle benchmarks op gedraaid, hebben vervolgens de patch geïnstalleerd en de benchmarks opnieuw gedraaid.

Where's the problem?

[Verwijderd]

"moet volgens Microsoft prestatieverbeteringen bemerken" kom op zeg, alsof je merkt dat je nu 1fps meer hebt dan voorheen, juist ja. Dit gaat helemaal nergens over...

[comatoast]

inderdaad, als je Benchmarks draait for a living dan merk je een marginale versnelling.
gebruik je je computer voor productieve doeleinden heb je ongeveer 4% meer tijd nodig voor alles ... niet echt hot, zeker niet fix ...

[qlum]

volgens mij zou bulldozer een stuk beter kunnen scoren als programma's zelf zegen op welke module iets geplaatst word mits ze hiervoor gemaakt zijn op deze manier zullen ze een stuk beter kunnen scoren, sommige dingen werken goed binnen een module en andere hebben hun eigen module nodig dus als de programma's dat zelf regelen zullen de prestaties wel aardig goed komen

[Verwijderd]

Dat is reeds mogelijk maar werkt niet aangezien applicaties niks afweten van wat andere applicaties doen. Heb je dus twee applicaties die beide twee threads op de eerste module zouden willen draaien, dan kan het besturingssysteem ze elk maar 50% van de tijd op die module draaien.

Het is beter deze taak volledig aan het besturingssysteem over te laten zodat alle cores benut worden. Je kan ook niet verwachten dat ontwikkelaars voor elke mogelijke CPU-architectuur een aparte scheduler gaan schrijven.

Het is de taak van AMD om een architectuur te ontwikkelen die zo min mogelijk onderhevig is aan dit soort details. Bulldozer is in dat opzicht simpelweg een mislukking voor de desktopmarkt.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 08:43]

[Madrox]

Ze doen het al jaren slechter dan Intel's, ook de Phenom's. Wat is nieuw ?

De hotfix doet niet wat die moet doen, vandaar dat offline is gehaald. Een betere fix gaat nog wel komen, dat denk ik dan weer wel.

[stewie]

phenoms 2 deden het prima vs de core2duo, maar sinds de i5/i7 sandy bridge niet meer.

[Madrox]

Relatief, ja. Met een hogere clock en dan toch net ff trager.
http://www.neoseeker.com/...re/Reviews/pii_555/7.html
Zie hier hoe de dual core van amd verliest, zelfs van een oude E8500 (world in conflict).

De i5 750 maakt echter, zelfs op slechts 2.66Ghz vaak gehakt van 3.33Ghz geklokt PHenom II X4 965. Laat staan als je die i5 750 nog wat gaat kietelen.
http://www.anandtech.com/show/2832/16

[Reactie gewijzigd door Madrox op 24 juli 2024 08:43]

[HC_N.ick]

Zo te zien kun je de hotfix beter laten zitten, als ik zie dat de prestaties er alleen maar op achteruit gaan onderhand.