Archief - AMD A64 K8L/65nm procede 2007--BIG INFO thread

[Gothrek]

weet ik, ik lees XS ook

[Zahur]

weet ik, ik lees XS ook

xs?

[Gothrek]

-Menthor- da zijde gij toch, getuigen van de hele copy paste van uit deze thread in die thread

[apa]

terwijl er nog maar amper dual core aplicaties zijn

Klopt... en ik zie daar niet meteen verandering in komen aangezien het erg moeilijk is om een single-user applicatie doeltreffend te laten genieten van een (of meer) extra core(s).

Om gebruik te kunnen maken van meerdere cores moeten applicaties multi-threaded geschreven zijn. Een thread is een eenheid van executie en moet als 1 geheel uitgevoerd worden. Een enkele thread kan dus niet door 2 cores tegelijk uitgevoerd worden. De meeste single-user applicaties zijn dan ook single-threaded...

Als je wat rondneust, zal je merken dat veel single-user applicaties wel meerdere threads gebruiken. In dat geval gaat het echter meestal om zgn. "helper-threads": zo zal je applicaties vinden met een aparte thread die de menu-structuur beheert terwijl de applicatie zelf in een andere thread draait.
Om echt te kunnen genieten van de extra core(s), moeten de threads echter ongeveer even CPU-intensief zijn... Voor single-user applicaties is het bijzonder ingewikkeld om de code zo op te splitsen.

Wanneer dat echter wel gelukt is, en je hebt de code van je applicatie wel kunnen opsplitsen in meerdere threads, dan zal je applicatie ook meteen vrij goed opschalen naarmate je meer cores toevoegt.

Waar je dat het beste ziet is in server-apps. Daar kan je per user een thread definiëren. Aangezien alle users op ieder moment dezelfde opvragingen kunnen doen, zijn alle threads grosso-modo even zwaar. Met dat soort toepassingen stijgt de capaciteit van de server vrij sterk naarmate er meer cores beschikbaar zijn.

idd, ze maken niets voor niets een dual core he

Zeer zeker niet... Maar geloof maar niet dat dat voor de desktop gedaan werd. Multi-core systemen zijn vooral interessant voor servers (zie ook mijn uitleg hierboven) omdat het veel goedkoper is om 2 dual-core CPU's te gebruiken om 4 threads tegelijk te kunnen verwerken dan om 4 single-core CPU's daarvoor te gebruiken.

Omdat de technologie al gecreëerd werd voor servers, is het dan ook maar overgebracht naar de desktop...

Memorycontroller die meerdere types ondersteund...
Vergeef me, maar dan denk ik meteen aan 915P die voor zowel DDR als DDR2 suckt.
Ze moeten toch de nadruk kunnen leggen op 1 bepaald type? Lijkt me nogal hard om beide types volledig te ondersteunen.

Dat kan perfect wanneer je ze niet allebei tegelijk op 1 bord wil kunnen gebruiken; en dat zal ook niet de bedoeling zijn in de K8L... Wil je dat wel doen, dan krijg je zgn. "routing-issues" waardoor de traces tussen memory-controller en geheugen minder goed gelegd worden en je dichter op de limieten van het toelaatbare aanleunt wat betreft signalisatie.

Is het ook gekend voor wat die coprocessors precies zullen zorgen?
FPU, GPU, PPU, ... ?

Dat kan vanalles worden. De bedoeling is het systeem erg schaalbaar te maken zodat iemand met sterke eisen wat betreft floating-point berekeningen (wetenschappelijk onderzoek, rendering, ...) meer kan investeren in FPU-power (eventueel meerdere FPU's installeren). Ik vermoed dat de GPU wat minder vaak in die sockets zal geprikt worden (die vereisen immers massa's bandbreedte die moeilijk te bieden valt doorheen de socket(s)).

[Zahur]

65nm sample bolt op 1.25w en heeft een output van 65W..
lijkt me wel hoog

[Den_John]

65nm sample bolt op 1.25w en heeft een output van 65W..
lijkt me wel hoog

srr vr verbereing troman mr kdenk da ge 1.25V bedoeld

eventjes ter vergelijking, een x2 3800+ EE (am2) verbruikt ook 65w dus gaat amd er precies niet echt op vooruit met de overstap naar 65nm

[Zahur]

srr vr verbereing troman mr kdenk da ge 1.25V bedoeld

eventjes ter vergelijking, een x2 3800+ EE (am2) verbruikt ook 65w dus gaat amd er precies niet echt op vooruit met de overstap naar 65nm

idd 1.25V

[Gothrek]

bwa, een X2 zit qua verbruik aan dat van een conroe
staar u niet blind op die TDP's

[Zahur]

bwa, een X2 zit qua verbruik aan dat van een conroe
staar u niet blind op die TDP's

bwha niet dat het verbruik mij enigzins boeit lol , als de bulle ma marcheren ist goed

doch verwacht je een lichte daling met de jump naar 65, nuja we zullen binnekrot wel zien zekers

[apa]

staar u niet blind op die TDP's

Inderdaad... De TDP's van Intel en AMD duiden trouwens op verschillende zaken. Bij Intel wordt het gemiddeld opgenomen vermogen opgegeven terwijl dat bij AMD steeds het maximaal opgenomen vermogen is.

[Gothrek]

Inderdaad... De TDP's van Intel en AMD duiden trouwens op verschillende zaken. Bij Intel wordt het gemiddeld opgenomen vermogen opgegeven terwijl dat bij AMD steeds het maximaal opgenomen vermogen is.

dat bedoelde ik idd, maar apa zijn uitleg is altijd beter

[Den_John]

Enkele foto's en wat info gevonden over 65nm; probleem is dat het int chinees ofzoiets is
anyway => LINK

[RealFlub]

http://babelfish.altavista.com/tr use that, het help (chinees-vereen gebruiken)

[Zahur]

Ik vraag me af in hoevere, die L3 cache voor de superpiers gaat uitdraaien
Totale cache ligt dan rond de 2.5MB niet slecht ^^

[apa]

Ik vraag me af in hoevere, die L3 cache voor de superpiers gaat uitdraaien
Totale cache ligt dan rond de 2.5MB niet slecht ^^

Ik vraag mij af of dat nog veel uitmaakt hoor... SuperPi lijkt mij niet meteen een applicatie die erg veel cache nodig heeft (correct me if I'm wrong) dus ik denk niet dat het toevoegen van L3 cache heel veel zal veranderen voor SuperPi.

Op de K8L wordt het L3 cache overigens toegevoegd om het probleem van cache-coherency tussen de verschillende cores te verlichten (het L3 cache wordt namelijk gedeeld; dit in tegenstelling tot de L2- en L1-caches van de huidige K8)...

[blind_ripper]

Ik vraag mij af of dat nog veel uitmaakt hoor... SuperPi lijkt mij niet meteen een applicatie die erg veel cache nodig heeft (correct me if I'm wrong) dus ik denk niet dat het toevoegen van L3 cache heel veel zal veranderen voor SuperPi.

Op de K8L wordt het L3 cache overigens toegevoegd om het probleem van cache-coherency tussen de verschillende cores te verlichten (het L3 cache wordt namelijk gedeeld; dit in tegenstelling tot de L2- en L1-caches van de huidige K8)...

apa zie eens naar een 6400 en een 6600 , laat ze bijde zelfde speeds lopen enkel helft cache maar tijd is ook trager , superpi is een cache loving bench

[Zahur]

Ik vraag mij af of dat nog veel uitmaakt hoor... SuperPi lijkt mij niet meteen een applicatie die erg veel cache nodig heeft (correct me if I'm wrong) dus ik denk niet dat het toevoegen van L3 cache heel veel zal veranderen voor SuperPi.

Op de K8L wordt het L3 cache overigens toegevoegd om het probleem van cache-coherency tussen de verschillende cores te verlichten (het L3 cache wordt namelijk gedeeld; dit in tegenstelling tot de L2- en L1-caches van de huidige K8)...

1Mb
512kb

= circa 2secs verschil op zelfde speeds

[apa]

1Mb
512kb

= circa 2secs verschil op zelfde speeds

Ja, maar hier hebben we het dan over de overgang van 2 MB naar 4 MB he... Zolang je niet genoeg cache hebt, zal het wat uitmaken als je er wat toevoegt. Eens je er genoeg hebt, zal meer cache niet merkbaar veel uitmaken. Wat ik mij afvraag is of 2 MB voldoende is of niet...

[Zahur]

Ja, maar hier hebben we het dan over de overgang van 2 MB naar 4 MB he... Zolang je niet genoeg cache hebt, zal het wat uitmaken als je er wat toevoegt. Eens je er genoeg hebt, zal meer cache niet merkbaar veel uitmaken. Wat ik mij afvraag is of 2 MB voldoende is of niet...

bwha als ze die latency een pak omlaag krijgen denk ik wel dat het gaat compenseren..