AMD brengt 'Dual-Core Optimizer' uit

AMD heeft een stukje software gepubliceerd dat volgens AMD op systemen met meerdere cores of meerdere processors de prestaties van bepaalde games zou verbeteren. Diverse gamedevelopers maken namelijk gebruik van een tellertje in de cpu om de tijd bij te houden, de zogenaamde TSC. Dualcores beschikken over twee van zulke tellertjes, en er is geen enkele garantie dat beide even snel lopen. Bovendien is de snelheid waarmee de TSC wordt opgehoogd vanwege bijvoorbeeld Cool'n'Quiet niet meer lineair. Games die de tijd via de Windows-API bijhouden hebben geen last van dit euvel, maar software die de bewuste tellers rechtstreeks uitleest krijgt hierdoor last van allerhande timingsproblemen. De fix die AMD nu heeft uitgebracht zorgt er kennelijk voor dat deze moeilijkheden worden tegengegaan. Ook Intel kende overigens vergelijkbare problemen toen het de SpeedStep-technologie introduceerde, wat later werd ondervangen door de TSC altijd op de volle snelheid te laten ophogen, ook als de rest van de cpu toevallig even trager draaide.

De Dual-Core Optimizer lijkt op het eerste gezicht AMD's eerste publieke stap op het gebied van 'omgekeerde HyperThreading' te zijn, maar niets is minder waar: het tooltje zorgt er niet voor dat singlethreaded toepassingen plotseling efficiënter van meerdere cores gebruik kunnen maken. In tegenstelling tot wat de naam suggereert, zou het programma eigenlijk het beste als een bugfix omschreven kunnen worden. Wel werd eerder al aangekondigd dat AMD zijn Socket AM2-processors met support voor Reverse HyperThreading zou hebben uitgerust, wat naar verluidt met een driverupdate te activeren zou zijn. Het nu gepubliceerde programma is echter voor alle dualcore- en multiprocessorsystemen van de fabrikant geschikt. Of er een significante prestatiewinst mee kan worden behaald mag dan ook op voorhand betwijfeld worden, maar alleen benchmarks kunnen daar definitief uitsluitsel over geven.

AMD dual-core die

Door René Wichers

Eindredacteur

05-07-2006 • 17:02

63

Submitter: J3roen

Bron: AMD

Reacties (63)

63
63
25
9
0
29
Wijzig sortering
.oisyn Moderator Devschuur® 5 juli 2006 17:10
Tja, ik zie liever gewoon vaste high-resolution timerhardware op het moederbord dat goed en snel uit te lezen is en nooit van snelheid veranderd zolang de PC aan staat. De verschillende bugs in games zijn daar wel het bewijs van. De rdtsc instructie is zoals gezegd amper te gebruiken, en Windows' QueryPerformanceCounter (waar deze software waarschijnlijk een fix voor brengt) is allesbehalve snel (hoewel het wel voldoende is om timesteps mee uit te rekenen, dat is slechts eens per frame, maar voor profiling is het een ramp)
Misschien wordt het gewoon tijd om een RealTime OS te gebruiken voor spellen?

Windows (net zo goed als linux en FreeBSD in standaarduitvoeringen) is eigenlijk het meest bizarre platform om spellen op te draaien. Je wilt namelijk een garantie dat een bepaalde berekening áltijd even snel draait, en niet fluctueert omdat het OS bepaalt dat er iets moet gebeuren.

Precies het probleem waar die TSC's een oplossing voor zijn, is in een Real Time omgeving een échte oplossing voor: de berekeningen worden dan elke X milliseconde gestart, en je hebt de garantie dat die altijd voor de deadline klaar zijn. Vervolgens kan je een aparte thread het resultaat van alle berekeningen samen samenvoegen en op het scherm zetten.
Wat nou gezeur met andere processors? Daar hoort het OS rekening mee te houden, niet de programmeur van de applicatie.
.oisyn Moderator Devschuur® @MBV5 juli 2006 23:02
Nee, het probleem is namelijk helemaal niet dat je niet weet hoe lang een bepaalde berekening kan duren, maar dat je niet weet hoeveel van die berekeningen je moet gaan doen. En daar gaat een real-time OS je net zo goed niet bij helpen. Games zijn prima stabiel te krijgen op een console, dat zijn ook geen real-time OS'en.

Bovendien gaat deze thread en mijn reactie over timers, niet over datgene wat getimed moet worden ;)
In hoeverre is het aantal berekeningen onbekend? Als er een 'normaal maximum' bekend is kan je bewijzen dat het in die gevallen schedulable is op *insert hardware*. Verder kan je op een RT-OS zorgen voor gunstige overload-afhandeling.

Dat het op consoles stabiel draait (blauwe schermen daarbuiten gelaten :+) wil nog niet zeggen dat het dan direct optimaal is. Dat blijft trial-and-error programmeren, iets waar iedere TU-leraar van gruwelt en vindt dat iedere TU-student van zou moeten gruwelen ;). Probleem op de PC t.o.v. consoles komt hier ook weer naar voren: te veel soorten hardware, en een incompetent OS dat die verschillen niet afvangt. En toen werkte trial-and-error ineens niet meer.

Ik ben van mening dat mijn post zeker relevant is, omdat het het hele probleem omzeilt waarvoor je die ontzettend nauwkeurige timers in de eerste instantie nodig had :)

't is dat ik de eerste reactie had geplaatst, anders had ik waarschijnlijk jouw argumenten aangedragen ;) Het blijft iets waar je over na moet denken. Omdat het altijd zo werkte, is dat nog niet direct de beste manier :)
Dit doet me denken aan die oude spelletjes die helemaal geen timing hebben. Draai het spel op een huidige pc, en je bent na 40ms doodgeschoten. :+

Als je nu nog op de processor vertrouwt om de tijd bij te houden, ben je IMHO slecht bezig...
Heel veel applicaties gebruiken de interne processor counters om tijd bij te houden als het om een 'ongeveer' tijd gaat. Deze counters zijn daar ook specifiek voor bedoeld.

Echter is er met Cool&Quiet en dual core een probleem ontstaan dat er ineens niet meer vertrouwd kan worden op de counters. Dit is niet echt een software probleem, maar meer een verandering van specs.

Het uitlezen van de hardwareklok duur meestal te lang om effectief te zijn als je dit heel vaka per seconde wil doen. Daarom is dat meestal geen alternatief. Wat een programma doet is, aan de hand van de hardwareklok, kijken hoe lang een tick duurt en daar dan mee verder rekenen. Als er precizie timing vereist is, wordt de hardwareklok gewoon weer geraadpleegd.
Het probleem bestaat al een stuk langer: sinds we echte mobiele cpu's hebben. En eigenlijk weten we al heel lang dat kloktik afhankelijke tellertjes onbruikbaar zijn om je timing te regelen. Zoals boven al aangehaald, als je vroeger je cpu flink geupgrade had werden je spelletjes onbruikbaar, of je moets met speciale 'slow down' software gaan knoeien. Gewoon slecht programmeerwerk,dus.
dat was in de tijd dat je met de turbo knop nog een game kon versnellen. hoezo 3dkaart nodig :Y)
Sega's Outrun Coast to Coast (2006!!!) laat z'n timing afhangen van de refresh van je display.
Hij wil 60Hz zien (arcade spel), zet je 'm hoger loopt het spel te snel. Leuk als je een 21" crt hebt... (Of als je online speelt tegen mensen die het als cheatmethode gebruiken.)
Ik krijg een bluescreen met DRIVER_IRQL_NOT_LESS_OR_EQUAL. En de uninstaller werkt niet in veilige modes, je bent gewaarschuuwd.
Anoniem: 88342 @T-RonX5 juli 2006 20:11
System restore / rollback cpu driver? :Y)
werkt niet.
NIET INSTALLEREN DEZE HAP!!!

(ik heb X2 4400+ met Nvidia video kaart, ben nu opnieuw aan 't installen :( kut drivers)
Ik heb het nog kunnen fixen met "De meest recente werkende instellingen laden" oid met F8. Ik heb trouwens een 939 4200+ en Asus A8N-SLI Premium. Heb ook de Dual Core driver en de MS fix.
voor iedereen die dit ook heeft (ik heb het gehad)
Ga naar:
Control Panel > System > Hardware > Device Manager > System Devices -> rechtermuisknop op 'AMD Special Tools Driver' en dan op uninstall, nu kun je weer normaal opstarten.
(voor degene met een nl versie:
Configuratiescherm->systeem->hardware->apparaatbeheer->systeemapparaten)
Hmm, dat kreeg ik toen ik mijn IDE kabel verkeerdom had aangesloten :Y)
Anoniem: 67950 5 juli 2006 17:08
Aan te bevelen is dan om geen cool'n'quiet te draaien tijdens gaming
tijdens een hoogwaardige game is het eerder Hot'n'Loud als je lucht koeling gebruikt ;)
Ja dat is zowiezo al aan te bevelen... want de processor kan niet binnen 1 kloktik van 1000mhz naar zijn originele kloksnelheid schakelen. Dus de processor is dan niet op tijd klaar voor plotselinge berekeningen...

Cool & Quiet was dan ook een ramp voor mij tijdens het spelen van Most Wanted.
Anoniem: 139094 5 juli 2006 17:28
Het bijbehorende topic op GoT:
forum: AMD Dual-Core Optimizer
Anoniem: 136863 5 juli 2006 17:15
1 thread op 2 cores klinkt mij beter als 2 op 1 ;) en verder die tick timers moeten toch gewoon altijd door ticken,

Wel raar opzich als je er over na denkt dat dan ticks geen snelheid bepaalt.. ook deze fix lijkt me lastig in sommige situaties/programma's..

@.oisyn

Die timer is altijd beter als die van VB6.0 ;) met een preciezie (spell?) van 55 ms. GetTickCount of iets dergelijks moet je gewoon gebruiken..
.oisyn Moderator Devschuur® @Anoniem: 1368635 juli 2006 17:30
GetTickCount heeft anders ook maar een granulariteit van 18.2ms, timeGetTime is een iets betere functie. Maar QueryPerformanceCounter gebruikt meestal de TSC of de PCI clock, die hebben een stuk hogere resolutie en zijn essentieel als je microsecondes wilt meten (wat je meestal wilt met profiling, maar daar zijn die functies dus weer te langzaam voor en zit je vast aan de rdtsc instructie)
Zou het alleen voor amd werken?
Ik heb het geïnstalleerd op een Intel Pentium D 920 'ES'.
Zie daarvoor het topic op GoT: AMD Dual-Core Optimizer :)
Ik heb sinds kort ook een dual core, en merk dat vooral oudere spellen soms grote problemen hebben met dual processor systemen. Gelukkig zijn er tooltjes als SetAffinity om aan te geven dat bepaalde processen op slechts één van de 2 cores mag draaien. Ik heb nu de incompatible games op core 0 gezet en achtergrondprogramma's als de firewall en virusscanner op core 1, waardoor er nog zeker een behoorlijke performancewinst te halen is.
Je gebruikt geen windows? In taakbeheer kun je dat gewoon instellen hoor, heb je geen apart programma voor nodig.
Het probleem is dat de taskmanager deze instelling niet onthoudt. Zodra jij je programma afsluit, en daarna weer opstart, staat ie gewoon weer vrolijk op 2 cores ;)

SetAffinity onthoudt het, waardoor je niet elke keer alles opnieuw hoeft in te stellen.
Anoniem: 164619 5 juli 2006 20:34
Geinstalleerd, Windows wilde niet meer goed booten. Sloot af bij het starten van de programma's.

System Restore heeft het gefixed, geen Dual Core Optimizer voor mijn X2 3800+ dus. :'(
Ik heb ook een X2 3800+, maar heb er totaal geen problemen mee!

1. Welke socket heb je?
2. Welk mobo heb je?
3. Heb je de AMD processor driver installed?
4. Heb je de MS Dual Core fix installed?

Mijn situatie

1. Socket 939
2. Abit KN8 SLI
3. Ja
4. Nee
Waarom brengt AMD eigenlijk alleen een fis uit door dualcore cpu's terwijl single core cpu's met cool&quiet ook een gedeelte van het probleem zouden moeten kennen?
Het gaat om het verschil in timing tussen de twee cores.

Op dit item kan niet meer gereageerd worden.