Veel cache kost veel chip-oppervlak, wat een chip veel duurder maakt om te produceren. Waarschijnlijk is dat de paar procent extra performance niet waard, en zou je bijvoorbeeld veel meer performancewinst kunnen boeken door er een 2e core bij te zetten op dezelfde chip. Daar komt nog bij dat Athlon-achtigen door hun architectuur niet eens zo vreselijk veel winst halen uit extra cache. Zie bijvoorbeeld het performanceverschil tussen de Thoroughbred en de Barton, wat ondanks de verdubbeling van de L2 cache in de regel toch niet echt vreselijk schokkend was.
En vergeet niet dat een Athlon-achtige een exclusieve cache heeft, waardoor de effectieve cachegrootte uitkomt op L1+L2. Dan is 1152KB aan cache plotseling niet eens zo beroerd...
Misschien moeten ze de beide L1 caches vergroten naar 2x 256KB... Dan kom je uit op 1530KB aan cache...
[edit: verhaaltje over cache en chipoppervlak uitgebreid]
[edit]
@TigeriS: Bottomline is natuurlijk altijd wat je terug krijgt voor je investering. Als je de L2 cache op een K8 verdubbelt, neemt het chipoppervlak met grofweg 50% toe, maar de prestaties gaan niet evenredig omhoog. Een 2e core kost minder oppervlak en levert waarschijnlijk meer prestaties op.
Ik meen nog ergens in een interview met een hotshot van AMD gelezen te hebben dat ook AMD aan een variant van hyperthreading werkte, dus wie weet gaan ze zoiets ook nog toepassen. Bij Intel vroeg die aanpassing ook maar een paar procent chipoppervlak, terwijl de prestaties er met -1% - +20% op vooruit gaan. Da's pas waar voor je geld!
Een dergelijk voordeel geldt ook voor de implementatie van AMD64.
Ik ben wel met je eens dat voor K7 die 64-bits bottleneck naar de L2 waarschijnlijk de prestatiewinst van een grotere L2 negatief beïnvloed. Dat is inderdaad één van de bottlenecks in het K7 design die met K8 opgelost zijn. En dan levert een grotere cache meer winst op.
Het wegvallen van de FSB lost niet alle problemen op op het gebied van geheugentoegang. Er is nl. nog steeds een bottleneck, en da's het datapad naar het geheugen. Voor zowel K8 als P4 geldt dat DDR-SDRAM (of welke vorm van RAM ook) een maximale output heeft, alleen heeft AMD de latency flink weten te verkleinen door de northbridge te integreren.
Latency is inderdaad erg belangrijk voor een L1 cache, dat ben ik helemaal met je eens. Al met al blijft het natuurlijk een afweging: als je latency iets toeneemt is dat niet per definitie negatief voor de totale performance van de processor. De toegenomen latency voor de L1 moet je namelijk afwegen tegen de afgenomen kans dat je naar de L2 (met een nog hogere latency) moet. Op zich een "simpel" rekensommetje, maar ik ben wel met je eens dat ze bij AMD best kunnen rekenen en waarschijnlijk niet voor niets weer voor 2 keer 64KB zijn gegaan.
[/edit]
[edit2: goeie discussies zijn altijd leuk!
]
@TigeriS: Uiteraard zijn ze (gelukkig) bij AMD niet helemaal gek.
2e core was een voorbeeld van wat je met zo veel chipoppervlak kunt doen om de prestaties op te krikken. Als je de plaatjes van een Opteron bekijkt zie je dat die 1MB cache qua oppervlak groter is dan de core...
HTT is inderdaad afhankelijk van de software, en in het bijzonder van het OS. Maar goed, iemand moet ergens beginnen. Als je geen processor bouwt met HTT support, komt er ook geen software voor. Zelfde geldt/gold voor MMX, 3DNow!, SSE, SSE2, AMD64, etc. etc. Om jou maar eens om de oren te slaan met je eigen stellingen (hopelijk niet al te erg uit hun verband gerukt):
Zo kan je altijd blijven zeggen dat het geen nut heeft.
In de regel zijn processorfabrikanten de "kippen" die het "ei" leggen...
Het belangrijkste nadeel is dat een techniek als HTT ook negatief kan werken. Overigens geldt dat voor meer cache ook (zij het in mindere mate), want zoals je zelf al aangaf heeft een grotere cache in de regel ook een hogere latency...
Jou betoog zou je zelfs zonder meer kunnen houden voor toenames in de cachegrootte (waar deze discussie ooit over begonnen is).
Stel je moet een algoritme schrijven voor een probleem, en je optimaliseert dit algoritme voor een cachegrootte van 256KB. Als je dan een processor tegenkomt met een 2 keer zo grote cache, zal dit algoritme daar niet heel erg van profiteren. En in een grotere cache past misschien net die optimalisatie van het algoritme waarmee het probleem in de helft van de tijd oplost kan worden. Dan ga je natuurlijk je programma herschrijven, want je wilt natuurlijk ook van die grotere cache gebruik maken.
Software volgt hier dus toch weer de processorarchitectuur.
offtopic:
Wat is eigenlijk de maximale lengte van een post?
[/edit2]
De Clawhammer-cores met 1MB L2-cache worden momenteel zowel op Socket 754 (Athlon 64) als op Socket 940 (Athlon 64 FX) geleverd. De tot nu toe bekende planning luidde als volgt: in het tweede kwartaal van 2004 zou de Clawhammer voor high-end desktopsystemen migreren naar het Socket 939-platform, ondertussen het Socket 754-platform nog steeds bedienend (codenaam San Diego). Daaronder zouden dan eind 2004 K8-cores op de markt komen met 256KB L2-cache die van x86-64-instructies verstoken zouden zijn op Socket 754, Paris (130 nm) en Victoria (90 nm) genoemd. Vanuit het Franse gerucht geredeneerd zou dan de Newcastle-variant met 512KB L2 cache de huidige dubbelrol van de Clawhammer over kunnen nemen voor het middensegment, met een scherpere prijsstelling.
:strip_icc():strip_exif()/u/67678/crop57e119e58e2d8_cropped.jpeg?f=community){kind=small}
/u/83539/crop5f929c0524984_cropped.png?f=community){kind=small}
/u/18715/1.JPG?f=community){kind=small}
:strip_icc():strip_exif()/u/6511/icoon%2520t.net.jpg?f=community){kind=small}
:strip_exif()/u/23403/wicky55.gif?f=community){kind=small}
/u/10064/leuk_he.png?f=community){kind=small}
:strip_icc():strip_exif()/u/85689/crop65fb0c2ca2763_cropped.jpg?f=community){kind=small}