Hoofdcategorieën

[RSS] Index » Nieuws » Core » Software » AMD brengt 'Dual-Core Optimizer' uit

AMD brengt 'Dual-Core Optimizer' uit

Door René Wichers, woensdag 5 juli 2006 17:02
Bron: AMD, submitter: J3roen, views: 34.040

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
Volgende 17:22
Vorige 16:12
Gesponsorde link
Arjen (House) logo Besparen op uw ICT?

Categorieën

Gerelateerde content

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 63 reacties zichtbaar630 Off-topic / Irrelevant: 63 reacties zichtbaar63+1 On-topic: 54 reacties zichtbaar54+2 Informatief: 9 reacties zichtbaar9+3 Must-read: 0 reacties zichtbaar0
«  1  2  3  »

Door BitBooster, woensdag 5 juli 2006 17:08

Score: 2
Aan te bevelen is dan om geen cool'n'quiet te draaien tijdens gaming

Door Bulls, woensdag 5 juli 2006 18:34

Score: 1
tijdens een hoogwaardige game is het eerder Hot'n'Loud als je lucht koeling gebruikt ;)

Door poepkop, woensdag 5 juli 2006 21:38

Score: 1
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.

Door Parasietje, woensdag 5 juli 2006 17:08

Score: 2
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...

Door schnitzelcore, woensdag 5 juli 2006 17:12

Score: 1
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.)

Door ShadowLord, woensdag 5 juli 2006 17:38

Score: 2
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.

Door Bulls, woensdag 5 juli 2006 18:35

Score: 0
dat was in de tijd dat je met de turbo knop nog een game kon versnellen. hoezo 3dkaart nodig :Y)

Door TheekAzzaBreek, woensdag 5 juli 2006 21:21

Score: 1
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.

Door .oisyn, woensdag 5 juli 2006 17:10

Score: 2
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)

Door MBV, woensdag 5 juli 2006 22:30

Score: 2
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.

Door .oisyn, woensdag 5 juli 2006 23:02

Score: 1
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 ;)

Door MBV, woensdag 5 juli 2006 23:12

Score: 2
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 :)

Door EWK, woensdag 5 juli 2006 17:11

Score: 0
En zo is het dual/multicore systeem nog niet helemaal waterdicht.

Ik wacht er nog maar even mee, ten eerste omdat het nog duur is. Maar ten tweede (en vooral) omdat er nog kleine fouten en dergelijke in zitten.
En tja, virusscannen en gamen tegelijk...? Nog niet echt nodig voor een gewone consument. Pas als er over een paar jaar meer gecompliceerde programma's zijn zul je echt rendement halen. Als ik nu moest kiezen ga ik toch liever voor een snelle AMD 64 4000+ dan (bijvoorbeeld) een X2.

Door RazorBlade72nd, woensdag 5 juli 2006 17:21

Score: 1
Ik haal zo'n 30% prestatie winst met Falcon 4.0, een F-16 flightsim.

Door Jan Groothuijse, woensdag 5 juli 2006 17:32

Score: 1
Dual multicore is noodzakelijk vanwege de te traag oplopende schakelsnelheid van transistors, en het feit dat die transistors inmiddels klein genoeg zijn om het commercieel haalbaar te maken.

x86 is orgineel gemaakt voor een 16bit ALU op een 8bit databus, er zijn wel meer dingen die wij er in de tussentijd mee gedaan hebben die voor kleine bugjes hebben gezorgt, ik vind het tot nu toe vrijwel vlekkeloos gaan met de x86 dual core processors (als mede omdat x86 SMP systemen met meerdere processoren natuurlijk al wel langer bestonden en wel die kinderziekte al gehad hebben, maar toch...).

Door PaddoSwam, woensdag 5 juli 2006 17:15

Score: 1
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..

Door .oisyn, woensdag 5 juli 2006 17:30

Score: 2
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)

Door r.marijnissen, woensdag 5 juli 2006 17:19

Score: 1
Zou het alleen voor amd werken?

Door Thandor, woensdag 5 juli 2006 18:57

Score: 1
Ik heb het geïnstalleerd op een Intel Pentium D 920 'ES'.
Zie daarvoor het topic op GoT: AMD Dual-Core Optimizer :)

Door Jan Groothuijse, woensdag 5 juli 2006 17:28

Score: 1
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?

Door flippy.nl, woensdag 5 juli 2006 17:38

Score: 1
anders krijg je van die uber speed spellen die ook in het 80086 tot 486 tijperk hadden.

* the_virus begint oud te worden... :)

Door j0bro, woensdag 5 juli 2006 19:58

Score: 1
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)

Door Aapenootjes, woensdag 5 juli 2006 20:41

Score: 1
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.

Door mysterieworld, woensdag 5 juli 2006 23:23

Score: 1
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.

Door deavatar, donderdag 6 juli 2006 15:42

Score: 1
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

Door .oisyn, woensdag 5 juli 2006 23:08

Score: 1
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.

Door MMaster23, woensdag 5 juli 2006 17:35

Score: 1
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 ?

Door flippy.nl, woensdag 5 juli 2006 17:39

Score: 1
x2 heeft het "bugje" niet.

Door Dumbo, woensdag 5 juli 2006 18:00

Score: 1
Oh nee?

http://www.amd.com/us-en/...,30_182_871_13118,00.html

:Z

Door flippy.nl, woensdag 5 juli 2006 18:09

Score: 0
niet goed gelezen, sorry, ben nog neit helemaal wakker... :Z

Door Tyrian, woensdag 5 juli 2006 18:14

Score: 1
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.

Door Patriot, woensdag 5 juli 2006 23:09

Score: 1
Je gebruikt geen windows? In taakbeheer kun je dat gewoon instellen hoor, heb je geen apart programma voor nodig.

Door Clawz, donderdag 6 juli 2006 00:14

Score: 1
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.
«  1  2  3  »

Op dit item kan niet meer gereageerd worden.

Volgende 17:22
Vorige 16:12
VNU Media logo Hosted by True

© 1998 - 2009 Tweakers.net - Alle rechten voorbehouden - Uw Privacy - Algemene Voorwaarden

Uitgever van: