Archiv verlassen und diese Seite im Standarddesign anzeigen : Intel - Compiler für den Atom
Acid-Beatz
2010-01-07, 22:54:50
Hey Leute,
mir ist letztens aufgefallen, dass beim Itanium letztendlich ja auch das Ziel war eine einfache Architektur zu schaffen wo die meiste Arbeit dem Compiler überlassen wird.
Ist es dann nicht so, dass man paar In-Order Nachteile des Atoms auch ausgleichen könnte und so noch bischen zusätzliche "Power" bekommt?
Ich bin mir durchaus bewusst, dass ein Atom keine High-Performance Plattform darstellt und es von daher egal ist aber mir gehts eigentlich nur ums prinzipielle "möglich sein" ... paar % hald, Sinnfreiheit dahingestellt ;)
Greez
StefanV
2010-01-07, 23:34:26
Beim Itanic siehst ja auch, dass dies idee nicht besonders gut funktioniert.
AFAIR arbeitete man auch bei EPIC an OoOE, aber die Arbeiten an der Architektur wurden ja beanntlich sehr zurückgefahren.
Deswegen hat der Atom HT bekommen, weil er als In-Order-Architektur davon insgesamt besser profitiert.
Acid-Beatz
2010-01-07, 23:43:18
Also meines Wissens nach "funktioniert" es quasi nur nicht, weil keiner den Itanium kauft(e)! Die Performance mit optimiertem Code soll ja speziell bei Gleitkommaberechnung spitze gewesen sein, des dumme war eben nur wie ich bereits sagte, dass es keinen Markt gab/gibt!
Ein anderes Problem war am Anfang irgendwie auch noch, dass die Compiler dahingehend optimierten, dass sie gewissen Code spekulativ ausführen ließen und viele Sachen dann trotzdem verworfen worden wurden -> alle Einheiten der CPU auf 100% was in einer realen Leistungsaufnahme von > 100W resultierte aber bei der Performance hat es nicht wirklich was genutzt.
Ich glaub, man hat eben speziell diese Problem dann mit dem Itanium 2 und besseren Compilern behoben.
x86 CPUs müssen wohl oder übel mit Microsoft- und GCC-Code vorlieb nehmen. Punkt.
Alles andere ist nur in Nischenbereichen relevant und wird der CPU nicht helfen.
Aquaschaf
2010-01-08, 01:14:56
Das ist sozusagen eine andere Art von Preis die man bezahlt, wenn man eine CPU mit dem x86-Instruktionssatz ausstattet.
Was soll daran ein "Preis" sein? MSVC++ und GCC sind recht ausgereifte Compiler. So ist es ja nicht.
Nur wird der ausgelieferte Code halt "blended" optimiert, d.h. nicht auf einen speziellen Chip.
gibts eigentlich benches mit verschiedenen Compilern für größere reallife anwendungen?
Shink
2010-01-08, 08:30:04
Also meines Wissens nach "funktioniert" es quasi nur nicht, weil keiner den Itanium kauft(e)!
Wenn die Architektur so effizient gewesen wäre hätte man sie auch im Consumer-Bereich durchgeprügelt.
Pläne für einen IA64-Pentiumnachfolger hatte man bei Intel damals durchaus in der Pipeline.
Ich glaub, man hat eben speziell diese Problem dann mit dem Itanium 2 und besseren Compilern behoben.
War dann aber wohl doch nichts oder wie?:freak:
Wie gesagt: Wofür hätte man den Xeon gebraucht wenn man einen kleineren Itanium bauen hätte können. Für jedes Windows vor Vista gab es immerhin eine IA64-Version.
Probleme waren seit jeher:
- Einen wirklich effizienten IA64-Compiler zu entwickeln war doch ein größeres Problem als man angenommen hat. Wenn das Intel und HP nicht schaffen wer dann?
- Die Caches müssen riesig sein.
Aquaschaf
2010-01-08, 09:06:36
Nur wird der ausgelieferte Code halt "blended" optimiert, d.h. nicht auf einen speziellen Chip.
Das meine ich ja.
Exxtreme
2010-01-08, 12:15:13
Also meines Wissens nach "funktioniert" es quasi nur nicht, weil keiner den Itanium kauft(e)! Die Performance mit optimiertem Code soll ja speziell bei Gleitkommaberechnung spitze gewesen sein, des dumme war eben nur wie ich bereits sagte, dass es keinen Markt gab/gibt!
Ein anderes Problem war am Anfang irgendwie auch noch, dass die Compiler dahingehend optimierten, dass sie gewissen Code spekulativ ausführen ließen und viele Sachen dann trotzdem verworfen worden wurden -> alle Einheiten der CPU auf 100% was in einer realen Leistungsaufnahme von > 100W resultierte aber bei der Performance hat es nicht wirklich was genutzt.
Ich glaub, man hat eben speziell diese Problem dann mit dem Itanium 2 und besseren Compilern behoben.
Das Spekulative hat viel Strom gefressen und hat die Executables aufgebläht ohne Ende.
Ob es daran lag, daß niemand den Itanic kaufte weiss ich nicht. Intel hat da viele Resourcen reingesteckt und beim Compiler werden sie nicht gepatzt haben. In order execution hat schon etliche Nachteile. Verschmerzbar ist es nur dann wenn die Performance kaum eine Rolle spielt und man auf Dinge wie Stromverbrauch und Kosten achten muss.
Ganon
2010-01-08, 13:17:34
Das ist sozusagen eine andere Art von Preis die man bezahlt, wenn man eine CPU mit dem x86-Instruktionssatz ausstattet.
Andere Architekturen haben dafür in bestimmten Bereichen nicht mal "Compiler". z.B. JiTC bei Java.
Acid-Beatz
2010-01-08, 15:26:50
Wenn die Architektur so effizient gewesen wäre hätte man sie auch im Consumer-Bereich durchgeprügelt.
Pläne für einen IA64-Pentiumnachfolger hatte man bei Intel damals durchaus in der Pipeline.
War dann aber wohl doch nichts oder wie?:freak:
Wie gesagt: Wofür hätte man den Xeon gebraucht wenn man einen kleineren Itanium bauen hätte können. Für jedes Windows vor Vista gab es immerhin eine IA64-Version.
Probleme waren seit jeher:
- Einen wirklich effizienten IA64-Compiler zu entwickeln war doch ein größeres Problem als man angenommen hat. Wenn das Intel und HP nicht schaffen wer dann?
- Die Caches müssen riesig sein.
Also die Pläne für einen Consumer-Itanium gabs wohl aber auch da stand schon fest, dass sich dieser erst mit viel kleineren Fertigungsprozessen realisieren lässt wie wir sie jetzt zum Beispiel haben.
Ansonsten hatte er mit einigen Verzögerungen bei Auslieferung und niedrigen Taktgeschwindigkeit zu kämpfen soweit ich mich gerade erinnern kann und das ist in der Serverindustrie nicht unbedingt gern gesehen!
Die Xeons waren eben von den Desktops da und von daher waren sie auch erprobt und verfügbar was deren weitere Entwicklung begünstigte: Die passende Software gabs bereits und die Hardware eben auch: Den Rest hat der Markt entschiede und hier wurde eben nicht Wert auf moderne und fortschrittliche Technik gelegt.
Das mit den Compilern war wohl nicht der Fall, eher die mangelnde Akzeptanz bei den Firmen.
Shink
2010-01-08, 15:36:47
eher die mangelnde Akzeptanz bei den Firmen.
...die eben nicht ganz unbegründet war.
Das lustige bei der VLIW/EPIC-Geschichte ist ja dass man annahm man kann die Komplexität der CPU verringern indem man Komplexität in den Compiler verlegt.
Weniger Komplexität -> billiger herzustellen, kleiner, stromsparend, höher taktbar.
Wenn man sich nun aber einen Itanium ansieht...:rolleyes:
AFAIR arbeitete man auch bei EPIC an OoOE, aber die Arbeiten an der Architektur wurden ja beanntlich sehr zurückgefahren.Höh? EPIC und Out-of-Order-Execution? Wie das?
Ansonsten ist die Nutzung von was anderem als MSVC unter Windows und GCC unter GNU/Linux/MacOS/BSD doch wirklich die Ausnahme, wie Coda schon sagte. SIcher kann ich mir mein Linux auch mit dem Intel Compiler zusammenbauen, aber sobald man Software auch verteilen will, endet hier der Spaß. Den GCC hingegen kann man auf praktisch jedem Linux-System als vorhanden voraussetzen.
Wenn man sich nun aber einen Itanium ansieht...:rolleyes:
Itanium ist so groß, weil er bedingt durch den Einsatzzweck riesige Caches hat. Die Cores an sich sind relativ klein.
Höh? EPIC und Out-of-Order-Execution? Wie das?
Man müsste halt die Abhängigkeiten der Bundles statt Instructions tracken. Theoretisch sollte das schon gehen.
Würde man den Itanium für den Desktop-Einsatz umkonzipieren, hätte er weit weniger Cache - wahrsch. genau so viel wie die Core- oder Nehalem-Architektur - dafür aber einen up-to-date IMC.
Man müsste halt die Abhängigkeiten der Bundles statt Instructions tracken. Theoretisch sollte das schon gehen.
Dann wäre er aber auf der gleichen, wenn nicht sogar auf einer höheren, Komplexitätsstufe als die gängigen Archs.
Es gibt beim Intel Compiler extra Schalter für den Atom, Optimierung auf InO ist halt etwas Anderes als für OoO. Aber wieviel das bringt weiss ich nicht.
Exxtreme
2010-01-08, 19:55:24
Es gibt beim Intel Compiler extra Schalter für den Atom, Optimierung auf InO ist halt etwas Anderes als für OoO. Aber wieviel das bringt weiss ich nicht.
Problem ist, den Compiler nutzt halt kaum jemand. Meist wird entweder der Visual Studio-Compiler oder die GCC-Suite benutzt. Einfach weil es schon von vorneherein in die Entwicklungsumgebungen eingebunden ist und man nix basteln braucht. Kompatibilitätsprobleme mit irgendwelchen reservierten Schlüsselwörtern hat man auch keine etc.
Und Intel hat jetzt ein x86-Smartphone präsentiert:
http://www.heise.de/newsticker/meldung/Intel-zeigt-x86-Smartphone-899552.html
:D
Problem ist, den Compiler nutzt halt kaum jemand. Meist wird entweder der Visual Studio-Compiler oder die GCC-Suite benutzt. Einfach weil es schon von vorneherein in die Entwicklungsumgebungen eingebunden ist und man nix basteln braucht. Kompatibilitätsprobleme mit irgendwelchen reservierten Schlüsselwörtern hat man auch keine etc.
Und Intel hat jetzt ein x86-Smartphone präsentiert:
http://www.heise.de/newsticker/meldung/Intel-zeigt-x86-Smartphone-899552.html
:D
Schonmal den Intelcompiler verwendet? Da muss nicht gebastelt werden! Einfach installieren und per Schalter entscheiden ob das Projekt mit MS oder Intel Compiler compiliert werden soll. Für Einstellung und Co. wird der ICC genauso wie der MS Compiler ins System verankert.
Ganon
2010-01-09, 03:25:15
Bloß wer bringt schon extra eine Anwendung nur für den Atom-Prozessor raus?
Bloß wer bringt schon extra eine Anwendung nur für den Atom-Prozessor raus?
Vor allem: Wer kauft dafür den ICC?
san.salvador
2010-01-09, 09:56:09
Bloß wer bringt schon extra eine Anwendung nur für den Atom-Prozessor raus?
Alles eine Frage des Aufwands und der Kosten. Wenn die Atom-optimierte Version nur einen weiteren Mausklick kosten würde, gäbs sicher einiges an Software für den Atom.
Alles eine Frage des Aufwands und der Kosten. Wenn die Atom-optimierte Version nur einen weiteren Mausklick kosten würde, gäbs sicher einiges an Software für den Atom.
Es kostet mindestens einmal neu compilieren.
Exxtreme
2010-01-09, 10:03:51
Ist sowieso fraglich ob die typische PC-Software einfach so läuft. Kompilieren ist da nicht so die Hürde.
Benedikt
2010-01-09, 10:15:33
Ist sowieso fraglich ob die typische PC-Software einfach so läuft. Kompilieren ist da nicht so die Hürde.
Ist der Intel-Compiler denn bei den herkömmlichen Visual Studio-Projekten genauso "gutmütig" wie der MS-Compiler, oder handelt man sich da schnell Warnungen/Inkompatibilitäten beim Kompilieren ein, sodass das ganze dann sowieso wieder in Anpassungsarbeit ausartet? Mit einem simplen Rekompilieren wird's wohl bei größeren Softwareprojekten dann doch nicht getan sein, oder?
san.salvador
2010-01-09, 10:44:23
Es kostet mindestens einmal neu compilieren.
Das sollte aber keine große Hürde sein, wenns nur das wäre. ;)
Bloß wer bringt schon extra eine Anwendung nur für den Atom-Prozessor raus?
Siehe hier:
Intels Netbook-App-Store öffnet Beta-Pforten
http://www.heise.de/newsticker/meldung/Intels-Netbook-App-Store-oeffnet-Beta-Pforten-899532.html
Ich frage mich, was da besonders für den Win-Netbook sein soll?
Vielleicht eine Portable-Version eines Programms speziell kompiliert für den Atom?
Oder eine Version für den x86-Smartphone?
Siehe hier:
Intels Netbook-App-Store öffnet Beta-Pforten
http://www.heise.de/newsticker/meldung/Intels-Netbook-App-Store-oeffnet-Beta-Pforten-899532.html
Ich frage mich, was da besonders für den Win-Netbook sein soll?
Vielleicht eine Portable-Version eines Programms speziell kompiliert für den Atom?
Oder eine Version für den x86-Smartphone?
Da etwas von Entwicklungswerkzeugen erwähnt wird könnte das sein.
Ansonsten ist es scheinbar ein nachgemachmter Appstore von Apple.
Das x86 Smatphone hat auch einen Atom...
Shink
2010-01-09, 20:51:15
Das sollte aber keine große Hürde sein, wenns nur das wäre. ;)
Warum nicht? Immerhin hätte man damit doppelt so viele Binaries im Umlauf/zum Ausrollen.
Shink
2010-01-09, 21:27:06
Würde man den Itanium für den Desktop-Einsatz umkonzipieren, hätte er weit weniger Cache - wahrsch. genau so viel wie die Core- oder Nehalem-Architektur - dafür aber einen up-to-date IMC.
Ich dachte der Befehls-Cache müsste wesentlich größer sein?
Exxtreme
2010-01-09, 22:50:55
Ist der Intel-Compiler denn bei den herkömmlichen Visual Studio-Projekten genauso "gutmütig" wie der MS-Compiler, oder handelt man sich da schnell Warnungen/Inkompatibilitäten beim Kompilieren ein, sodass das ganze dann sowieso wieder in Anpassungsarbeit ausartet? Mit einem simplen Rekompilieren wird's wohl bei größeren Softwareprojekten dann doch nicht getan sein, oder?
Darum geht es nicht. Mobile Software hat komplett andere Anforderungen als normale Anwendungen für den PC. Etliche Hardware ist nicht vorhanden, die ganzen Betriebssystemfunktionen/APIs/ABIs sind extrem abgespeckt etc.
Sprich, man muss in sehr vielen Dingen eine Extrawurst braten wenn die mobilen Anwendungen "benutzbar" bleiben sollen. IMHO wird x86 den mobilen Bereich nicht so einfach überrennen können wie es in anderen Bereichen passiert ist. Das Meiste neu implementieren muss man sowieso. Und wenn man schon neu anfängt dann ist die Architektur egal. Und gegen ARM sieht x86 im Moment relativ schlecht aus was den mobilen Einsatzzweck angeht.
Acid-Beatz
2010-01-09, 23:26:53
Also die Binaries sind bei den Speichern heute wohl das geringste Problem oder seh ich da was falsch?!
Letzendlich is es doch auch so, dass ein Atom SSE Instruktionen ganz anders abarbeitet wie ein Core 2 oder Phenom?!
Die Befehls Caches waren beim ersten Itanium zu klein soweit ich weiß aber dannach hat mans behoben.
Es gab ja mal kleine Itaniums für 1000 Dollar rum, mit denen ging schon was ;)
Acid-Beatz
2010-01-09, 23:51:22
Was mir gerde noch eingefallen ist: Der Pentium 4 war ja das beste Beispiel wieviel man durch gute Compiler noch rausholen kann: Anfangs geschollten war er Performancemäßig am Schluss ja ziemlich gut ... nur der Verbrauch war etwas "suboptimal" und von daher ... vllt ginge es beim Atom ja genauso!
Controller Khan
2010-01-10, 00:07:06
Es kostet mindestens einmal neu compilieren.
stichwort war lpia unter linux, hat kaum was gebraucht.
zum Pentium 4, den hat SSE2 zum Teil gerettet, ein Irrweg war das Ding trotzdem.
Acid-Beatz
2010-01-10, 01:28:50
Ja sicher hats SSE(2) zum Teil gerettet aber letztendlich ist doch egal wie oder was, das Ergebnis zählt ;)
Exxtreme
2010-01-10, 02:04:42
Was mir gerde noch eingefallen ist: Der Pentium 4 war ja das beste Beispiel wieviel man durch gute Compiler noch rausholen kann: Anfangs geschollten war er Performancemäßig am Schluss ja ziemlich gut ... nur der Verbrauch war etwas "suboptimal" und von daher ... vllt ginge es beim Atom ja genauso!
Der Original-P4 war bis auf paar Ausnahmen wie Streaming nie richtig gut. Intel hat mit den Nachfolgemodellen dann doch paar Dinge eingebaut, die mehr Leistung brachten. Z.B. wurde beim Northwood der L2-Cache verdoppelt und beim Prescott dann auch der L1-Daten-Cache etc.
War nicht unbedingt eine Sache des Compilers, daß der P4 am Ende besser stand als der Original-Williamette.
Acid-Beatz
2010-01-10, 02:38:03
Öhm doch ... ich erinnere mich noch gut an die Benchmarks wo der Compiler miteinbezogen wurde und es eben zu den Ergebnissen kam, egal ob jetzt neuer oder alter Pentium 4.
Ich glaube kaum das der Compiler mit der Leistungssteigerung etwas zu tun hatte. Viel mehr waren es die vielen Verbesserungen in der Arch.
Z.B.
Der Willamette hatte 256KB L2 und FSB400. Der Northwood in seiner stärksten Ausbaustufe dagegen 512KB L2, FSB800 und HTT.
Gast321
2010-01-10, 13:42:54
Problem ist, den Compiler nutzt halt kaum jemand. Meist wird entweder der Visual Studio-Compiler oder die GCC-Suite benutzt.
Atom optimierten code kann man schon länger auch mit gcc erzeugen.
Ab 2.6.32er Kernel kann man den Kernel mit "config MATOM" compilieren...
außerdem kann man mit tools wie z.B. ACOVEA auch selber die opitimale Compiler Configuration für die eigene CPU austesten.
Die Befehls Caches waren beim ersten Itanium zu klein soweit ich weiß aber dannach hat mans behoben.
Es gab ja mal kleine Itaniums für 1000 Dollar rum, mit denen ging schon was ;)
Hallo,
die L1 Caches sind immer noch 16+16 KB. Der L2 steig von 96 auf 256 KB. Aber ein Itanium braucht eigentlich nicht so viel schnellen Cache, der L3 Cache ist mehr zu kaschieren der RAM Latenzen. Außerdem lassen sich mit den 128 Registern 64 Bit Registern viele Cache/RAM zugriffe vermeiden.
Das Problem des Itaniums sind Sprünge mit mehr als zwei Verzweigungen und schlechte Daten für die Compiler.
Ich selbst besetze einen Itanium mit zwei Madison CPUs (1,3 GHz), auf dem rennt Windows 2008 R2 schneller als auf einem moderenem Xeon/Opteron Dual Quadcore System. Die Performance, kommt vom Compiler, somit könnte ein dirket auf den Atom compiliertes Programm vermutlich schneller sein.
mfg
Shink
2010-01-10, 15:02:04
Ich glaube kaum das der Compiler mit der Leistungssteigerung etwas zu tun hatte.
Also ich würde mal vermuten dass der P4 eine wesentlich längere Pipeline hatte als die diesbezüglich ähnlichen P2, P3 und Athlon hatte schon die Auswirkung dass keines der zu Beginn erhältlichen Compilate dafür optimal war.
Das Problem des Itaniums sind Sprünge mit mehr als zwei Verzweigungen und schlechte Daten für die Compiler.
Ein bedingter Sprung hat immer genau 2 Möglichkeiten.
Ein bedingter Sprung hat immer genau 2 Möglichkeiten.
Ok, etwas undeutlich ausgedrückt, ein CASE ist der Feind des Itaniums.
Bei "if" ,"if/else" oder "comp/jmp" werden alle Pfade im vorraus berechnet und die nicht eintrettenden verworfen.
Ok, etwas undeutlich ausgedrückt, ein CASE ist der Feind des Itaniums.
Auf Hardwareebene gibt es kein switch/case, das existiert nur in Hochsprachen.
In der Hardware wird jedes switch/case-Konstrukt wieder in einzelne bedingte Sprünge zerlegt.
Demirug
2010-01-13, 12:12:19
Auf Hardwareebene gibt es kein switch/case, das existiert nur in Hochsprachen.
In der Hardware wird jedes switch/case-Konstrukt wieder in einzelne bedingte Sprünge zerlegt.
Mit x86 kann man leicht Sprungtabellen umsetzen und das wird auch gemacht.
Auf Hardwareebene gibt es kein switch/case, das existiert nur in Hochsprachen.
Was interessiert das den Compiler? Er hat die Ressourcen um zwei Wege im vorraus zu berechnen und hat fünf zur Auswahl.
Bei "if" hat er den normalen Programmablauf und wenn 20 Befehle später die Verzweigung ist, berechnet er einfach beide Varianten nebenbei mit (und verwirft dann eine, -> Trefferquote 100%).
Mit x86 kann man leicht Sprungtabellen umsetzen und das wird auch gemacht.
Die Radeon-HD5000-Serie hat auch Hardwaresupport für Sprungtabellen.
Bei "if" ,"if/else" oder "comp/jmp" werden alle Pfade im vorraus berechnet und die nicht eintrettenden verworfen.
Das macht er soweit ich weiß nur, wenn man das speziell so im Code vermerkt und genügend Ausführungsresourcen übrig sind.
Das macht er soweit ich weiß nur, wenn man das speziell so im Code vermerkt und genügend Ausführungsresourcen übrig sind.
Die Ressourcen für drei "Befehlsfolgen" sind immer da und der Intel Compiler, welcher der einzige wirlich in Frage kommende ist, macht sowas automatisch.
Beim Number Crunching werden allerdings alle drei Pfade mit "echten" Befehlen gefüllt und daher kommt der hohe Durchsatz bei relativ geringem Takt.
Compiler generieren bei weitem nicht den Code den man von Hand in Assembler schreiben würde.
GCC macht konstant suboptimalen Code, ich schätze dass man im Schnitt 50% der Leistung hat die möglich wäre, das bei simpelstem Source.
MSVC macht recht guten OpCode bei integer-Code. Kommt float hinzu, schubst VC manchmal zu oft was rum. Unter 64bit und nur SSE (keine FPU Nutzung) macht VC wieder einen guten Job, da denke ich kommen ca 80-90% der Leistung raus von handgeschriebenem Assembler. Wo VC aber oft sehr versagt sind intrinsics, der Compiler scheint schlicht keine Ahnung zu haben was die machen und optimiert rein das Scheduling und Registernutzung. Manchmal kann man einige nutzlose mov sparen indem man einfach die parameter vertauscht (wegen dem destruktiven Verhalten von x86 Befehlen macht der Compiler sonst manchmal eine temporäre Kopie).
Dazu kommt noch die sehr schlechte SSE einheit vom Atom. Nur auf FPU zu arbeiten kann durchaus schneller sein. Wenn man z.B. X,Y,Z,W im Register hat, dann durch W teilen will, wird man auf anderen CPUs W splatten und alle 4 Komponenten teilen, beim Atom sollte man W auf X umsortieren, durch X teilen und dann X splatten. Obwohl man sonst sowas meidet weil es RAW Hazards verursacht (gerade auf in-order-CPUs), ist das dennoch schneller.
Man sollte sich die interesanten Tabellen anschauen mit "Atom instruction latencies" ;)
@Gast
Ich hatte von Anfang an das Gefühl, das der Atom sowas wie ner abgespeckter Northwood ist, mit ner In-Order Arch*. Und deswegen ging ich davon aus, das zumind. die SSE-Einheit recht flot ist. Beim NW war sie das - konnte pro Takt genau so viel wie bei den anderen Archs, der NW hatte aber zu seiner Zeit einen viel höheren Takt. Wieso ist sie beim Atom jetzt so lahm?
*Ähnlicher Transi-Verbrauch, ähnliche Cache-Struktur, HTT...
BlackBirdSR
2010-01-14, 12:38:27
@Gast
Ich hatte von Anfang an das Gefühl, das der Atom sowas wie ner abgespeckter Northwood ist, mit ner In-Order Arch*. Und deswegen ging ich davon aus, das zumind. die SSE-Einheit recht flot ist. Beim NW war sie das - konnte pro Takt genau so viel wie bei den anderen Archs, der NW hatte aber zu seiner Zeit einen viel höheren Takt. Wieso ist sie beim Atom jetzt so lahm?
*Ähnlicher Transi-Verbrauch, ähnliche Cache-Struktur, HTT...
Atom sieht intern ganz anders aus als der P4. Das an der Anzahl an Transistoren festzumachen ist sinnlos, die Cachestruktur ist auch ganz anders (Trace-Cache) und SMT hat die PowerISA auch ;)
Bei Atom hat man halt agressiveres Glock-Gating, weniger kostspielige Optimierungen, ein weniger breit ausgelegtes Front-End und schluss endlich wohl auch wirtschaftliche Designentscheidungen, die Atom hier ausbremsen.
Atom sieht intern ganz anders aus als der P4.
Das ist doch schon an dem InO vs OoO Unterschied mehr als klar. Man kann aber nicht bestreiten, das die Design-Philosophie in eine ähnliche Richtung geht. Und zwar "kleiner Kern, wenig IPC", nur das man beim Atom den 3. Teil "TAKT" ausgelassen hat. Schon anhand dieser "Insturuction latency and throughput"-Tabelle sieht man das der Atom eine starke Ähnlichkeit mit der P4-Arch aufweist. Auch die Perf in real-world Situationen sollte einem Ur-P4/Willamette ähnlich sein.
Ich wette, das ein Willamette/Northwood in heutigen Prozessen hergestellt und mit max. 1,6 GHz getaktet, eine sehr ähnliche Leistungsaufnahme aufweisen würde. Eine erschreckend ähnliche.
Acid-Beatz
2010-01-14, 13:06:27
Hat der Atom SSE+ dann quasi nur aus Kompatibilitätsgründen einiger Programme, nicht zur Beschleudingung, sehe ich das richtig?
@Gast: Meines Wissens nach produzieren die Intel Compiler recht guten Code, vor allem mit Feedback Optimierung ( ich glaub zumindest so hats geheissen).
Die paar Fälle wo "echter" Assemblercode schneller ist düfte sich an zwei Händen abzählen lassen ;)
BlackBirdSR
2010-01-14, 13:32:12
Die Designphilosophie geht überhaupt nicht in die gleiche Richtung, es sei denn du abstrahierst so weit, dass ein Cortex A9 quasi ein Core2 und ein PowerPC quasi ein x86 ist.
P4 war ein Logikmonster mit unzähligen Extras, die heute einfach gescheitert sind. Der Rest ist im Atom genau so zu finden, wie im Core2.
Nur weil Instruktionen ähnliche Latenzen und Durchsätze haben, ist eine µArch nicht gleich, ähnlich oder angelehnt.
Sonst müssen wir demnächst den Atom mit dem G3 vergleichen.
Performance ist ein ganz schlechter Indikator für einen Vergleich, ob eine Architektur mit einer anderen ähnlich ist. Sonst vergleichen wir plötzlich ARM mit Atom und Power mit x86.
Gleiches für Leistungsaufnahme.
Wichtig ist doch, wieviel P4 im Atom steckt, also quasi ob der P4 als Unterbau benutzt wurde und das ist ganz und gar nicht der Fall, wenn man sich Front-End,BackEnd und Blockdiagramme ansieht.
Das ist doch schon an dem InO vs OoO Unterschied mehr als klar. Man kann aber nicht bestreiten, das die Design-Philosophie in eine ähnliche Richtung geht. Und zwar "kleiner Kern, wenig IPC", nur das man beim Atom den 3. Teil "TAKT" ausgelassen hat. Schon anhand dieser "Insturuction latency and throughput"-Tabelle sieht man das der Atom eine starke Ähnlichkeit mit der P4-Arch aufweist. Auch die Perf in real-world Situationen sollte einem Ur-P4/Willamette ähnlich sein.
Ich wette, das ein Willamette/Northwood in heutigen Prozessen hergestellt und mit max. 1,6 GHz getaktet, eine sehr ähnliche Leistungsaufnahme aufweisen würde. Eine erschreckend ähnliche.
Die Designphilosophie geht überhaupt nicht in die gleiche Richtung, es sei denn du abstrahierst so weit, dass ein Cortex A9 quasi ein Core2 und ein PowerPC quasi ein x86 ist.
Nein, so war das nicht gemeint, sondern das es unter den x86-Archs keine gibt die der des Atom ähnlicher ist als die P4. Und umgekehrt.
Gemessen an den heutigen Standards ein schlanker Kern (sogar der Logik-Teil), low IPC, usw. Beim P4 gabs noch die 3. Säule, der hoche Takt, aber wenn man sich die anderen Archs anschaut, ist das nicht sooo ein großer Unterschied.
P4 war ein Logikmonster mit unzähligen Extras, die heute einfach gescheitert sind.
Vll. zur damaligen Zeit. Aber heute? Du willst doch nicht etwa sagen, das der P4-Logikteil komplexer ist als der des Cores, Nehalems, oder Penoms?
Der Rest ist im Atom genau so zu finden, wie im Core2.
Nein, das glaube ich nicht. Die Core-Arch verfolgt einen völlig gegentiligen Ansatz. Nämlich Perf/Clock. Da kann einfach nicht viel des P4 drin sein.
Nur weil Instruktionen ähnliche Latenzen und Durchsätze haben, ist eine µArch nicht gleich, ähnlich oder angelehnt.
Sonst müssen wir demnächst den Atom mit dem G3 vergleichen.
Was denn sonst? Die Latenz und Durchsatz-Angaben geben einen Hinweis darauf, wie es um die Ausführungseinheiten und die Leitungen bestellt ist. Und wenn die Atom- da der P4-Arch am ähnlichsten ausschaut, kann man sehr wohl sagen, das die 2 ähnlich sind. Und natürlich kann man Atom und G3 auf diese Weise nicht vergleichen. Es ist klar, das die beiden aus völlig anderen Welten kommen, und schon die Basis komplett unterschiedlich ist.
Performance ist ein ganz schlechter Indikator für einen Vergleich, ob eine Architektur mit einer anderen ähnlich ist. Sonst vergleichen wir plötzlich ARM mit Atom und Power mit x86.
Natürlich kann man ARM und x86 auf diese Weise nicht vergleichen. Aber innerhalb des x86 gibts dagegen nichts einzuwenden.
Gleiches für Leistungsaufnahme.
Wichtig ist doch, wieviel P4 im Atom steckt, also quasi ob der P4 als Unterbau benutzt wurde und das ist ganz und gar nicht der Fall, wenn man sich Front-End,BackEnd und Blockdiagramme ansieht.
Und woher soll man diese Infos bekommen? Ein Shot des Dies, ode was?
Und wieviel Wahrheit ist wirklich in Blockdiagrammen drin? SWIW verlor damals kein einziges dieser Diagramme ein Wort darüber, das die Netburst-Arch so eine Vorgehensweise (und die Nötigen Transis dafür) wie das "Replay" hat. Das musste man damals anhand der Perfmessung unter bestimmten Bedingungen extrapolieren.
BlackBirdSR
2010-01-14, 14:50:01
Ich glaube da ist heute Abend ein längerer Text fällig ;)
Das ist doch schon an dem InO vs OoO Unterschied mehr als klar. Man kann aber nicht bestreiten, das die Design-Philosophie in eine ähnliche Richtung geht.
Nein. Tut sie überhaupt nicht.
Atom ist darauf getrimmt möglichst wenig Strom zu verbrauchen und opfert dafür Perf/Takt. Netburst war darauf getrimmt möglichst hohen Takt zu erreichen und opfert dafür Perf/Takt.
Ich gehe jetzt nicht ins Detail. Aber du liegst def. falsch.
Von der Architektur könnten sie gar nicht weiter auseinander liegen. P4 ist Out-Of-Order, hat nen Trace-Cache und Replay. Atom ist In-Order, hat Caches die 8T-Transistorzellen haben um Strom zu sparen und würde nen Teufel tun auch nur irgendwas öfter zu berechnen als nötig.
Vll. zur damaligen Zeit. Aber heute? Du willst doch nicht etwa sagen, das der P4-Logikteil komplexer ist als der des Cores, Nehalems, oder Penoms?
In der Prescott-Ausführung auf jeden Fall, bei Willamette/Northwood bin ich mir nicht sicher.
Compiler generieren bei weitem nicht den Code den man von Hand in Assembler schreiben würde.
GCC macht konstant suboptimalen Code, ich schätze dass man im Schnitt 50% der Leistung hat die möglich wäre, das bei simpelstem Source.
MSVC macht recht guten OpCode bei integer-Code. Kommt float hinzu, schubst VC manchmal zu oft was rum. Unter 64bit und nur SSE (keine FPU Nutzung) macht VC wieder einen guten Job, da denke ich kommen ca 80-90% der Leistung raus von handgeschriebenem Assembler. Wo VC aber oft sehr versagt sind intrinsics, der Compiler scheint schlicht keine Ahnung zu haben was die machen und optimiert rein das Scheduling und Registernutzung. Manchmal kann man einige nutzlose mov sparen indem man einfach die parameter vertauscht (wegen dem destruktiven Verhalten von x86 Befehlen macht der Compiler sonst manchmal eine temporäre Kopie).
Abgesehen von ein paar Beispielen die eher akademischer Natur sind, wirst du einen Compiler nicht das Wasser reichen können in der Praxis ;)
In der Prescott-Ausführung auf jeden Fall, bei Willamette/Northwood bin ich mir nicht sicher.
Ja, Prescott war riesig. Das ist wohl auch heute noch von der Core-Logik der komplexeste Chip den Intel je produziert hat - nicht nur vom Transistoraufwand, sondern auch vom Design.
Prescott hat es geschafft trotzt >30 Pipeline-Stufen die gleiche Takt-Performance wie Northwood zu haben. Das wäre eigentlich unglaublich beeindruckend, wenn das Ding nicht an der Physik gescheitert wäre.
Ohne die große Abwärme hätte man wohl locker >6Ghz aus Prescott rausbekommen.
Abgesehen von ein paar Beispielen die eher akademischer Natur sind, wirst du einen Compiler nicht das Wasser reichen können in der Praxis ;)
Das kommt sehr stark darauf an was du machen willst. Bei normalen Int-Code, ja, aber nicht bei Vektor-Code.
Wie der Gast gesagt hat wird bei Intrinsics oft nicht gerade toller Code erzeugt.
Allgemeingültig ist das auch nicht, auch wenns öfter so ist. Wichtiger ist aber nunmal dass das Ergebnis bei int gut ist. ;)
Nein. Tut sie überhaupt nicht.
Atom ist darauf getrimmt möglichst wenig Strom zu verbrauchen und opfert dafür Perf/Takt.
Das stimmt aber nicht. Es ist wahr das er wenig Strom verbraucht, aber eben nicht möglichst wenig, denn für die Perf die er abliefert verbraucht er bei weitem zu viel. Ein Atom ist kein Perf/Watt-Champion, er ist höhstens ein Perf/Watt/$-Champ.
Netburst war darauf getrimmt möglichst hohen Takt zu erreichen und opfert dafür Perf/Takt.
Das Ergebniss ist das selbe. Ich wette das ein in 40nm hergestellter Northwood, auf 1,6GHz getaktet, eine zum Verwechseln ähnliche Perf bei einem nicht zu unterscheidendem Verbrauch hätte. Mich würde nichtmal wundern, wenn unter dem Atom-Lable in Wirklichkeit ein In-Order-Northwood stecken würde, und man nach Aussen einfach Blödsinn erzählt.
Ich gehe jetzt nicht ins Detail. Aber du liegst def. falsch.
Von der Architektur könnten sie gar nicht weiter auseinander liegen. P4 ist Out-Of-Order, hat nen Trace-Cache und Replay. Atom ist In-Order, hat Caches die 8T-Transistorzellen haben um Strom zu sparen und würde nen Teufel tun auch nur irgendwas öfter zu berechnen als nötig.
Ich hab nicht gesagt das sie identisch sind. Was ich behaupte ist Folgendes:
Northwood/Willemate<-->Atom
Core<-------->Atom
Nehalem<---------------------->Atom
Usw.
Und btw. alleine schon das In-Order-Design sprich gegen die "und würde nen Teufel tun auch nur irgendwas öfter zu berechnen als nötig."-Behauptung, denn während er des öfteren auf irgendwas aus dem Speicher wartet, tut er nichts anderes als das was Netburst beim Replay tat, er verbraucht Storm. ;)
BlackBirdSR
2010-01-14, 20:49:10
Das Ergebniss ist das selbe. Ich wette das ein in 40nm hergestellter Northwood, auf 1,6GHz getaktet, eine zum Verwechseln ähnliche Perf bei einem nicht zu unterscheidendem Verbrauch hätte. Mich würde nichtmal wundern, wenn unter dem Atom-Lable in Wirklichkeit ein In-Order-Northwood stecken würde, und man nach Aussen einfach Blödsinn erzählt.
Ich glaube den langen Text spare ich mir, ich habe nämlich das Gefühl es wäre der Zeit nicht gerecht. Wieviele Leute müssen dir noch sagen, dass Atom sehr sehr weit vom P4 entfernt ist, was Design, µArchitektur, interner Aufbau und Funktionsweise und Designprinzip ist?
Natürlich kann ich sagen, ein Golf ist ein Mazda3 ist ein Astra ist ein Focus weil sie alle ähnlich aussehen, mit ähnlichen Motoren ähnlich schnell sind und am Ende das gleiche tun. Deswegen ist keiner von denen ein umgebauter Golf mit anderer Farbe.
BTW: Replay mit Idle-States zu vergleichen gibt dem den Rest ;)
Ich glaube den langen Text spare ich mir, ich habe nämlich das Gefühl es wäre der Zeit nicht gerecht. Wieviele Leute müssen dir noch sagen, dass Atom sehr sehr weit vom P4 entfernt ist, was Design, µArchitektur, interner Aufbau und Funktionsweise und Designprinzip ist?
Ich bin ein Skeptiker. Nur zu sagen "die 2 sind komplett unterschiedlich" reicht mir nicht. Gibts da nicht ein Liste der Unterschiede wo man das vergleichen könnte?
Natürlich kann ich sagen, ein Golf ist ein Mazda3 ist ein Astra ist ein Focus weil sie alle ähnlich aussehen, mit ähnlichen Motoren ähnlich schnell sind und am Ende das gleiche tun. Deswegen ist keiner von denen ein umgebauter Golf mit anderer Farbe.In diesem Fall ist es eher so: von Aussen siehts wie ein Golf aus, hat fast das gleiche Fahrverhalten, beschleunigt und bremst in ähnlich vielen Sek wie ein Golf, aber hinten steht "Astra" und auf Blockdiagrammen der Ingenieure sieht es völlig anders aus...
BTW: Replay mit Idle-States zu vergleichen gibt dem den Rest ;)
Wieso bezeichnest du das als "Idle-State"? SWIW bezeichent man einen Zustand als "Idle" wo die Arbeit erledigt ist, und "man" entspannen kann. Aber doch nicht einen solchen wo man mit der Arbeit nicht weitermachen kann weil irgendwas nicht zur Hand ist und man deswegen genötigt ist sich im Kreis zu drehen und Energie zu verbrauchen. Und genau das tut der Atom während er auf die Daten aus dem Speicher wartet. Caches sind geladen und verbrauchen Strom, Register auch...eigentlich an jeder Stelle wo irgendwelche (Zwischen)Ergebnisse gespechert sind wird Energie verbraucht. Das einzige was rüht sind die Ausführungseinheiten. Und daher passt meine Analogie: ein Bauarbeiter, der auf nen Hammer wartet, aber sich in der Zwischenzeit im Kreis dreht. "Idle" wäre dagegen, der gleiche Bauarbeiter, der nach getaner Arbeit in ner Hängematte entspannt liegt.
Ich hab nicht gesagt das sie identisch sind. Was ich behaupte ist Folgendes:
Hallo? Ist jemand zuhause?
Ich habe dir doch gerade erklärt, dass es NICHT so ist, sondern genau das Gegenteil.
Ich bin ein Skeptiker. Nur zu sagen "die 2 sind komplett unterschiedlich" reicht mir nicht. Gibts da nicht ein Liste der Unterschiede wo man das vergleichen könnte?
Wie wäre es wenn du zwei Leuten hier glaubst die Ahnung davon haben?
Es nervt. Skeptizismus ist eine gute Eingeschaft, aber sich dann nichts erklären lassen ist reine Dummheit.
Mich würde nichtmal wundern, wenn unter dem Atom-Lable in Wirklichkeit ein In-Order-Northwood stecken würde, und man nach Aussen einfach Blödsinn erzählt.
Ein In-Order-Northwood hätte nichtmal die Per-Clock Leistung eines 386.
EOD. Glaub was du willst, mir ist meine Zeit dafür zu schade.
Mal ehrlich Coda, ist dieses Forum dein Leben? Wieso nimmst du das ganze sooo ernst?
Skeptizismus ist eine gute Eingeschaft, aber sich dann nichts erklären lassen ist reine Dummheit.
Tja, dann erklär mal, aber ohne das es auf "die 2 sind komplett unterschiedlich. Punkt!" hinausläuft. Denn genau das tust du, und nicht nur bei dieser Gelegenheit. Wie wärs mit ner echten, umfassenden Erklärung, zur Abwechslung?
Nö, mir gehen nur Leute wie du gewaltig auf die Nerven. Durch die Bahn, nicht nur hier.
Denken sie sehen die Welt als einzige "richtig", sind dann aber nicht Willens sich Tatsachen beibringen zu lassen, weil dann wären sie ja so wie "die unwissende Masse".
Wenn du den Leuten die sowas studiert haben nichts glaubst, dann ist das einzige was du hier machst den Leuten die gewillt sind dir was zu erklären ihre Zeit zu verschwenden.
Und da werd ich ehrlich gesagt ganz schön angepisst.
Tja, dann erklär mal, aber ohne das es auf "die 2 sind komplett unterschiedlich. Punkt!" hinausläuft. Denn genau das tust du, und nicht nur bei dieser Gelegenheit. Wie wärs mit ner echten, umfassenden Erklärung, zur Abwechslung?
Wenn ich dir das erklären sollte, dann müsstest du erstmal grundlegendes Verständnis dafür haben.
Ich kann hier nicht in zwei Absätzen eine Basiseinführung in Rechnerarchitektur bringen. Und vor allem nicht weil du die wohl auch noch anzweifeln würdest.
Manchmal sollte man sich einfach was sagen lassen von Leuten die es gelernt haben.
Nö, mir gehen nur Leute wie du gewaltig auf die Nerven. Durch die Bahn, nicht nur hier.
Denken sie sehen die Welt als einzige "richtig", sind dann aber nicht Willens sich Tatsachen beibringen zu lassen, weil dann wären sie ja so wie "die unwissende Masse".
Wenn du den Leuten die sowas studiert haben nichts glaubst, dann ist das einzige was du hier machst den Leuten die gewillt sind dir was zu erklären ihre Zeit zu verschwenden.
Und da werd ich ehrlich gesagt ganz schön angepisst.
Cool bleiben Mensch! ;)
Dein Studium und all dein Wissen werden dir nichts nützen wenn du das hier zu ernst nimmst, und eines Tages einem Infarkt erliegst.
Und btw. du schätzst mich völlig falsch ein. Es ist eben so, das ich einen "Hunch" nicht so schnell zu ignorieren beginne, nur weil du mir ein Paar Krümmel Info nachgeworfen hast. Es braucht schon n'Paar Brocken. ;)
Allein dass das eine In-Order ist und das andere Out-Of-Order sollte dir klarmachen, dass wenn beide die gleiche IPC hat etwas grundlegend anders ausgelegt sein muss.
OOO bringt pro Takt normal gut den 1,5-2x Durchsatz.
Und Trace-Cache, Double-Pumped-ALUs und Replay sind große Brocken. Sowas würde man niemals im Embedded-Sektor einsetzen. Nichts davon ist in Atom vorhanden.
Allein dass das eine In-Order ist und das andere Out-Of-Order sollte dir klarmachen, dass wenn beide die gleiche IPC hat etwas grundlegend anders ausgelegt sein muss.
OOO bringt pro Takt normal gut den 1,5-2x Durchsatz.
Da hast du recht. Aber was mich irritiert, ist, das Atom und Northwood (den Trace-Cache ausgenommen) sehr ähnliche Cache-Grössen haben (was der Hauptverbraucher an Transis ist). D.h. für den Logik-Teil bleiben bei beiden ungefähr gleich so viele Transis übrig, denn beide haben fast gleichviel Transis insgesamt (54 Mio, IIRC). Und wenn die schon auf eine ähnliche Perf/Clc* kommen, dann muss doch in den Kernen etwas sehr ähnliches passieren. Und das bringt mich zum Schluss, die Archs müssen ähnlich sein.
*Hier ist der Vergleich von nem NW FSB400 mit nem Atom gemeint. Der FSB800 mit DC hat ein um einiges höhere Perf/Clc.
Ein P4-Core ist um einiges größer als ein Atom-Core. Atoms Core hat 13,8 Mio Transitoren. Prescott eher so um die 40 Mio. Aber auch Northwood wird noch >20 haben.
Hier ein paar Brocken:
Northwood: 55m Transistoren
Atom: 47m Transistoren, zusätzlich kann er aber im Gegensatz zum Northwood x86-64, sse3, VT und hat 8t-sram als cache. (einige der features sind nur bei bestimmten Versionen aktiviet)
Ergo Atom kann garkein NW im Schafspelz sein, von der grundsätzlichen Andersartigkeit als in-Order design mal ganz abgesehen. Diese Informationen hättest dir aber genausogut selbst raussuchen können "hunch" hin oder her.
Hier ein paar Brocken:
Northwood: 55m Transistoren
Atom: 47m Transistoren, zusätzlich kann er aber im Gegensatz zum Northwood x86-64, sse3, VT und hat 8t-sram als cache. (einige der features sind nur bei bestimmten Versionen aktiviet)
Ergo Atom kann garkein NW im Schafspelz sein, von der grundsätzlichen Andersartigkeit als in-Order design mal ganz abgesehen. Diese Informationen hättest dir aber genausogut selbst raussuchen können "hunch" hin oder her.
Jo, die zusätzlichen Features hab ich irgendwie verdrängt, und die Anzahl der Transis beim Atom hatte ich falsch in Erinnerung (nämlich als 50+).
Ich geb zu, Atom ist kein abgespeckter Northwood.
Edit: Würde mich wirklich interessieren, wie hoch sich nen 45nm Northwood takten liesse...wir werden es wohl nie erfahren.
Edit: Würde mich wirklich interessieren, wie hoch sich nen 45nm Northwood takten liesse...wir werden es wohl nie erfahren.
Wohl nicht viel besser als die Nehalems. Die haben inzwischen auch schon wieder 16 Pipeline-Stufen, aber sind bei weitem energieeffizienter.
BlackBirdSR
2010-01-14, 22:46:35
Da hast du recht. Aber was mich irritiert, ist, das Atom und Northwood (den Trace-Cache ausgenommen) sehr ähnliche Cache-Grössen haben (was der Hauptverbraucher an Transis ist). D.h. für den Logik-Teil bleiben bei beiden ungefähr gleich so viele Transis übrig, denn beide haben fast gleichviel Transis insgesamt (54 Mio, IIRC). Und wenn die schon auf eine ähnliche Perf/Clc* kommen, dann muss doch in den Kernen etwas sehr ähnliches passieren. Und das bringt mich zum Schluss, die Archs müssen ähnlich sein.
Diese Ansicht ist konzeptionell schon völlig falsch. Da musst du unbedingt noch mal drüber schlafen.
Wohl nicht viel besser als die Nehalems. Die haben inzwischen auch schon wieder 16 Pipeline-Stufen, aber sind bei weitem energieeffizienter.
Naja, Prescott hatte immerhin ~30, da ist noch etwas Luft nach oben ;)
Naja, Prescott hatte immerhin ~30, da ist noch etwas Luft nach oben ;)
Nicht wenn man die IPC nicht senken will.
Nicht wenn man die IPC nicht senken will.
Prescott hatte sehr ähnliche IPC wie Northwood mit seinen 20 Stages, und davon ist man nicht mehr weit entfernt.
Eine längere Pipeline heißt nicht zwangsläufig schlechtere IPC-Leistung, man kann durchaus mit diversen Maßnahmen Stalls in sehr vielen Fällen abfangen.
Netburst hatte nicht nur wegen der langen Pipeline eine vergleichsweise schlechte IPC-Leistung.
Prescott hatte sehr ähnliche IPC wie Northwood mit seinen 20 Stages, und davon ist man nicht mehr weit entfernt.
Eine längere Pipeline heißt nicht zwangsläufig schlechtere IPC-Leistung, man kann durchaus mit diversen Maßnahmen Stalls in sehr vielen Fällen abfangen.
Netburst hatte nicht nur wegen der langen Pipeline eine vergleichsweise schlechte IPC-Leistung.
Dazu muss man aber wiederum die restliche Logik anpassen(wahrscheinlich deutlich größer/komplexer).
Sonst ist es wohl tatsächlich so, dass gilt: Je mehr Stages, destso schlechter die IPC.
Und ein bisschen schlechter war die IPC des Prescotts schon gegenüber des Northwoods. (Ich erinnere mich da an entäuschte Tester beim Vergleich des 3.4GHz Precotts gegen den 3.2Ghz Northwood)
BlackBirdSR
2010-01-16, 15:15:22
Und ein bisschen schlechter war die IPC des Prescotts schon gegenüber des Northwoods. (Ich erinnere mich da an entäuschte Tester beim Vergleich des 3.4GHz Precotts gegen den 3.2Ghz Northwood)
Das liegt aber nicht nur daran, sondern an Sachen wie dem L1-Cache mit 4 Takten Latenz gegenüber 2 usw. Im Endeffekt ist es erstaunlich, dass Prescott an Northwood heranreichen konnte bei gleichen Taktraten. Das wäre natürlich egal gewesen, wenn Prescott mit 5-6 GHz läuft.
Seien wir froh, who knows ob wir mit Prescott schon so früh Quad-Cores gehabt hätten - und deren Nutzen ist ja inzwischen weit größer, als eine hypothetische 10GHz CPU.
Seien wir froh, who knows ob wir mit Prescott schon so früh Quad-Cores gehabt hätten - und deren Nutzen ist ja inzwischen weit größer, als eine hypothetische 10GHz CPU.
Mir wäre ein 10+GHz SC wesentlich lieber als die heutigen Quadcores.
Mir wäre ein 10+GHz SC wesentlich lieber als die heutigen Quadcores.
Vielen anderen die jetzt viel Geld für multicoreoptimierung ausgeben müssen wohl auch.
Das ändert aber wenig daran das entsprechend optimierte Programme schneller sind als auf einem kern mit nur 2-2,5 mal mehr Takt.
Das ändert aber wenig daran das entsprechend optimierte Programme schneller sind als auf einem kern mit nur 2-2,5 mal mehr Takt.
Das wird schon recht knapp. Ein Singlecore mit 3-fachem Takt dürfte schon in fast allen Fällen mindestens so schnell wie ein Quadcore sein.
Je mehr Kerne desto schwieriger wird es auch für den Multicore sich abzusetzen.
Ein gesunder Mittelweg wäre wohl ideal, 2 Kerne (evtl. mit HT) und hoher Takt wären wohl relativ ideal.
Stattdessen haben wir aber quasi stagnierende Taktfrequenzen und immer mehr Kerne. Bei Intel werden die stagnierenden Taktfrequenzen zumindest durch steigende IPC etwas ausgeglichen, wobei der Sprung von 45nm-Core2 auf Nehalem jetzt auch nicht so weltbewegend ist. Bei AMD tut sich selbst beim IPC recht wenig.
Das wird schon recht knapp. Ein Singlecore mit 3-fachem Takt dürfte schon in fast allen Fällen mindestens so schnell wie ein Quadcore sein.
Je mehr Kerne desto schwieriger wird es auch für den Multicore sich abzusetzen.
Ein gesunder Mittelweg wäre wohl ideal, 2 Kerne (evtl. mit HT) und hoher Takt wären wohl relativ ideal.
Stattdessen haben wir aber quasi stagnierende Taktfrequenzen und immer mehr Kerne. Bei Intel werden die stagnierenden Taktfrequenzen zumindest durch steigende IPC etwas ausgeglichen, wobei der Sprung von 45nm-Core2 auf Nehalem jetzt auch nicht so weltbewegend ist. Bei AMD tut sich selbst beim IPC recht wenig.
Höhere Taktraten sind aufgrund von Lekströmen nicht drin (gibt hier aber auch schon einige Threads dazu)
Bei AMD tat sich zuletzt beim K10.5 was und das nexte mal beim Bulldozer.
Die Lifecycles sind nun mal so lang im Prozessormarkt.
Höhere Taktraten sind aufgrund von Lekströmen nicht drin (gibt hier aber auch schon einige Threads dazu)
Taktraten haben mit Leckströmen nur indirekt etwas zu tun.
Mit höheren Taktraten erhöhen sich erstmal nur der "normale" Stromverbrauch, die Leckströme bleiben identisch. Erst wenn man auch die Spannung erhöhen muss, werden auch die Leckströme entsprechend höher.
Es wäre aber durchaus denkbar die CPU so zu designen, dass man auch mit vergleichsweise niedrigen Spannungen hohe Taktraten erreicht.
Acid-Beatz
2010-01-17, 18:53:56
Leckströme hängen meines Wissens nach NUR von der Fertigungsgröße ab, deswegen wird es in geraumer Zukunft auch hier Probleme geben.
Die höheren Taktraten wurden unter anderem auch durch die Verkleinerung erreicht weshalb dann aus oben genannten Grund eben auch die Leckströme gestiegen sind.
BlackBirdSR
2010-01-19, 10:12:53
Leckströme hängen meines Wissens nach NUR von der Fertigungsgröße ab,
Leider nicht..
Design, Prozess und Material.
Leider nicht..
Design, Prozess und Material.
Jo, Intels P4 wäre mit AMDs SOI Prozess ironischerweise vielleicht ganz brauchbar gewesen :freak:
Der englische Begriff silicon on insulator (SOI, deutsch „Silizium (http://de.wikipedia.org/wiki/Silizium) auf einem Isolator“) bezeichnet eine Herstellungstechnologie für Schaltkreise (http://de.wikipedia.org/wiki/Integrierter_Schaltkreis) auf Basis von Silizium-Substraten. Diese befinden sich auf einem isolierenden Material (http://de.wikipedia.org/wiki/Isolator), wodurch sich kürzere Schaltzeiten (http://de.wikipedia.org/w/index.php?title=Schaltzeit&action=edit&redlink=1) und geringere Leistungsaufnahmen (http://de.wikipedia.org/wiki/CPU-Leistungsaufnahme), besonders bezüglich der Leckströme (http://de.wikipedia.org/wiki/Leckstrom), ergeben. Sie wurde zuerst von AMD (http://de.wikipedia.org/wiki/Advanced_Micro_Devices)[1] (http://de.wikipedia.org/wiki/Silicon_on_Insulator#cite_note-0)[2] (http://de.wikipedia.org/wiki/Silicon_on_Insulator#cite_note-1) für den AMD K8 (http://de.wikipedia.org/wiki/AMD_K8) [3] (http://de.wikipedia.org/wiki/Silicon_on_Insulator#cite_note-2) entwickelt und großtechnisch umgesetzt.
http://de.wikipedia.org/wiki/Silicon_on_Insulator
ciao
Alex
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.