Vergleich VLIW - superskalar; das Ende von Legenden
- Ersteller rkinet
- Erstellt am
BlackBirdSR
Commodore Special
es fallen ja eine ganze Reihe an Befehlen an, für die die beiden FMACs zuständig sind.
Wenn man sich ansieht wie diese versorgt werden, fällt schon auf, dass man Wert darauf gelegt hat das theoretische Maximum der Einheit auch wirklich auszuschöpfen.
Ich hab aber noch nicht auf einem Itanium programmiert, weiss also nicht wie genau das aussieht
Ich weiss auch nicht, in wie fern man an die möglichen 8 single precision Ops/Takt rankommt.
Ansonsten war ja klar, dass der Opteron momentan in Sachen Skalierung bei 2-4 CPUs ganz oben steht.
@blackbirdsr
1. keinen humor?
2. da ich die ganze zeit vom opteron vs. itanium spreche (und sogar von dual-core) ist ja wohl klar, daß ich auch von "spec_rate" rede. alles andere wäre ja lächerlich. woher du deine werte heißt, weiß ich nicht, aber schau ruhig mal hier: http://www.aceshardware.com/SPECmine/index.jsp?b=3&s=0&v=1&if=0&r1f=2&r2f=2&m1f=0&m2f=0&o=0&o=1
3. du sagst: "der opteron hält gut mit - aber er spielt in einer anderen liga." wieso? welche liga? was ist da anders? wenn er gut mit hält, was willst du mehr? was fehlt ihm? um die nähe zu zeigen verwies ich ja auf die spec-benches. und ich habe nie gesagt, der jetzige itanium2 hätte gegen den opteron keine chance, sondern ganz klar sprach ich dabei von einem dual-core opteron.
4. was mir an größerem cache nicht paßt? hm, habe ich deutlich gesagt: größeres, teureres die. und hat ja auch nichts damit zu tun, ob es mit paßt oder nicht, sondern einfach damit, ob es eine sinnvolle strategie ist, einen prozessor mit 24mb l3-cache zu produzieren, oder ob es von anfang an wirtschaftlicher unsinn ist, denn man sich nur erlauben kann, wenn der kunde abhängig wäre. ist er aber nicht - also wird es wohl schwer für intel, eine teurere, heißere cpu an den man zu bringen, wenn es eine billigere, kühlere alternative gibt. und wir diskutieren eben genau darüber: ob der opteron doch noch zu einer alternative gegenüber dem itanium werden kann, oder nicht. wenn intel tatsächlich den weg geht, so ein fettes ei zu legen, dann freut sich nicht intel und nicht der kunde, sondern amd... meine meinung...
5. thema "yield". ich habe schon verstanden, was du meintest. witzig war nur, daß deine erste definition genau die meinige wiederholte, obwohl(!) du sie doch bestritten hattest. ich zitiere dich: "Aber die Yields, und das ist die Anzahl an funktionsfähigen CPUs eines Wafers [...]" na, vielleicht gibt es ja eine definition von yield, die sich nicht auf wafer bezieht (wie du ja meinst, aber eben beim ersten male doch anders sagtest
). nur ist es m.e. ein wenig unsinnig, den verschnitt außen vor zu lassen. für die herstellungskosten sind nun mal die anzahl der (verkaufbaren, also natürlich funktionstüchtigen) cpus pro wafer entscheidend. wenn man schon allein 10% verschnitt hat...nenne es halt yield(real) vs. yield(marketing)
6. im nächsten jahr mit dual-core wissen wir mehr. das intel allein schon den opteron als 64bit konkurrenz bekämpft, muß doch schon bitter für sie sein. ebenso wie das nischendasein des itanium als number-cruncher. ist doch peinlich und hart, wenn die strategische planung für zwanzig jahre geld drucken den bach runter geht. und genau dies passiert doch gerade, deswegen ja intels "nervösität". worüber wir hier ja diskutieren ist nicht mehr die frage, ob amd mit dem opteron den zugang zum server-markt geschafft hat, sondern die frage, wie nachhaltig dies sein wird bzw. wie die position von amd ausgebaut werden könnte. amd hat letztere frage beantwortet mit der ankündigung von dual-core. intel hat eben diese antwort auch - nur immer noch nicht die temp-probleme gelöst. nicht beim p4, damit nicht beim xeon - und eben auch nicht beim itanium2. und in wenigen stunden werden wir sehen, ob intel mit der umsetzung von amd64 im prescott gute arbeit geleistet hat oder nicht. wenn nicht (was nach einigen gerüchten ja so sein soll): fiasko!
1. keinen humor?
2. da ich die ganze zeit vom opteron vs. itanium spreche (und sogar von dual-core) ist ja wohl klar, daß ich auch von "spec_rate" rede. alles andere wäre ja lächerlich. woher du deine werte heißt, weiß ich nicht, aber schau ruhig mal hier: http://www.aceshardware.com/SPECmine/index.jsp?b=3&s=0&v=1&if=0&r1f=2&r2f=2&m1f=0&m2f=0&o=0&o=1
3. du sagst: "der opteron hält gut mit - aber er spielt in einer anderen liga." wieso? welche liga? was ist da anders? wenn er gut mit hält, was willst du mehr? was fehlt ihm? um die nähe zu zeigen verwies ich ja auf die spec-benches. und ich habe nie gesagt, der jetzige itanium2 hätte gegen den opteron keine chance, sondern ganz klar sprach ich dabei von einem dual-core opteron.
4. was mir an größerem cache nicht paßt? hm, habe ich deutlich gesagt: größeres, teureres die. und hat ja auch nichts damit zu tun, ob es mit paßt oder nicht, sondern einfach damit, ob es eine sinnvolle strategie ist, einen prozessor mit 24mb l3-cache zu produzieren, oder ob es von anfang an wirtschaftlicher unsinn ist, denn man sich nur erlauben kann, wenn der kunde abhängig wäre. ist er aber nicht - also wird es wohl schwer für intel, eine teurere, heißere cpu an den man zu bringen, wenn es eine billigere, kühlere alternative gibt. und wir diskutieren eben genau darüber: ob der opteron doch noch zu einer alternative gegenüber dem itanium werden kann, oder nicht. wenn intel tatsächlich den weg geht, so ein fettes ei zu legen, dann freut sich nicht intel und nicht der kunde, sondern amd... meine meinung...
5. thema "yield". ich habe schon verstanden, was du meintest. witzig war nur, daß deine erste definition genau die meinige wiederholte, obwohl(!) du sie doch bestritten hattest. ich zitiere dich: "Aber die Yields, und das ist die Anzahl an funktionsfähigen CPUs eines Wafers [...]" na, vielleicht gibt es ja eine definition von yield, die sich nicht auf wafer bezieht (wie du ja meinst, aber eben beim ersten male doch anders sagtest
). nur ist es m.e. ein wenig unsinnig, den verschnitt außen vor zu lassen. für die herstellungskosten sind nun mal die anzahl der (verkaufbaren, also natürlich funktionstüchtigen) cpus pro wafer entscheidend. wenn man schon allein 10% verschnitt hat...nenne es halt yield(real) vs. yield(marketing) 6. im nächsten jahr mit dual-core wissen wir mehr. das intel allein schon den opteron als 64bit konkurrenz bekämpft, muß doch schon bitter für sie sein. ebenso wie das nischendasein des itanium als number-cruncher. ist doch peinlich und hart, wenn die strategische planung für zwanzig jahre geld drucken den bach runter geht. und genau dies passiert doch gerade, deswegen ja intels "nervösität". worüber wir hier ja diskutieren ist nicht mehr die frage, ob amd mit dem opteron den zugang zum server-markt geschafft hat, sondern die frage, wie nachhaltig dies sein wird bzw. wie die position von amd ausgebaut werden könnte. amd hat letztere frage beantwortet mit der ankündigung von dual-core. intel hat eben diese antwort auch - nur immer noch nicht die temp-probleme gelöst. nicht beim p4, damit nicht beim xeon - und eben auch nicht beim itanium2. und in wenigen stunden werden wir sehen, ob intel mit der umsetzung von amd64 im prescott gute arbeit geleistet hat oder nicht. wenn nicht (was nach einigen gerüchten ja so sein soll): fiasko!
rkinet
Grand Admiral Special
a)
Um EPIC/VLIW steht es nicht gut, weil es auch bei theoretischer Betrachtung ein x64 oder PowerPC Design nicht signifikant abhängen kann.
Für x64 /SSE hat sich AMD an Intels SSE Design hängen 'müssen', beim Vergleich PowerPC und IA64 würden sich die tatsächlichen Unterschiede 'superskalar' zu EPIC zeigen.
b)
Bei SpecFP wirkt sich klar die bessere Fließkommaeinhaiet des IA64 aus. Nur, solche Rechenaufgaben sind auch gut parallelisierbar und Cluster-Domäne, also kein praktischer Vorteil für IA64.
c)
Der 2 MB-L2 beim Dothan bringt Performance 'begünstig' durch den relativ lahmen Bus. Nur Welten auch wieder nicht. Auch dürfte SpecFP praktisch nicht von größerem L2 profitieren.
12 MB statt 6 MB klingt toll, nur muß IA64 das 2-3 fache an Programmcode (vs. x64) dort handhaben und es fehlt die Performancepower von HTr. (Intel könnte durchaus 2-4 MB L3 bei Nocoma-Verwandten einbauen, dann wäre der IA64 Vorsprung hier weg)
Im Normalfall dürfte der 12 MB Cache irgendwo 0-10% an Performance bringen, also keine Revolution.
d)
Bei so großen DIE ist der Ausschuß doch größer, bei dieser Preisgruppe aber akzeptabel. Der Cache kann per Reservezellen wohl weitgehend genutzt werden, die zwei Cores verdoppeln allerdings die Wahrscheinlichkeit eines Defektes.
e)
130nm statt 90nm: Bei Intels 90nm sinkt bei gleichem Takt die absolute Stromaufnahme etwa (-10 bis 20%), nur die spez. Wärmeentwicklung je mm2 verdoppelt sich. Die vielen Funktionseinheiten hätten in 90nm den Chip schlicht überhitzt.
Dieses Problem verschwindet auch nicht bei 65nm, vielleicht gibts eine Chance mit dem von Intel skizzierten low power 45nm Fertigungsprozess.
Der IA64 kann in einigen Bereichen punkten. Auch wird ein Dual-Core IA64 bei Fließkomma x64 deutlich schlagen. In Clustern wird man wohl auch mit ca. 1/2 an CPUs die gleiche Rechenleistung erhalten, wobei hier PowerPC Systeme ähnlich gut liegen. Nur, die Kunden zählen nicht CPUs, sondern das Kosten/Leistungsverhältnis. Hier hat x64 mit seinen 'Massen-CPUs' und entsprechenden Kosten die Nase vorne.
Und, Software muß auch entwickelt werden. Bei x64 und PowerPC gibt es Desktopsyteme dafür, sowas fehlt für IA64. Auch ein Problem.
@Treverer
Die "Weltmachtgelüste" sind in dem Moment zusammengebrochen, als die ISA "PIC" erstmals vor Gericht anerkannt wurde.
Die Schöpfer von PIC hatten derartig grundlegendes geschaffen, dass sie auch bei vielen anderen abkassiert haben (TI, AMD ...) von daher kann Intel gar nicht mehr mit Lizenzen andere Knebeln, da mit PIC-Lizenzen leicht ein AI64-Clone gebacken werden könnte
Selbst wenn der Itanium ein grosser Erfolg wäre, so ist damit schon ein Teil der Strategie weggebrochen
8)
MFG Bokill
Die "Weltmachtgelüste" sind in dem Moment zusammengebrochen, als die ISA "PIC" erstmals vor Gericht anerkannt wurde.
Die Schöpfer von PIC hatten derartig grundlegendes geschaffen, dass sie auch bei vielen anderen abkassiert haben (TI, AMD ...) von daher kann Intel gar nicht mehr mit Lizenzen andere Knebeln, da mit PIC-Lizenzen leicht ein AI64-Clone gebacken werden könnte
Selbst wenn der Itanium ein grosser Erfolg wäre, so ist damit schon ein Teil der Strategie weggebrochen
8)MFG Bokill
rkinet
Grand Admiral Special
tja, ohne Weltmacht-Perspektive wird man IA64 wohl irgendwie dezent beerdigen.
Also 'unsinkbar' mit 24 MB Cache ausstatten und König Eisberg wills halt einfach nicht.
Dann kommt der Duellino mit 64 Bit und Pentium-M Technik und rettet Intel vor der unzuverlässigen Kundschaft.
? Wie schreibt man 1 Milliarde Dollar buchmäßig so ab ?
Also 'unsinkbar' mit 24 MB Cache ausstatten und König Eisberg wills halt einfach nicht.
Dann kommt der Duellino mit 64 Bit und Pentium-M Technik und rettet Intel vor der unzuverlässigen Kundschaft.
? Wie schreibt man 1 Milliarde Dollar buchmäßig so ab ?
RLZ
Captain Special
- Mitglied seit
- 22.02.2003
- Beiträge
- 239
- Renomée
- 5
echt?
Ich würde erstmal abwarten bis ein entsprechender Compiler ausm Betastatus kommt und vernünftig optimierte Software da is. Mir dünkt, dass unter entsprechend optimierter Software der Nocona schneller sein könnte als der Opteron.
Opteron ist halt mehr der solide Allesfresser.
Intel leidet aber wohl auch unter dem Problem, dass wenn man für den P4 optimierte Software für IA64 compiliert, die Performance doch eetttwaass bescheiden ausfällt....
Und Entwickler zu begeistern für noch eine Plattform zu optimieren ist auch nicht so einfach. Zumal die Umbauten dabei doch etwas grösser ausfallen würden.
![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
worüber sprichst du?
ich nehme ein 64bit programm unter linux - vielleicht wieder gimp - und vergleiche den gewinn/verlust von 64bit bei einem opteron mit dem eines nocona - fertig. wie kommst du darauf, daß es bei intel für 64bit irgendwelcher optimierungen bedarf (oder überhaupt gibt)?
ich nehme ein 64bit programm unter linux - vielleicht wieder gimp - und vergleiche den gewinn/verlust von 64bit bei einem opteron mit dem eines nocona - fertig. wie kommst du darauf, daß es bei intel für 64bit irgendwelcher optimierungen bedarf (oder überhaupt gibt)?
rkinet
Grand Admiral Special
Schuld daran ist nur die EU und DD.
Hätte man dem kleinen 'Wicht' AMD nicht geholfen, gäbs heute nur noch Intel -
und Microsoft.
Die Kundschaft wäre klar sortiert, Celeron grob 250$, Pentium 500-1000$
und Server wären alle IA64 für 2500$ und mehr. Alles BTX-geföhnt ...
BlackBirdSR
Commodore Special
nein, den habe ich in den letzten Monaten verloren
Woher habe ich meine Werte wohl? Nur habe ich mich auf die DualSysteme beschränkt, da es ja um DualCore CPUs ging.
Dann musst du aber den DualCore Opteron gegen den DualCore Itanium antreten lassen, was ich seit Beginn an tue.
Schließlich geht es uns ja hier nicht um Geld, Verfügbarkeit oder Rentabilität.
Was ich mit den Ligen meine, wirst du doch sicher erkennen können?
IA64 spielt bei den HighEnd Server, mit wenig Absatz viel Leistung und Kosten spielen keine Rolle.
AMD spielt in der Xeon Liga. Das ist nunmal ein großer Unterschied, so dass Opterons seltenst in direktem Kampf mit Itaniums stehen.
Das ist ja die Frage, ist es eine sinnvolle Strategie oder nicht?
Itanium2 sind scheiss teuer und den Kunden ist das relativ egal. In diesem Segment zahlt man eben so viel. Dementsprechend kann es sich Intel leisten.
Zudem musst du dich echt mal fragen was sinnvoller ist, an einer Architektur ständig rumkleben (siehe Prescott) und damit die Leistungsaufnahme stetig in die Höhe treiben, ohne jedoch signifikante Leistungsgewinne zu erzielen, oder eben den realtiv billigen Cache zu vergrößern?
Zudem die erste Variante die Yields ja maßgeblich beeinflusst, die zweite die Anzahl an defekten CPUs nur geringfügiger ansteigen lässt.
Sorry hier wirst du mir zu konfus und selbstgefällig.
5. thema "yield". ich habe schon verstanden, was du meintest. witzig war nur, daß deine erste definition genau die meinige wiederholte, obwohl(!) du sie doch bestritten hattest. ich zitiere dich: "Aber die Yields, und das ist die Anzahl an funktionsfähigen CPUs eines Wafers [...]" na, vielleicht gibt es ja eine definition von yield, die sich nicht auf wafer bezieht (wie du ja meinst, aber eben beim ersten male doch anders sagtest
Yields sind nunmal die DIEs die man am Ende funktionsfähig ihre AUfgabe erfüllen können.
Maßgeblich bestimmend sind hier Punktdefekte, die während der Fertigung unweigerlich auftreten.
Erhöht man die Anzahl an Logitransistoren proportional (USIV) werden die Yields extrem schlecht.
Erhöht man dagegen hauptsächlich die ANzahl an SRAM Zellen, findet man vergleichen zur Steigerung der Logiktransen viel weniger Defekte im Logikteil.
So einfach ist das, und da hab ich nicht die geringste Ahnung was du mir da sagen wolltest. Probiers einfach nochmal, oder lass es.
Nein, das hier hat mit dem Ganzen überhaupt nichts zu tun.
Mach doch nen neuen Thread auf, wenn du über sowas reden willst.
BlackBirdSR
Commodore Special
Eben
Sehe ich nicht so.
SpecFP hängt hier noch viel mehr von der Speicherbandbreite als von der Gleitkommastärke ab und auch von der Cachegröße. Ein Großteil der Vorteile für Power4 und Itanium2 kommen davon, dass die SpecFP Berechnungen fast ganz in den Cache passen. (Beim Power4 fast mit Sicherheit)
Aber wenn diese Berechnungen nicht eben genau das Berufsfeld des Itanium2 sind, was denn dann? Spiele sind es nicht, Abspielen oder Encoden von DIVX auch nicht.
Strömunsberechnungen, Thermodynamik, Statik etc eben schon!
Das habe ich nichtmal gemeint. Ich dachte dabei an das Speicherinterface und die Northbridge an sich. Mit einem größeren Cache fallen weniger Speicherzugriffe an, wodurch die Stromaufnahme des Systems sinkt. Eine von vielen kleinen Sparmaßnahmen, die sich am Ende zusammenfügen.
Eben nicht, da ein Core nur ca 20Mio Transen hat, ist das auch schon das einzige was sich verdoppelt. Die Chance auf einen Defekt auf jeden fall nicht.
Daher macht es mehr Sinn ne Menge Cache draufzuklatschen als groß am Core zu basteln. Oder hat man hier den Prescott schon vergessen?
Und wo steht das bitte? Dass ein 90nm Prescott nicht überhitzt, ein 90nm IA64 aber schon?
RLZ
Captain Special
- Mitglied seit
- 22.02.2003
- Beiträge
- 239
- Renomée
- 5
Es geht generell um Optimierungen für die Intels(lange Pipeline, entsprechende penalties beachten,etc).
Im 64 Bit Modus ändert sich einiges an den Registern. Hier kann ein Compiler, der dafür ausgelegt ist einiges rausholen. Inbesondere können die Datentröme auf den Prozessor abgestimmt geliefert werden, dass er sich nicht verschluckt. Abgesehen davon hat sich der icc 8.0 nicht sonderlich in der Performance verbessert (nach meiner Erfahrung nach teilweise sogar verschlechtert), sondern wurde in anderen Bereichen verbessert. Von den neuen Versionen erhoffe ich mir dafür neben 64 Bit Unterstützung wieder mehr Performance. Diese werden aber wohl auf eine längere Pipeline optimiert werden...
Gimp als Benchmark zu nehmen ist imo total daneben und bewertet nur die Leistung bei "Nudel"-Code. Dem Opterons schmeckts, den P4´s weniger. Grade im Serverbereich wird für Kunden oft spezielle Software erstellt, die auch oft auf die Intels optimiert ist. Dort werden sie auch mehr Leistung bringen und gekauft werden. Die Allerweltsbenchmarks interessieren Kunden in dem Bereich nicht. Es kommt nur auf die Performance bei ihrer Software an. Und wofür gibts Testsysteme?
Crashman
Grand Admiral Special
Warum muss man immer AMD CPU's auf durchschnittlichem Code mit Intel CPU's auf hochoptimiertem Code vergleichen?
MfG
MfG
RLZ
Captain Special
- Mitglied seit
- 22.02.2003
- Beiträge
- 239
- Renomée
- 5
Les mal von beiden Herstellern die Guides...
Bei den Intels gibts einfach mehr, dass man optimieren kann und dabei wirklich Leistung rauskommt. Andersrum gesehen, gibts bei den Intels halt mehr was man falsch machen kann
Bei normalen Desktop-CPU´s kann man die Messlatte mehr in Richtung unoptimierten Code anlegen. Aber beim Serverbereich, wo die Rechner zur Software gekauft werden brauch man wohl kaum unoptimierte Software zu betrachten.
rkinet
Grand Admiral Special
Intel hat lange gefeilt und auch die Signalführung im Prescott deutlich verändert.
Pro Flächeneinheit hat sich aber die thermische Leistung ungefähr verdoppelt.
Dies ist übrigens bezgl. der Core beim Dothan ähnlich, nur dort sind keine anscheinend kritischen Werte erreicht worden.
Bei IA64 konnte man wohl nichts an der Signalführung verbessern und ist daher auf 130nm Technik geblieben.
Bei Cluster sind IA64 und PowerPC in der Tat je CPU deutlich effektiver.
Nur, schon in 130nm sieht es bei der benötigten Watt-Leistung eines Opteron nicht schlecht aus, die -HE und bedingt -EE Reihe gibt noch weitere Ansätze.
Nachdem es eigentlich fast schon sicher ist, daß die kommende SOI-90nm Opteron-Generation deutlich weniger Strom benötigt und nicht teuerer wird, rechnen sich auch doppelt soviele Opterone wirtschaftlich für einen solchen Cluster.
Und, das x64 Design ist ein Massenprodukt und ermöglichst preiswerte Softwareentwicklungssysteme.
BlackBirdSR
Commodore Special
Sorry ich sehe die Worte, aber der Inhalt erschließt sich mir nicht.
Intel hat beim Prescott die Signallaufzeiten optimiert und es irgendwie geschafft die extrem zu drücken. Damit wäre die Taktschraube in der Hinsicht so gut wie unbehindert. Wäre da nicht da thermische Problem.
Das hat aber mit dem Itanium nichts zu tun, zumindest will mir nicht in den Kopf wie die Signallaufzeiten und 90nm Prozess sich in die haare bekommen sollten.
IA64 ist eine HighEnd Server CPU, mit enormen Preisen und nicht gerade großem Volumen. Zudem sind solche CPUs für 6+ Monate in Evaluierung. Montecito ist ferig, aber vor nächstem Jahr werden wir den nicht sehen.
Deshalb gibt es jetzt nioch keine 90nm Itaniums.
Nicht weil Intel es irgendwie nicht gepackt hat mal schnell umzustellen.
Der Desktopmarkt unterscheidet sich hier eben extrem.
Dresdenboy
Redaktion
☆☆☆☆☆☆
Ich habe mir den Thread mal auf Papier durchgelesen und ein paar Anmerkungen zusammengestellt.
Anzahl der x86-GPRs im 32bit-Mode
Es sind eigentlich 6. Neben EAX bis EDX kann man meist ESI und EDI problemlos verwenden, da nur einige CISC-Relikte wie MOVS diese Register als Index-Register festgelegt haben. Die Compiler machen ebenfalls Gebrauch von ESI und EDI als normale Arbeitsregister. Einschränkungen bei den 6 Registern gibt es hauptsächlich bzgl. einiger Befehle, die nur mit EAX und manchmal zusätzlich EDX arbeiten (z.B. MUL, manche IMUL-Varianten und IDIV).
Yields
Es gibt für eine bestimmte Die-Größe (Höhe, Breite) eine Anzahl maximal möglicher, vollständiger Dice auf einem Wafer. Das "Die Yield" berechnet sich dann daraus, wieviele dieser vollständigen Dice entsprechend den Anforderungen funktionieren. Dann gibt es noch das "Line Yield", welches aussagt, wieviele Wafer den Herstellungsprozess so überstanden haben, daß man von ihnen noch nutzbare Dice gewinnen kann.
Mittlerweile existiert ein Trend bei manchen Herstellern (z.B. AMD und Intel), die Anforderungen etwas zu lockern, um das Die Yield zu erhöhen - hauptsächlich durch Angabe einer max. bzw. typical TDP für eine ganze Prozessorlinie. So kann man auch einen A64 2800+, der bei dem Takt schon 85W max. TDP hat, verkaufen.
Anzahl der x86-GPRs im 32bit-Mode
Es sind eigentlich 6. Neben EAX bis EDX kann man meist ESI und EDI problemlos verwenden, da nur einige CISC-Relikte wie MOVS diese Register als Index-Register festgelegt haben. Die Compiler machen ebenfalls Gebrauch von ESI und EDI als normale Arbeitsregister. Einschränkungen bei den 6 Registern gibt es hauptsächlich bzgl. einiger Befehle, die nur mit EAX und manchmal zusätzlich EDX arbeiten (z.B. MUL, manche IMUL-Varianten und IDIV).
Yields
Es gibt für eine bestimmte Die-Größe (Höhe, Breite) eine Anzahl maximal möglicher, vollständiger Dice auf einem Wafer. Das "Die Yield" berechnet sich dann daraus, wieviele dieser vollständigen Dice entsprechend den Anforderungen funktionieren. Dann gibt es noch das "Line Yield", welches aussagt, wieviele Wafer den Herstellungsprozess so überstanden haben, daß man von ihnen noch nutzbare Dice gewinnen kann.
Mittlerweile existiert ein Trend bei manchen Herstellern (z.B. AMD und Intel), die Anforderungen etwas zu lockern, um das Die Yield zu erhöhen - hauptsächlich durch Angabe einer max. bzw. typical TDP für eine ganze Prozessorlinie. So kann man auch einen A64 2800+, der bei dem Takt schon 85W max. TDP hat, verkaufen.
Dresdenboy
Redaktion
☆☆☆☆☆☆
Original geschrieben von RLZ
Les mal von beiden Herstellern die Guides...
Bei den Intels gibts einfach mehr, dass man optimieren kann und dabei wirklich Leistung rauskommt. Andersrum gesehen, gibts bei den Intels halt mehr was man falsch machen kann
Bei normalen Desktop-CPU´s kann man die Messlatte mehr in Richtung unoptimierten Code anlegen. Aber beim Serverbereich, wo die Rechner zur Software gekauft werden brauch man wohl kaum unoptimierte Software zu betrachten.
Hinter der Entwicklung dieser CPU-Klassen von Intel und AMD stehen zwei im Wesentlichen unterschiedliche Ansätze. Intel konzentrierte sich ursprünglich auf Durchsatz und Taktfrequenz unter der Annahme, daß Code dafür optimiert werden würde (sie haben ja auch ein eigenes Compiler-Team) und daß zu erwartende niedrigere Leistung bei herkömmlichem Code durch die P4-Architekturmerkmale (v.a. die erreichbare Taktfrequenz) ausgeglichen wird.
AMD rechnete dagegen beim K7 nicht unbedingt mit optimierenden Compilern bzw. speziellen Optimierungen für K7, sondern hatte als Ziel, vorhandenen Code (für ältere, aber auch aktuelle CPUs wie PII) möglichst gut auszuführen. Darum kommen K7/K8 mit durchschnittlichem, nicht oder für <=P6 optimierten Code meist gut klar, da die dort geltenden Optimierungsregeln (auf Assembler-Code-Ebene) fast immer auch für K7/K8 günstig sind.
Nun könnte ich weiter fortsetzen, aber möchte nun nur noch auf Folgendes hinweisen:
Auf P4 optimierte Software läuft auf K7/K8 meist langsamer, als z.B. für P6, 486 oder "blend" optimierte, weil z.B. Befehle, die auf AMD CPUs effizient ausgeführt werden könnten, durch längere Konstrukte ersetzt wurden. Der P4 braucht P4-optimierte Software, weil er sonst Nachteile hat, und K7/K8 sollten nicht mit P4-optimierer Software getestet werden.
Für den 32bit-Modus braucht man also keinen speziellen AMD-Compiler. Das kann, wie man sah, der ICC auch sehr gut. Aber ohne ICC hätte der P4 ein Problem. Also kann man da nicht mehr optimieren, sondern man muß, weil es wirklich darauf ankommt.
Genug geschrieben für heute..
Ich bezweifele immernoch, dass der Banias/Dothan eine gute Desktop CPU wird. Die Integer-Leistung ist zwar sehr gut, aber für den Desktop Einsatz müsste Intel die komplette FPU rausreißen und neudesingen. Die stammt noch von P3 Zeiten (leistungsmäßig unverändert - siehe AMBiX Ergebnisse), nur war der P3 nicht auf niedrige Taktraten ausgelegt (eher Mittelfeld).
Ein Dothan 2GHz könnte einem A64 2.2GHz im Desktop Bereich zwar durchaus starke Konkurrenz machen, aber sowie es zu arbeitsintensiveren Sachen (Spiele, Multimedia) geht bricht der Dothan gnadenlos weg.
Ein Dothan 2GHz könnte einem A64 2.2GHz im Desktop Bereich zwar durchaus starke Konkurrenz machen, aber sowie es zu arbeitsintensiveren Sachen (Spiele, Multimedia) geht bricht der Dothan gnadenlos weg.
rkinet
Grand Admiral Special
@BlackBirdSR
Intel hat beim Prescott Funktionseinheiten nicht nach Baugruppen sortiert auf dem DIE angeordnet, sondern unter Aspekten der Signallaufzeit. Die erhöht deutlich die maximal mögliche Frequenz, dürfte aber auch viele 'Hotspots' entschärft haben.
Trotzdem, der Prescott erzeugt im Core bzgl. Fläche die doppelte Wärmeleistung und wird ja auch nach außen deutlich wärmer.
Ein IA64 in 90nm würde eher konventionell geschrumpft werden und hätte auch ca. mit der doppeltem Wärmeleistung je Fläche zu schaffen. Nachdem das Design schon unter 130nm thermisch am Limit ist, erscheinen mir die 90nm nicht machbar.
Erst wenn Intel einen Fertigungsprozess auf die Reihe bekommt, der den Energieverbrauch je Transistor deutlich absenkt und insgesamt wieder eine ähnliche Wärmefreisezung je Fläche eregibt, wäre der Shrink machbar.
Mit IA64 in 90nm könnte Intel die max. Taktrate erhöhen (geringer kap. Widerstände durch kürzere Signalführung) und den Gesamtstomverbrauch auch noch senken.
Darauf zu verzichten, obwohl IA64 TTakt benötigen könnte, kann nur technisch bedingt sein.
Zur Erinnerung, jetzt hängt ein 90nm Pentium-M, ein low power Design, im Takt schon den Itanium ab.
Intel hat beim Prescott Funktionseinheiten nicht nach Baugruppen sortiert auf dem DIE angeordnet, sondern unter Aspekten der Signallaufzeit. Die erhöht deutlich die maximal mögliche Frequenz, dürfte aber auch viele 'Hotspots' entschärft haben.
Trotzdem, der Prescott erzeugt im Core bzgl. Fläche die doppelte Wärmeleistung und wird ja auch nach außen deutlich wärmer.
Ein IA64 in 90nm würde eher konventionell geschrumpft werden und hätte auch ca. mit der doppeltem Wärmeleistung je Fläche zu schaffen. Nachdem das Design schon unter 130nm thermisch am Limit ist, erscheinen mir die 90nm nicht machbar.
Erst wenn Intel einen Fertigungsprozess auf die Reihe bekommt, der den Energieverbrauch je Transistor deutlich absenkt und insgesamt wieder eine ähnliche Wärmefreisezung je Fläche eregibt, wäre der Shrink machbar.
Mit IA64 in 90nm könnte Intel die max. Taktrate erhöhen (geringer kap. Widerstände durch kürzere Signalführung) und den Gesamtstomverbrauch auch noch senken.
Darauf zu verzichten, obwohl IA64 TTakt benötigen könnte, kann nur technisch bedingt sein.
Zur Erinnerung, jetzt hängt ein 90nm Pentium-M, ein low power Design, im Takt schon den Itanium ab.
BlackBirdSR
Commodore Special
Bahnhof sag ich nur.
Du stellst hier die verblümtesten vermutungen auf.
Zur Erinnerung: Die 90nm Montecito SIND FERTIG und sind/gehen richtung OEMs.
Wo steht, dass ein IA64 eher konventienell geschrinked wird?
Montecito erhält einige Verbesserungen, CMT z.B. da müsste man schon ein paar Sachen anpassen, im gleichen Zuge kann man ja auch am Design feilen.
Wo steht, dass das Design bei 130nm am thermischen Limit arbeitet?
Das hieß es doch schon bei der 1.5GHz Version mit 3MB L3 Cache.
Nun gibt es 1.5GHz mit 6MB L3 Cache und bald 1.7 mit 9MB L3 Cache.
Wo steht, dass der Prozess schuld ist an der hohen thermischen Abgabeleistung?
Wir kommen hier an Grenzen der CMOS Fertigungstechnik, und das lässt sich vielleicht nur mit radikalen shrinks verzögern.
Prescott ist vom Design her schon ein Garant für Verlustleistung pur. Dothan nicht.
Dothan hat dann auch anscheinend keine Probeme mit thermischer Verlustleistung.
AMDs K8 scheint das auch nicht wirklich zu haben.
Also?
Intel's 90nm Chips werden nicht kleiner, sondern größer.
Da kannst du diese simple Rechnung nicht mehr andwenden. Dann müssen eben repeater rein, bzw die Mettalisierungsebenen müssen angepasst werden.
Und nochmal, Intel verzichtet nicht darauf.
Der 90nm Montecito DualCore ist bereits aus den Wafern geschnitten. Server CPUs brauchen eben länger als Desktops um evaluiert zu werden.
Ich weiss also gar nicht vonw as du sprichst.
rkinet
Grand Admiral Special
@BlackBirdSR
Habs nochmal recherchiert - ist 90nm Technologie beim Montecito.
Das dürfte wohl so zutreffen, wobei eben hier thermische Überlegungen dann mit eingeflossen sind.
Im Prinzip habe ich aber nur oberflächlich beim IA64 recherchiert - sorry.
Beim Fertigungsprozess Intel und IBM fällt auf (Dothan vs. PowerPC), daß Intel nur etwas an Leistungsaufnahme bei gleichem Takt reduzieren konnte, beim PowerPC wurde der wert fast halbiert. Die Ursache dafür ist simpel: Bei SOI läßt sich die Vcc fast problemlos reduzieren, nur der max. Takt wird dadurch begrenzt.
Intel strained Technologie mit Germanium inside ist hier wesentlich unflexibler. Der Dothan hat ähnliche Vcc Werte /Takt wie der Banias, sogar leicht eingeschränkt. Der Prescott liegt auch auf Northwood-Niveau.
Nun, je höher die Vcc, desto stärker ausgeprägt die Leckströme, daher hat IBM (und auch AMD) hier die Nase vorne. AMD zeigt ja beim laufenden 130nm 'CG' Stepping, daß man selbst unselektierte Desktop-CPUs in Großserie zwischen 1,1 und 1,5 V betreiben kann und die Vcc Werte auch innerhalb der Fertigung konstant hält.
Bei Intel gibt es regelrechte Selektion bei der Vcc für die CPUs, selbst wenn der takt ähnlich ist. Der Fertigungsprozess und das entstandene DIE ist also empfindlich bzgl. Vcc und muß daraufhin optimiert ausgeliefert werden. SOI ist die 'wurscht', je niedriger die Vcc, desto niedriger einfach der max. Takt, verursacht weitgehend durch physikalische Effekte.
In Summe zeigt sich, daß SOI kein IBM-Spielzeug ist, sondern eine geniale Antwort auf ein sonst (fast) nicht beherrschbares Problem. Intel hat bei 90nm Probleme und 65 nm wird keine wesentlichen Veränderungen im Prozess mit sich bringen. Nur bei 45nm hat Intel neue Konzepte angedacht, die aber die max. Taktrate deutlich begrenzen werden.
Die Schere wird in den nächsten Jahren somit aufgehen und Intel verfügt nur über eine problematische Fertigungstechnik.
Habs nochmal recherchiert - ist 90nm Technologie beim Montecito.
Das dürfte wohl so zutreffen, wobei eben hier thermische Überlegungen dann mit eingeflossen sind.
Im Prinzip habe ich aber nur oberflächlich beim IA64 recherchiert - sorry.
Beim Fertigungsprozess Intel und IBM fällt auf (Dothan vs. PowerPC), daß Intel nur etwas an Leistungsaufnahme bei gleichem Takt reduzieren konnte, beim PowerPC wurde der wert fast halbiert. Die Ursache dafür ist simpel: Bei SOI läßt sich die Vcc fast problemlos reduzieren, nur der max. Takt wird dadurch begrenzt.
Intel strained Technologie mit Germanium inside ist hier wesentlich unflexibler. Der Dothan hat ähnliche Vcc Werte /Takt wie der Banias, sogar leicht eingeschränkt. Der Prescott liegt auch auf Northwood-Niveau.
Nun, je höher die Vcc, desto stärker ausgeprägt die Leckströme, daher hat IBM (und auch AMD) hier die Nase vorne. AMD zeigt ja beim laufenden 130nm 'CG' Stepping, daß man selbst unselektierte Desktop-CPUs in Großserie zwischen 1,1 und 1,5 V betreiben kann und die Vcc Werte auch innerhalb der Fertigung konstant hält.
Bei Intel gibt es regelrechte Selektion bei der Vcc für die CPUs, selbst wenn der takt ähnlich ist. Der Fertigungsprozess und das entstandene DIE ist also empfindlich bzgl. Vcc und muß daraufhin optimiert ausgeliefert werden. SOI ist die 'wurscht', je niedriger die Vcc, desto niedriger einfach der max. Takt, verursacht weitgehend durch physikalische Effekte.
In Summe zeigt sich, daß SOI kein IBM-Spielzeug ist, sondern eine geniale Antwort auf ein sonst (fast) nicht beherrschbares Problem. Intel hat bei 90nm Probleme und 65 nm wird keine wesentlichen Veränderungen im Prozess mit sich bringen. Nur bei 45nm hat Intel neue Konzepte angedacht, die aber die max. Taktrate deutlich begrenzen werden.
Die Schere wird in den nächsten Jahren somit aufgehen und Intel verfügt nur über eine problematische Fertigungstechnik.
BlackBirdSR
Commodore Special
Ich sehe wir finden einen gemeinsamen Nenner
Allerdings möchte ich noch ein paar Sachen zum Thema SOI, Processhrinks etc hinzufügen.
SOI ist ein Ansatz für bestimmte Probleme.
Man kann damit Leckströme ins Substrat reduzieren und die Spannung senken, das hast du völlig recht. Aber das Problem ist, dass diese Leckströme nur ein Teil der vielen Lecks sind. Bereits mit dem 90nm Prozess treten verstärkt Lecks vom Gate in den Kanal auf. Dieser Effekt lässt sich nur mit High-K Gates hinausschieben/verringern, und dort gibt es noch massig Probleme. Vor 45nm werden wir da wohl nichts sehen.
Derweil wird die Ausbreitungsgeschwindigkeit der Signale innerhalb der CPU immer mehr zu einem Problem.
Bevor ich jetzt was falsch wiedergebe verlinke ich einfach mal auf Pauls Artikel.
http://www.realworldtech.com/page.cfm?ArticleID=RWT062004172947
Komplexere Designs wie der Prescott wären damit völlig in die falsche Richtung gedacht, Niagara, Xenon oder anscheinend selbst die IA64 Cores dagegen in einer etwas besseren Ausgangsposition.
rkinet
Grand Admiral Special
Danke für den Link , hab ihn aber erst überflogen.
Bei den diversen Leckströmen bitte nicht das 'Ohmsche Gesetz' vergessen.
Zwar ist der elektrische Widerstand wahrhaft kein konstanter Wert bzgl. Vcc, nur als Näherung brauchbar.
25% weniger Vcc bedeutet grob -25% an Leckstrom in 'Ampere', ausmultiplizier 40-50% weniger Wärmeleistung durch ungewollte Leckströme.
Auch wenn die Leckstöme wohl beim 130nm auf 90nm Shrink sich fast vervierfachen (etwa so bei Intel), eine niedrigere Vcc kann hier wieder gegensteuern.
IBM hat bei der Vcc gegengesteuert, AMD wirds wohl auch so machen (1,3 V statt 1,5 V)
Kann Intel nicht durch simples Vcc Absenken die Leckströme teils gegenkompensieren, wird der weitere Shrink problematisch. Auch dürften die kleinen Transistoren noch mehr einfach die alten, hohen Vcc mitmachen.
Hier punktet SOI, u.U. ein großer Vorteil bei 90nm und 65nm.
Bei den diversen Leckströmen bitte nicht das 'Ohmsche Gesetz' vergessen.
Zwar ist der elektrische Widerstand wahrhaft kein konstanter Wert bzgl. Vcc, nur als Näherung brauchbar.
25% weniger Vcc bedeutet grob -25% an Leckstrom in 'Ampere', ausmultiplizier 40-50% weniger Wärmeleistung durch ungewollte Leckströme.
Auch wenn die Leckstöme wohl beim 130nm auf 90nm Shrink sich fast vervierfachen (etwa so bei Intel), eine niedrigere Vcc kann hier wieder gegensteuern.
IBM hat bei der Vcc gegengesteuert, AMD wirds wohl auch so machen (1,3 V statt 1,5 V)
Kann Intel nicht durch simples Vcc Absenken die Leckströme teils gegenkompensieren, wird der weitere Shrink problematisch. Auch dürften die kleinen Transistoren noch mehr einfach die alten, hohen Vcc mitmachen.
Hier punktet SOI, u.U. ein großer Vorteil bei 90nm und 65nm.
Ähnliche Themen
