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 , , 26 reacties
Bron: x86-secret.com, submitter: T.T.

De Franse geruchten- en nieuwssite x86-secret.com beweert van een insider te hebben vernomen dat AMD zijn processorroadmap voor volgend jaar heeft aangepast, door de inpassing van twee nieuwe K8-varianten. De eerste variant wordt Newcastle genoemd, zou 512KB L2-cache meekrijgen gebakken op een 0,13 micron-procédé, in het tweede kwartaal van het volgend jaar opduiken, en zowel op Socket 754 als 939 leverbaar worden. Later dat jaar zou deze dan worden opgevolgd door een 90 nm-versie op Socket 939, voorlopig Winchester gedoopt.

AMD logoDe 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.

Of het allemaal in de planning zit valt natuurlijk te bezien, maar dat AMD dergelijke opties overweegt of openhoudt is niet uit te sluiten. AMD geeft geen commentaar op dergelijke geruchten, maar zegt in het algemeen roadmaps aan te passen aan de marktsituatie. Hieronder een tabel met de geruchte core-introducties:

CodenaamSocketProcédéL2-cacheAMD 64Release
Clawhammer754/940130 nm1MBJaQ3 2003
Clawhammer939130 nm1MBJaQ2 2004
Newcastle754/939130 nm512KBJaQ2 2004
San Diego93990 nm1MBJaH2 2004
Winchester93990 nm512KBJaH2 2004
Paris754130 nm256KBNeeQ4 2004
AMD Fab 30 cleanroom dude met wafer

Update: Inmiddels is de nieuwe roadmap officiëel gepresenteerd.

Lees meer over

Gerelateerde content

Alle gerelateerde content (27)
Moderatie-faq Wijzig weergave

Reacties (26)

Wel vaag als AMD er nu voor kiest om niet-64-bit chips op socket 754 te introduceren. Wat ik van de berichtgeving begrepen heb is dat het nauwelijks extra chipoppervlak kost om 64-bit in een chip te bakken, dus... Naar mijn mening moet AMD juist in zoveel mogelijk segmenten die AMD64 introduceren om zoveel mogelijk draagvlak te creëren voor de software boeren. Als ze dat niet doen blijft AMD64 alleen voor de high-end, en dat kan niet de bedoeling zijn...

edit:

@Who Am I?: Tja, misschien heb je gelijk. Paris zal ongetwijfeld de goedkoopste processor op socket 754 worden. Het enige belangrijke verschil tussen Hammer en de verschillende vroegere Athlons is dat de basis-instructieset voor de vroegere Athlons hetzelfde is. Het gaat alleen om toegevoegde extensies als SSE, waar relatief simpel omheen te werken is door dat soort instructies dan maar expliciet uit te voeren. Voor AMD64 ligt dat wat moeilijker, want de toevoegingen zijn veel fundamenteler. Als AMD64 vervalt kun je geen 64-bits programma's en besturingssystemen meer draaien, en daar is geen workaround voor. En zeker omdat het nauwelijks extra kost om die AMD64 ondersteuning in de chip te houden zou ik het als ik AMD was niet doen... Een goedkope Paris-core met AMD64 ondersteuning zou namelijk AMD64 introduceren in de onderkant van de markt, wat mij taktisch slimmer lijkt. Maar inderdaad, het zijn maar geruchten... :) Hopelijk is AMD slimmer.
(+ een typo)
Nou kijk, sinds niet iedereen zoveel geld heeft, is de paris misschien een goedkopere en dus toeganglijkere processor, toch op 754 bord met geintergreerde memory controllerop de processor, wat dus maakt dat er misschien meer borden voor AMD 64 komen.

dat terwijl je niet perse een 64 bit en dure processor wilt hebben maar gewoon een goeie, maar toch zo'n moederbord wil , is het misschien een mooie low budget processor.

maar sinds het geruchten zijn zou ik het niet te serieus nemen, maar als die processor komt snap ik dat wel..je hebt toch ook veel verschillende cores voor Athlon XP? voor ieder wat wils..
en zo'n moederbpord is niet zo duur?
Dj - dat zou best kunnen, maar dan nog, dan zouden ze niet per se gelijk andere versies laten lekken alleen maar om de aandacht van die aangepaste versie af te halen?... of wel?

ert- das een goed punt, maar dat zegt niks.. dat wijst er misschien nog extra op dat het een low budget processor word..

ytsmabeer- zo'n moederbord zijn nu nog vrij duur, maar ze zijn ook nog vrij nieuw... ik denk dat die prijzen wel zullen gezakt zijn eer die processors uit zijn... en hopelijk ook gemeengoed geworden ;)
Het is ook gewoon een 64-bitter. Het is dat alleen uitgeschakeld. Het zorgt voor een extra stimulans om ook goedkope mobo te maken voor deze socket. En de mobo's zijn nu nog wel duur maar dat komt de processors op dit moment ook top of the bill zijn. Een el cheapo mobo er onder is als de banden van een dafje onder een ferrari.
Het zullen gewoon de processors uit een niet zo goede batch zijn. Misschien de cache niet helemaal ok (vandaar maar 256) Maar wel met een memory controllor.
De Franse geruchten- en nieuwssite x86-secret.com beweert van een insider te hebben vernomen dat AMD zijn processorroadmap voor volgend jaar heeft aangepast, door de inpassing van twee nieuwe K8-varianten.
Een "insider" die gewoon even de nieuwe roadmap op de AMD site heeft bekeken ? Staat alle informatie, plus nog meer, op ! :D
Ik had liever een K8 chip met 2MB L2 of meer gezien.. Dat zou nog meer performance boost geven.
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]
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.
Zo kan je altijd blijven zeggen dat het geen nut heeft. K8 is een andere architectuur dan wij gewend zijn. De bottleneck ligt op dit moment bij het geheugen omdat die niet op de processor's kloksnelheid kan lopen.
En daarom heeft het veel meer nut dan bij bijvoorbeeld een Pentium 4. Daar blijft de FSB altijd een beperkende factor.

Je kan wat je weet over de Pentium architectuur niet vergelijken met de K8, dat zijn 2 totaal verschillende culturen.
Daar komt nog bij dat Athlon-achtigen door hun architectuur niet eens zo vreselijk veel winst halen uit extra cache
Dat kwam omdat de K7 een 64bit Cache datapad heeft en nog steeds vast zit aan een "slome" FSB.
De K8 heeft wat dat betreft veel meer speelruimte, waarom denk je dat AMD voor 1MB L2 heeft gekozen ? Intel wilt bijvoorbeeld volgend jaar DDR2 gaan gebruiken, maar omdat de FSB op 800MHz blijft, heb je niet erg veel aan DDR2. Maar omdat de K8 "geen" FSB heeft, dan zal het meer voordeel geven.
Misschien moeten ze de beide L1 caches vergroten naar 2x 256KB... Dan kom je uit op 1530KB aan cache...
Juist niet, dan wordt de latency hoger, en die moet juist zo laag mogelijk zijn.
@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 ben het half met je eens. Maar AMD weet heus wel wat kan en wat niet. Wij kunnen slechts denken en vinden.. :)
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! .
Hier ben ik het niet mee eens en wel omdat je sterk afhankelijk bent van software support, hoeveel software is nou HTT geoptimaliseert ? Dat zijn bar weinig, dus het is misschien wel goedkoper om te implementeren, maar wat heb je eraan als er geen software voor is ? En mijn "oude software" dan ? Niet iedereen koopt gelijk de nieuwste versie van software.
Ik heb liever oplossingen die gelijk voor alle software winst oplevert ipv specifieke gevallen.

En voor de rest ben ik blij met jou gediscusseerd te hebben. Hopende u voldoende te hebben geinformeerd verblijf ik...

En met vriendelijke groet.. ;)
Ja, maar AMD heeft niet van die grote wafers, dus dat zou erg duur worden en de bruikbare aantallen c.q. yields omlaag drukken.
Het is voor AMD duurder om grote wafers te gebruiken op dit moment. En qua yields zal dat reuze mee vallen. Dankzij de betere prestaties kunnen ze meer geld voor vragen, en dus de kosten dekken.
Het is voor AMD duurder om grote wafers te gebruiken op dit moment
Juist, en daarom zitten ze met het probleem van duur silicicon per chip. Hoe groter de chip (bijv. door meer cache), hoe groter dat probleem wordt. AMD moet zoveel mogelijk chippies per wafer zien te behalen, en dat doen ze door de cores zo klein mogelijk te ontwerpen.
En qua yields zal dat reuze mee vallen.
Oh? En heb je daar ook nog een onderbouwing voor?
Dankzij de betere prestaties kunnen ze meer geld voor vragen, en dus de kosten dekken.
Tsja, kosten dekken is één ding; veel chips bakken tegen lage prijzen om marktaandeel te kunnen pakken een andere. Zijn de prestaties van de K8 t.o.v. de Netburst-architectuur nu niet goed genoeg hè? Tsja...
Juist, en daarom zitten ze met het probleem van duur silicicon per chip. Hoe groter de chip (bijv. door meer cache), hoe groter dat probleem wordt. AMD moet zoveel mogelijk chippies per wafer zien te behalen, en dat doen ze door de cores zo klein mogelijk te ontwerpen.
Nou AMD maakt de cores altijd juist express iets groter omdat je anders met warmte probleem komt te zitten. Er komt veel meer bij kijken dan zo goedkoop mogelijk produceren. Goedkoop is vaak duurkoop.
Oh? En heb je daar ook nog een onderbouwing voor?
jij voor je beweringen ? ;) Ik wel, zoals altijd :)

http://www.tweakers.net/nieuws/24126/?highlight=AMD+APC
Tsja, kosten dekken is één ding; veel chips bakken tegen lage prijzen om marktaandeel te kunnen pakken een andere.
Als de prestaties indrukwekkend genoeg zijn dan zullen mensen met verstand van zaken die chips niet laten liggen. Opteron doet het bijzonder goed in de HPC markt, en dan kan het zonder problemen uit om iets meer te vragen.
Zijn de prestaties van de K8 t.o.v. de Netburst-architectuur nu niet goed genoeg hè? Tsja
Netburst ? Alleen mensen die niet zo technisch zijn zijn onder de indruk van Netburst. Het zegt nl meer dan het in werkelijkheid is. Voorbeeld, als je naar de specificaties kijkt, dan lees je 3.2GHz/ 800MHz FSB, HTT en noem maar op. En toch kan een FX51 @2.2GHz in de meeste benchmarks sneller zijn.

Stel je had geen verstand van computers, zou het dan niet logisch zijn dat de 3.2GHz veel sneller dan de 2.2GHz moeten zijn ?

En nog iets, pak welke versie van 3DS Max die je wilt, allemaal zullen ze sterk presteren op een Athlon FX, echter als je een Netburst processor hebt dan moet je de laatste versie kopen anders heb je er gewoon slechte prestaties.

Ik vind de prestaties van Opteron/FX vele malen beter dan netburst, het ging mij meer om de verhouding met Itanium 2, want dat is pas relevant in de HPC markt.
dat zou enkel een boost geven in zwaar cache-afhankelijke apps. En hoeveel apps gebruiken echt meer dan 128 KB L1 en 1024 KB L2?

Je mag in dit opzicht de P4 niet vergelijken met de A64. De laatste heeft een totaal andere architectuur en kan ook rekenen op een ingebouwde mem controller die zeer snelle geheugentoegang mogelijk maakt. Zowieso: hoe sneller de geheugentoegang (bij een voldoende bandbreedte), hoe minder cache-afhankelijk de CPU is.

edit:
OK, had de sub-msg's niet gezien
Heel eerlijk, ik kan wel wat dingen verzinnen die het beter doen met een grotere cache. Best lekker als je voor bijvoorbeeld motion compensation tijdens het comprimeren van een MPEG-video-tje een stapeltje beeldjes met de benodigde statistische info kwijt kunt in de cache. :) Of een multi-tasking server met 400 actieve processen die allemaal een hun stukje geheugen het liefst in de cache willen hebben... Het is een kwestie van tijd voordat er programma's komen die optimaal gebruik weten te maken van 1024+128KB cache. Zo ook voor 2048+128KB cache, of 6MB zoals een Itanium kan hebben. :) Kwestie van aanbod, de vraag komt vanzelf. 640KB is immers voldoende voor iedere denkbare toepassing... ;)
Mag ik een stomme vraag stellen?
Waarom zijn die wafers cirkels?
Je kan op die wafer van het plaatje alle
cores van de buitenste ring wel wegpleuren
als ze zo incomplete zijn...
Ik weet dat deze wafers van een grote cillinder gesneden worden (net als worst). Bovendien meen ik me te herinneren uit een gastcollege van een kerel van ASML dat deze schijven ook draaien in de chipoven.

Bovendien lijkt het me nauwelijks mogelijk om een vierkante/rechthoekige wafer zo precies van vorm te maken dat je helemaal geen resten overhoudt.
het antwoord dat je noemt klopt wel, maar is niet de oorzaak.
Bij het bewerken van een wafer tot processor (of meerdere) worden er verschillende technieken gebruikt. Bijvoorbeeld het opdampen van lagen, en het weg-etsen van lagen. Dit moet natuurlijk zo egaal mogelijk gebeuren. In het midden gaat het alleen altijd iets harder/lanzamer dan aan de randen. Je kunt de wafer die in één keer behandeld wordt dus net zo groot maken als de circel waarin deze snelheidsafwijkingen zo klein zijn dat het voor het uiteindelijke werking niet uitmaakt*. Aangezien deze processen van nature in een circelvorm het werken (denk aan stoomdamp van een fornuis op een raam, deze beslagen ruiten zijn ook nooit in vierkanten beslagen) zijn de Wafers (en de Si-"worsten") ook rond gemaakt.
Als je alles dus vierkant maakt, dan kan je dat vierkant dus alleen zo groot maken als het vierkant dat IN de huidige circel past, en dus gooi je dan productiecapaciteit weg.

Bij het bakken in een oven zet het Si overigens ook nog eens uit. Een rond ontwerp heeft dan vanwege egale vorm het minste kans op barsten (denk wel aan n/u-meter niveau) bij het te snel opwarmen en afkoelen.

* het buitenste van een wafer wijkt vaak wel iets van de ideale situatie af, en daarom worden de "snelste" processoren meestal uit het midden gehaald, terwijl de langzamere broertjes uit de rand worden gesneden.
Er staat een behoorlijke verhandeling over waarom wafers rond zijn in een reactie op http://www.tweakers.net/nieuws/29229 dus misschien is dat wel wat. Lijkt trouwens wel behoorlijk op het antwoord van narotic, dus... :)
Ok, wafers zijn rond omdat er op diemanier makkelijk ronddraaiend substraten op worden gesmeerd.

Maar waarom zijn de chips dan niet 6 hoekig/in een honingraat stuctuur geplaatst op de wafer? dat levert toch veel minder verlies op aan de randen?
Hrm vaag die roadmap. Waarom introduceren ze een 130nm nog in Q4 '04 terwijl ze in Q2 dat jaar al de 90nm hebben. Want hoe kleiner hoe beter.
Om dezelfde reden dat ze nu nog durons bakken; voor de onderkant van de markt en minder rijke gebiedsdelen vermoed ik. De tools hebben ze dan nog. En 'as market requires' geldt ook hierbij.
Weet het niet zeker, maar heb een verhaal gehoord dat er zelfs 486's nog worden gebakken. Schijnt vraag naar te zijn voor oudere systemen in vliegtuigen en dat soort complexe systemen.

"as market requires" idd
Volledig correct.
Soekris bijvoorbeeld heeft een heel gamma aan 486 netwerk-hardware :)
http://soekris.kd85.com/
Zou het uitstellen van de "aangepaste" XP 64 editie hiervan invloed kunnen zijn ???
Het probleem met de cache verhogen van b.v. 1mb naar 2mb, is naast het feit dat de chip idd met zo'n 50% groter wordt (en het % geslaagde core's per wafer voor meer dan 50% gaat afnemen), nog steeds een slecht idee, omdat de tijd om 2mb via extra logica multiplexers (en vergeet niet alle ECC handelingen, zo'n cache is echt heel complex) aan te spreken veel langer wordt, en de CPU die tijd dus 'uit zijn neus staat te eten'. Kortom niet alleen de chip wordt groter, afhankelijk van de implementatie van de cache controller per architectuur, zou de snelheid van de processor misschien nog wel drastisch afnemen met een grotere cache.

Nog even om op een andere reactie in te gaan, iemand vroeg 'Hoeveel apps gebruiken nou die 1.5 mb cache'. Nou je cache op je processor staat altijd vol, en als het ff kan dan zien we graag het hele werkgeheugen en nog mooier de hele harddisk in de cache :). Kortom je cache op de processor staat altijd vol.

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