Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 63 reacties
Bron: AMD, submitter: J3roen

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
Moderatie-faq Wijzig weergave

Reacties (63)

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.
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.
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)
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.
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..
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)
Theorethisch kan dit tooltje ook performance verslechtere, een instructie om de waarde van de teller uit te lezen is aardig sneller, als in plaats van die instructie een workaround wordt uitgevoerd....

Ben ik overgens ook de enige die zich afvraagt waarom de processor clocksnelheid zo belangrijk zou zijn om te weten voor een applicatie?
anders krijg je van die uber speed spellen die ook in het 80086 tot 486 tijperk hadden.

* the_virus begint oud te worden... :)
Aaahh, nostalgie! We hadden vroeger thuis een XT met een 8088. Die liep standaard op 4,77 MHz, maar als je de magische toetscombinatie Alt-LShift-RShift aansloeg, schakelde hij naar 8 MHz! Dat was gewoon té snel voor Digger, Striker en Paratrooper :Y)
KIJK
Dat kan dus met dual cores ook }:O

Ehm, oops, wel een beetje verkeerd om dan :7

/ontopic
Deze fix lijkt mij dus om ook dit soort dingen op te lossen. Sommige spellen wouden nog wel eens crashen met meldeningen dat mijn CPU op -10Ghz liep.
Commodore 8088 XT werkte zelft via een software van 4,77 naar 10 MHz te forceren. Opstarten van het gehelen BIOS en MSDOS booting proces was meer dan 5x sneller.

Ik had toen 5 maanden nodig om de turbo optie te gebruiken,via een klein software programma die speciaal voor de commodore pc gebedoelt was.. Omdat er geen turbo knop was.
Maarja dat was al jaren geleden, was een van me eerste goed werkte pc's.

Zelfs buurman was onder de indruk dat ik deze meer dan 2x sneller had gemaakt. Hij bezitte zelf een Pentium 1, 100 MHz, maar hij wist echt niet dat die commodore sneller kon dan 4,77 MHz . Hij had die toen voor me geinstalleerd.
Paratrooper! BRILJANT! Ik had vroeger last dat Operation Wolf te snel ging wanneer ik de Turboknop gebruikte; de bewegingssnelheid van mijn 2knopsmuis verdubbelde haast :P
de TSC is een counter die elke cycle telt. Om dat om te zetten in seconden moet je dus delen door de kloksnelheid van je CPU. De problemen die het nieuwsartikel naar voren brengen zijn dat 2 cores verschillende counters hebben (en lees je ineens een hele andere counter uit als je thread toevallig op de andere core wordt gescheduled - op de meeste OSen en ook Windows kun je er echter programmatisch voor zorgen dat je thread maar op 1 bepaalde core draait) en dat de snelheid van je CPU kan varieren naar verloop van tijd (bijvoorbeeld wegens hitteproblemen of gewoon om stroom te sparen als hij uit z'n neus staat te eten). Games lezen dan eenmalig de CPU snelheid uit, en gaan daar vervolgens mee rekenen terwijl de counter een variabele snelheid aanneemt.
Zolang er geen games en programmatuur voor wordt geschreven, hou ik het gewoon bij 1 core.
de eerste games met hyperthreading/dual-core ondersteuning zijn er al (had Quake 4 niet een patch die ervoor zorgde dat 2 cores beter gebruikt konden worden?)
Zeker nooit met dualcore of HTT gewerkt? Je hebt echt geen idee hoe een verademing dat is. Alles is lekker responsief, alles loopt gewoon soepel. Met singlecore is dat wel ff anders, of je moet met prioritisering gaan rommelen, maar zelfs dan werkt dualcore nog soepeler.
Als je nu upgrade, is het naar mijn mening niet echt slim om een singlecore systeem aan te schaffen.

Ik denk sowieso dat je op het moment beter niet kunt upgraden, met de Directx10 kaarten die er aankomen e.d. Natuurlijk is deze business continue aan het ontwikkelen, maar nu is het wel heel erg.
Ik kwam er toevallig ook op toen in zaterdag nieuwe C'n'Q drivers wilde downloaden. Ik d8 wat raar, niks van gelezen.

Waarom staat die download eigenlijk bij 64/FX en niet bij X2 categorie ?
x2 heeft het "bugje" niet.
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.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True