Archief - [DISCUSSION] AMD Toledo
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
apa
Legacy Member
Verwacht maar niet te veel van dual-core voor desktop toepassingen!
Dual-core processoren geven hetzelfde effect als dual-processor (SMP) systemen. Om performance-winst te halen uit een SMP-systeem, moet de software daar specifiek voor geschreven zijn. Dat betekent dat de software op zijn minst al multi-threaded moet zijn en dat is bij games en klassieke desktop-apps gewoonlijk niet het geval.
Een thread is een deel van een programma dat als 1 geheel (= atomair) kan uitgevoerd worden. Een multi-threaded programma is een programma die met meerdere threads werkt. De verschillende threads moeten zo gedefinieerd worden dat ze perfect tegelijk kunnen uitgevoerd worden. Dat betekent dat die threads volledig onafhankelijk van elkaar moeten kunnen werken.
Klassieke voorbeelden van thread-definities vinden we terug in server-toepassingen. Neem bijvoorbeeld een web-server. Je zou in dit geval 1 thread kunnen definiëren per openstaande connectie. Als 1 connectie wordt gemaakt met de web-server, dan wordt de request voor die connectie door 1 thread afgehandeld en kan dat volledig onafhankelijk gebeuren van andere connecties/threads.
In een desktop-applicatie is dit veel moeilijker te bepalen. Neem bijvoorbeeld een game. Alles wat gebeurt in een scene is afhankelijk van hetgeen daarvoor gebeurd is. De verschillende verwerkingen zijn dus nauw met elkaar verbonden en geen goede kandidaten voor opsplitsing in meerdere threads.
Wat je wel zou kunnen is het in-game menu systeem in een aparte thread laten draaien dan de game zelf. De vraag is alleen of je daarmee veel performance wint: hoeveel performance kost dit menu-systeem immers t.o.v. de game zelf?
Bovendien is een dual-core systeem voor een groot deel ook minder efficiënt dan een SMP-systeem met 2 processoren; zeker als je een Toledo zou vergelijken met een dual-Opteron. In een dual-Opteron heeft iedere processor de beschikking over 6,4 GB/s bandbreedte naar het eigen geheugen en nog eens 3,2 GB/s bandbreedte naar het geheugen van de andere processor. In een dual-core Toledo moet iedere core hetzelfde pad naar het geheugen gebruiken en wordt 6,4 GB/s dus gedeeld door de 2 cores.
Voor de K8-architectuur is dit verlies aan bandbreedte echter veel minder erg dan voor Intel's Netburst-architectuur in dual-core opstelling: in tegenstelling tot de Netburst-architectuur, is de K8-architectuur helemaal niet zo bandbreedte-hongerig. Er wordt geschat dat een K8-core aan ongeveer 60% van de beschikbare bandbreedte genoeg heeft. De resterende 40% van de bandbreedte is dus luxe (in single-core opstelling) en dat betekent een extra kost waar je geen winst uit haalt. Een 2de core zou deze resterende bandbreedte wel mooi kunnen benutten waardoor de volle 100% van de bandbreedte gebruikt wordt. Zoals je wel merkt, zullen beide cores elkaar wel nog voor zowat 20% van de tijd elkaar in de voeten lopen, maar dit wordt niet als erg aanzien.
Dual-core systemen hebben het bijkomend voordeel dat ze veel goedkoper zijn als klassieke dual-processor SMP systemen (als je naar de totale kost van het systeem kijkt tenminste). In een SMP-systeem moet je immers ook de extra kost meerekenen van het SMP moederbord en wat gewoonlijk veel hoger is dan het kostenverschil tussen single-core en dual-core.
Dual-core processoren geven hetzelfde effect als dual-processor (SMP) systemen. Om performance-winst te halen uit een SMP-systeem, moet de software daar specifiek voor geschreven zijn. Dat betekent dat de software op zijn minst al multi-threaded moet zijn en dat is bij games en klassieke desktop-apps gewoonlijk niet het geval.
Een thread is een deel van een programma dat als 1 geheel (= atomair) kan uitgevoerd worden. Een multi-threaded programma is een programma die met meerdere threads werkt. De verschillende threads moeten zo gedefinieerd worden dat ze perfect tegelijk kunnen uitgevoerd worden. Dat betekent dat die threads volledig onafhankelijk van elkaar moeten kunnen werken.
Klassieke voorbeelden van thread-definities vinden we terug in server-toepassingen. Neem bijvoorbeeld een web-server. Je zou in dit geval 1 thread kunnen definiëren per openstaande connectie. Als 1 connectie wordt gemaakt met de web-server, dan wordt de request voor die connectie door 1 thread afgehandeld en kan dat volledig onafhankelijk gebeuren van andere connecties/threads.
In een desktop-applicatie is dit veel moeilijker te bepalen. Neem bijvoorbeeld een game. Alles wat gebeurt in een scene is afhankelijk van hetgeen daarvoor gebeurd is. De verschillende verwerkingen zijn dus nauw met elkaar verbonden en geen goede kandidaten voor opsplitsing in meerdere threads.
Wat je wel zou kunnen is het in-game menu systeem in een aparte thread laten draaien dan de game zelf. De vraag is alleen of je daarmee veel performance wint: hoeveel performance kost dit menu-systeem immers t.o.v. de game zelf?
Bovendien is een dual-core systeem voor een groot deel ook minder efficiënt dan een SMP-systeem met 2 processoren; zeker als je een Toledo zou vergelijken met een dual-Opteron. In een dual-Opteron heeft iedere processor de beschikking over 6,4 GB/s bandbreedte naar het eigen geheugen en nog eens 3,2 GB/s bandbreedte naar het geheugen van de andere processor. In een dual-core Toledo moet iedere core hetzelfde pad naar het geheugen gebruiken en wordt 6,4 GB/s dus gedeeld door de 2 cores.
Voor de K8-architectuur is dit verlies aan bandbreedte echter veel minder erg dan voor Intel's Netburst-architectuur in dual-core opstelling: in tegenstelling tot de Netburst-architectuur, is de K8-architectuur helemaal niet zo bandbreedte-hongerig. Er wordt geschat dat een K8-core aan ongeveer 60% van de beschikbare bandbreedte genoeg heeft. De resterende 40% van de bandbreedte is dus luxe (in single-core opstelling) en dat betekent een extra kost waar je geen winst uit haalt. Een 2de core zou deze resterende bandbreedte wel mooi kunnen benutten waardoor de volle 100% van de bandbreedte gebruikt wordt. Zoals je wel merkt, zullen beide cores elkaar wel nog voor zowat 20% van de tijd elkaar in de voeten lopen, maar dit wordt niet als erg aanzien.
Dual-core systemen hebben het bijkomend voordeel dat ze veel goedkoper zijn als klassieke dual-processor SMP systemen (als je naar de totale kost van het systeem kijkt tenminste). In een SMP-systeem moet je immers ook de extra kost meerekenen van het SMP moederbord en wat gewoonlijk veel hoger is dan het kostenverschil tussen single-core en dual-core.
eniac
Legacy Member
apa zei:
Hallo technologie: eerst de hardware, dan de software. Uiteraard gaan we er in het begin nog niet veel gebruik van kunnen maken, dat is altijd zo als er iets nieuws verschijnt. Zowel in de videokaart wereld als in de CPU-wereld.
Uiteindelijk komt er dan meer en meer support voor, wordt er meer en meer software voor uitgebracht en kom je in een situatie waarin je wel degelijk veel winst eruithaalt.
Kan het alleen maar toejuichen. En iedereen die zegt dat het overkill is: "512KB RAM is toch meer dan genoeg?"
apa
Legacy Member
eniac zei:
Je kan gelijk hebben, maar ik kijk naar HyperThreading die eigenlijk vergelijkbaar is met dual-core werking: dat is een technologie die al even op de markt is, waar ook redelijk wat software voor geoptimaliseerd raakt, maar waarbij de performance-winst slechts zeer beperkt is.
Dual-core is natuurlijk wel beter en makkelijker te ondersteunen dan HyperThreading (bij DC mogen de threads identiek zijn terwijl ze bij HT verschillend moeten zijn), maar het punt blijft dat de meeste desktop-toepassingen en games slechts moeilijk aan te passen zijn voor dual-core werking.
Een van de zaken die ik mij wel kan inbeelden is dat je je PC voor meerdere toepassingen simultaan gaat gebruiken: zoals een HDTV-stream laten afspelen terwijl je een game speelt; of een game-server waarop je tegelijk ook nog speelt; ...
Ik ben ook niet tegen vooruitgang, ik wil enkel opmerken dat DC lang niet zo'n enorme vooruitgang zal zijn voor desktop machines als voor workstations en servers (waar het dus wel een reuze stap voorwaarts is).
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.