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 , , 33 reacties
Bron: AnandTech, submitter: John_Glenn

AnandTech, The Tech Report en [H]ard|OCP hebben een interview gehad met Fred Weber, de CTO van AMD. In het uitgebreide interview legt Fred Weber uit wat AMD in de toekomst waarschijnlijk gaat doen op het gebied van processors. Hij legt onder andere uit wat er aan de huidige K8-architectuur kan worden verbeterd, want dat blijft de basis, gezien zijn uitspraak: "The K8 is here to stay". Ook geeft hij zijn visie op de Cell-processor en AMD's plannen op het gebied van notebooks.

*De K8-architectuur

Fred WeberNet als Intel ziet AMD meer toekomst in TLP dan ILP. Met andere woorden, de toekomst zijn multi-coreprocessors. AMD besteedt dan ook de meeste aandacht aan oplossingen om meerdere cores met elkaar samen te laten werken. Toch is er nog ruimte om iedere core sneller te laten werken. Hierbij kan er gedacht worden aan het verhogen van de klokfrequentie, maar ook aan zaken als verbeterde branch prediction, een lagere geheugenlatentie en het combineren van instructies. Het is dus mogelijk dat in de toekomst een verbeterde K8-core gebruikt gaat worden die een langere pipeline heeft dan de huidige K8-core, zodat deze op een hogere kloksnelheid kan lopen. Deze core zal een verbeterde branch predictor hebben en meerdere cores op een processor zullen waarschijnlijk gebruik gaan maken van een gedeeld L3-cachegeheugen om de geheugenlatentie te verkleinen.

*De Cell-processor

Weber denkt net als Justin Rattner van Intel dat de architectuur van de Cell-processor nog niet geschikt is om toegepast te worden in pc's. Het eerste probleem is dat deze processor bestaat uit ťťn core die alle instructies kan uitvoeren en een aantal kleinere cores die alleen specialistische instructies kunnen uitvoeren. Om hier efficiŽnt van gebruik te maken, moet software met een speciale compiler worden gecompileerd. Dit levert een probleem op voor de huidige software die al bestaat voor het x86/IA32-platform. De oplossing voor dit probleem bestaat uit gebruik van meerdere identieke cores die allen alle instructies kunnen uitvoeren. Dit is echter niet haalbaar met de huidige productiemethoden.

*Turion 64

De optimalisaties die AMD heeft aangebracht in de Turion 64-processor bestaan vooral uit het gebruik van transistors die minder energie verbruiken. Het nadeel hiervan is echter dat de transistors minder snel kunnen schakelen. Een echte Pentium M-killer zal de Turion 64 op de korte termijn dan ook niet worden. AMD werkt ook aan een mobiel platform, vergelijkbaar met Intel's Centrino. Hierbij zal elk onderdeel vanuit het oogpunt van mobiliteit worden ontworpen en geen energiezuinige versie van een bestaand desktopcomponent zijn. Veel meer wilde Weber hierover niet zeggen, behalve dan dat het ontwerpcentrum in Japan een grote rol speelt in de definitie van dit platform, dat ook de naam Turion zal gaan dragen.

Moderatie-faq Wijzig weergave

Reacties (33)

Over de Cell-processor:
Om hier efficiŽnt van gebruik te maken, moet software met een speciale compiler worden gecompileerd. Dit levert een probleem op voor de huidige software die al bestaat voor het x86/IA32-platform.
Alle instructies voor een processor -in wat voor taal dan ook- worden vertaald naar microcode, deze microcode is voor elke processor anders.
De microcode van een Intel processor is dus niet hetzelfde als de microcode voor een AMD processor.
Een instructie uit een hogere taal, bijvoorbeeld C++, wordt eerst vertaald naar assembler of machinetaal.
Deze machinetaal wordt in de processor verder vertaald naar nog simpelere instructies, de microcode.

Het is dus mogelijk om een compiler te schrijven die de x86 instructies vertaalt naar assembler voor de Cell processor, dit zal niet altijd even efficiŽnt gebeuren maar met de meeste instructies zal het geen problemen veroorzaken. Als het klopt dat de architectuur van de Cell processor zoveel sneller is dan die van de x86 dan zal een goede compiler het zeker mogelijk maken om bestaande software veel sneller uit te voeren dan de huidige generatie x86 processoren.

Er zijn nu emulators voor de C64, Gameboy, ZX Spectrum en andere beruchte computers uit het verleden die en een heel OS nabootsen maar uiteindelijk ook de code van bijv. de Z80 (ZX Spectrum) omzetten naar x86 code.
De reden dat deze emulators niet altijd even snel zijn is dat ze niet op compiler niveau hun werk doen maar er een compiler wordt nagebootst op het niveau van een hogere programmeertaal.

Als de Cell processor doet wat men beweert komt er ongetwijfeld een Cell PC.
Ik weet niet wat je bedoeld maar je verhaal van microcode klopt niet helemaal. C++ wordt gecompileerd naar (uiteindelijk) machinetaal en die machinetaal bevat instructies.
En hoe de CPU die instructies intern afhandeld is voor het systeem bijzaak.
Microcode is niet meer dan een tabel dat die instructies vertaald naar interne opdrachten die deze instructie moeten realiseren. En dus puur voor die ene processor samen gesteld. En dus een andere stepping van een CPU zal een heel andere microcode kunnen hebben.
Maar door de volgorde van die instructies slim te kiezen kun je de CPU zichzelf zo laten instellen dat ze optimaal presteert. Bijv de branche prediction wordt dan beter omdat de compiler helpt om de prediction nauwkeuriger te maken.
Maar een Cell CPU is een hele andere CPU dan een x86. En zal ook een afwijkende instructieset hebben. De term x86 duidt al op het feit dat die processoren allemaal dezelfde instructieset aankunnen.
Een Cell processor zal misschien ook andere memory controller en een andere BIOS nodig hebben.
En als een Cell of cluster van Cell proc's een x86 instructieset aankunnen plus het BIOS hier ook op aangepast is zullen deze pas ook x86 gecompileerde software aankunnen. Maar als die niet speciaal voor de Cell processor (in een dialect) worden gecompileerd zal de prestatie niet optimaal zijn.

De enige uitzondering hierop zijn de Transmeta's chips die on the fly van microcode kunnen veranderen en dus ook op dat moment een andere instructieset aankunnen.
Of bepaalde instructies optimaler intern kunnen vertalen. En bijv minder stroom verbruikt. Maar dan nog licht het er maar net aan hoever het BIOS diverse talen toelaat.
Als het klopt dat de architectuur van de Cell processor zoveel sneller is dan die van de x86 dan zal een goede compiler het zeker mogelijk maken om bestaande software veel sneller uit te voeren dan de huidige generatie x86 processoren.
Alleen als de architectuur ook een efficiente automatische vertaling mogelijk maakt. Dit is echter niet het geval.
in prenciepe zou eventueel een ander OS al genoeg zijn, maar hou er rekening mee dat een gewone aplicatie ondanks alles nog steeds enkel threaded is, dus er zal een app slecht op zijn hoogst 1/8 van de rekenkracht gebruiken.....maar verder, een nieuwe versie linux met ondersteuning voor de instructie set / ISA / asembly code
(altivec/VMX maar dan anders...) zou genoeg moeten zijn om in elke geval linux apps te draaien, jammer dat OSsen nog steeds geen fatsoenlijke standaarden hebben opgebouwd om alles echt portable te maken, Java was ghoed bedoelt, en het ligt niet aan de taal, maar het idee is niet geslaagd vanwege de OS-sen, voor Cell zou eigenlijk een nieuwe generatie OS-sen en talen nodig zijn....maar zoals ik al zei, als linux de instructie set maar ondersteund, kun je hem al gewoon gebruiken.
"Alle instructies voor een processor -in wat voor taal dan ook- worden vertaald naar microcode, deze microcode is voor elke processor anders.
De microcode van een Intel processor is dus niet hetzelfde als de microcode voor een AMD processor."

Ik denk dat hier ene fout wordt gemaakt.
de eerste x86 waren pure Cisc CPU. houd in de alu vraten wat er uit het geheugen werd opgehaald aan opcode en operand.
later x86 CPU weet niet meer van af welke zijn intern een risc CPU maar doen zich naar buiten voor als een CISC. De Decode stage naar microcode is gewoon de vertaal slag van Cisc(complex instructie) naar Risc (meerder simple instructie set)

Dus micro code is iets van de latere iNtels ik dacht ergen rond de 80386/P3 werdt die stap gemaakt.

Nu is de vraag hoe het met andere CPU zit zoals pure Risc CPU
ik vraag me af wanneer we de eerste details over K9 gaan horen :) dit klinkt verder toch veelal als een logisch verhaal..
De dual core is K9.
Het K9 project hebben ze doorgeschoven naar K10, de nieuwe cpu's die we begin 2006 mogen verwachten.
ik denk nog wel later als de K8 de standaard word net als een P4 een standaard wer en alleeen maar verbeterd is en net als een Athlon XP
K9 is synoniem voor hond... ik weet niet of ik een hond in m'n POD of computer wil vinden.
trouwe en volgzame beestjes met een giganties uithoudings vermogen.
wel eigenschappen die goed zijn om tehebben voor een cpu niet?
Wat ik me afraag is of AMD en/of Intel op korte termijn plannen hebben om lager te gaan dan de huidige 90nm.
Iets dat ze vast niet graag verklappen :)
Je die plannen hebben ze. Zowel Intel als AMD zijn daar ook al mee bezig. 65nm technologie. Intel is al wel verder als AMD.
Intel is al wel verder als AMD.
Alleen kwa grote van productieproces. AMD's van 130m, doen niet onder voor Intel's 90nm(denk aan Prescott). De Pentium M is echter wel een goeie 90nm-cpu... maar nog niet echt beschikbaar voor desktop ;)
Ik zou graag willen zien dat de chips iets groter worden zodat het geheugen op de chips kan worden gezet en er zieke bandbreedtes en superlage latencies kunnen worden gehaald! De dimm slots kunnen dan weg en blijft er veel meer ruimte over om makkelijk dual cpu borden te maken.

Budget : 1 cpu slot
Mainstream 2 cpu slots
Server: 4 of meer

Er zouden ook altijd 2 versies van elke snelheid moeten zijn, 1 met bijvoorbeeld 512MB en eentje met 1024MB, of ook nog een server versie met uber veel ram.

Het enige wat dan verder mooi zou zijn is dat het systeem en OS om kan gaan met processoren van vershillende snelheden. Dan kun je makkelijk upgraden door je traagste cpu telkens te vervangen met een betere.

De enige gebuikers die hier niets aan hebben zijn de grote database servers met 32GB ram bijvoorbeeld, hievoor zou een aparte memory controller op het moederbord kunnen worden gebruikt (in de northbridge) en dat het on-chip geheugen als L3 cache gaat werken.

We hebben laatst ook nog gehoord over Physics Co-processors, als die socket compatible zouden zijn kunnen die misschien in een socket. (betere integratie in het systeem dan op de PCI-E bus)

Dat was m'n verlanglijstje ;)
Heb jij pasgeleden een bank overvallen dat je zulke wensen hebt? Ga er maar van uit dat als ze dit maken dat het voor de meeste mensen (ook tweakers) niet meer te betalen is hoor
Fijn, we zitten al met warmte problemen en ga jij ook nog eens je geheugen in je CPU bakken. Nog meer warmte. Dan mogen ze ook wel standaard een vries kist meegeven om je PC in te doen.

Plus dat zo een oplossing niet te betalen is, zoals whizzy81 al zei.
K8 lijkt erg op K7, en is zelfs in niet alle vlakken een verbetering, K8 heeft een net iets langere pipeline, en als dat bij de K8-2 nog erger wordt........

Pentium4 is gefaalt vanwege zijn lange pipeline, K7 won dankzei zijn korte, net als Pentium-M

K8-2 zal nog steeds amper vooruitgang zijn op K7 van jaren terug, Pentium-M is gebasseerd op P6 van de Pentium Pro Pentium 2 en Pentium !!!(3).....Het schiet neit echt hard op in processorland......Mischien toch tijd voor nieuwe ISA's, en grote veranderingen dit keer, zelfs 64bit is niet genoeg om de trage vooruitgang goed te maken.
Pentium 4 is gefaalt vanwege zijn lange pipeline
De Pentium 4 architectuur is inderdaad een doodlopende weg, maar dit heeft niks met de langere pipeline te maken, maar met te grote warmteontwikkeling bij een hogere clock. Een pipeline is niets meer en niets minder dan een sorteermechanisme voor instructies; welke instructies moeten in welke volgorde worden uitgevoerd, waar moeten resultaten worden opgeslagen, etc. etc. Het langer maken van een pipeline betekent feitelijk het toevoegen van extra stappen in dit sorteermechanisme, waardoor elke stap in dit proces an sich simpeler wordt. Een simpelere stap kan dan weer sneller worden uitgevoerd waardoor de kloksnelheid omhoog kan. Een hogere klok gaat dus altijd gepaard met een langere pipeline. Dit is dus niet een fysieke tunnel of zoiets.
je kon er nauwelijks verder naast zitten,

meer warmte komt ondermer door die langere pipeline, en niet zozeer door hoge clocks.
Warmte ligt vooral aan de transistors die gebruikt worden, het voltage wat erop gezet worden.

Op arstechnica verglijken ze pipelines met auto-assemblages werkplaats, het idee is dat iedere stage met zijn eigen ding bezig is en vervoglens dat werk doorgeeft aan de volgende stage en nieuw input van de voorgaande stage krijgt, op het moment dat je het aantal stages in een pipeline vergroot duurt het langer voor dat iets klaar is, en is de processor met meer dingen tegelijker tijd bezig, hier staat tegenover dat de simpelere stages op hogere clocks kunnen draaien.

Netburst bevat pipelines die niets anders doen dan zorgen dat de signalen door blijven komen (drive-stages) Netbrust had 20 pipelines, P6 had er een stuk of 7/8 RISC heeft er een stuk of 4, K7 10 (integer, voor floatingpoint zijn er minder nodig), K8 12 (integer, voor floatingpoint zijn er minder nodig) Prescot heeft er 31 Pentium-M een stuk of 11.

De Pentium4 Northwood (2e incarnatie van de Netburst ) heeft een redelijke branchpredictor, maar de ware kracht haalt hij uit het idee van de ultra snelle L1 cache, wat ze voor de prescott vertraagd hebben....

Dit zijn allemaal pure rekentechnische gedachten, in werkelijkheid spelen cache en geheugen een zeer grote rol in hoe snel iets wordt uitgerekent, met een uitzondering, PiFast, dat is een van de weinige apps die erg veel voordeel heeft van een goede core, K7 wint er meestal nog steeds (bartons dan).....
Ik denk dta er ergens een sweet spot is kwa beste aantal stages tov IPC klokschaling.
AMD kan meer stages implementeren en dan nog zal de NEtburst een extreem stages beest blijven.

als AMD van 10 naar 12 naar 15 gaat lijkt veel maar is weinig tov de huidige prescott. die meer stages heeft dan de eerste generatie netburst cores en die waren al extreem. van 20 naar 30 ?
De p4 had vooral te kampen met nogal wat pipeline-stalls. Deze komen door een slechte/mindere branch prediction. En aangezien de pipeline erg lang was (32 stages meende ik, kan anders zijn) heeft dit nogal een nadeel.

Amd had er met de k8 17 voor zover ik weet dus ze zitten nog lang niet aan de aantallen van de p4. Bovendien is de predicion blijkbaar al beter, en wordt hij nog beter. Ik neem aan dat ze nu rond de 90%, maar hoger is beter.
De pipeline van de K8 is 12 stages tegen 10 voor een K7, valt dus wel heel erg mee. (weet niet of dit voor INT of FP is, er is er ook een van 17 geloof ik ja)
Maar door de betere branche prediction en andere verbeteringen doet een K8 het op dezelfde clock nog steeds zo'n 15% beter als een K7.
allemaal goed en wel die nieuwe snufjes van processoren... Grotere kloksnelheden, meer rekenkracht... Hoe zit het eigenlijk met de koelingen? Kunnen we deze beestjes aan, want ik kan me wel voorstellen dat ze zich zelf opfokken in hun rekenen en dus redelijk warm worden...

B-)
Het is dus mogelijk dat in de toekomst een verbeterde K8-core gebruikt gaat worden die een langere pipeline heeft dan de huidige K8-core, zodat deze op een hogere kloksnelheid kan lopen.
Ik hoop niet dat ze dezelfde weg gaan bewandelen als P4 van Intel, want in mijn optiek klinkt dit erg als de kenmerken van een P4.. of zit ik er dan naast?
Een echte Pentium M-killer zal de Turion 64 op de korte termijn dan ook niet worden.
Ik vond het al zo'n maffe foto, van die man met zijn grijns. Eigenlijk zegt hij niets, volgens mij. Hij is vooral heel stralend gelukkig in de zin van: "my 15 minutes of fame! Mag ik ook? Mag ik ook een keertje?" ;)

Cell nog niet klaar voor de toekomst? Tsja..
Cell als multi unicore? Tsja..
Klinkt alsof hij nog niet goed heeft gekeken naar de wijze van benaderen in een Cell.
Bij een CISC processor wordt een instructie verder vertaald naar microcode m.b.v. een tabel.

Een RISC processor doet dit niet.

Een x86 is onstaan uit het CISC tijdperk, doch is intern een RISC. Maar daar komt veel meer bij kijken.

Voor een goede naslag raad ik iedereen aan de 'bijbel' betreffende dit onderwerp te lezen: "Computer Archtitecture: a quantative approach" by Hennesy & Patterson. Zeer goed boek, up to date in de 3e editie, standaard werk voor iedereen die een goede basis in processor hardware architecturen wil hebben.

edit: typo
Zouden die nieuwe Turions dan de Turion2 zijn of de Turion M(obile)?
idd maar ik hoop dat de grens van 4GHZ kunnen bereiken.
dat moet toch mogelijk zijn op een of andere manier?
idd maar ik hoop dat de grens van 4GHZ kunnen bereiken.
Volgens mij moet AMD eerst nog door de 3 ghz grens.
Het gaat niet er niet om op hoeveel GHz een cpu loopt, het gaat er om hoeveel meer een nieuwe CPU per clockcycle kan doen. Waardoor het aantal GHz gewoon laag blijft waardoor dan dus ook de temperatuur en de energie-verbruik laag blijft

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