Was kommt (nach den ersten Deneb (K10.5+)) fuer den Desktop bis zum Launch der BD(APUs)?
- Ersteller TNT
- Erstellt am
Dresdenboy
Redaktion
☆☆☆☆☆☆
Ich habe jetzt das richtige Bild im Blog veröffentlicht.
@Opteron:
An die Dispatcher-Anbindung schreiben wir mal TBD dran
Das ist in der Tat diskussionswürdig. Ich werde mal nach weiteren Texthinweisen suchen. Passen würde es dennoch, da die INT-Cluster nicht auf Dispatch-Pakete in jedem Zyklus angewiesen sind, da ein Paket nach meinem Verständnis für 2 Zyklen Auslastung reicht. Sollte die FPU mit der entspr. Breite und Unterteilung arbeiten, kann sie aus der Menge an Dispatch-Paketen auch Nutzen schlagen.
Das Credo dürfte (auch laut JF) etwa lauten: Alles so effizient wie (wirtschaftlich) möglich. Möglichst wenige idle Einheiten während der Ausführung. Also Fast Path Decoder während µCode-Decoding mit nutzen, freie FPU-Teil-FUs für zusätzliche Ausführung nutzen, freie Int-Cluster für Eager Execution...
@Opteron:
An die Dispatcher-Anbindung schreiben wir mal TBD dran
Das ist in der Tat diskussionswürdig. Ich werde mal nach weiteren Texthinweisen suchen. Passen würde es dennoch, da die INT-Cluster nicht auf Dispatch-Pakete in jedem Zyklus angewiesen sind, da ein Paket nach meinem Verständnis für 2 Zyklen Auslastung reicht. Sollte die FPU mit der entspr. Breite und Unterteilung arbeiten, kann sie aus der Menge an Dispatch-Paketen auch Nutzen schlagen.Das Credo dürfte (auch laut JF) etwa lauten: Alles so effizient wie (wirtschaftlich) möglich. Möglichst wenige idle Einheiten während der Ausführung. Also Fast Path Decoder während µCode-Decoding mit nutzen, freie FPU-Teil-FUs für zusätzliche Ausführung nutzen, freie Int-Cluster für Eager Execution...
Dr@
Grand Admiral Special
Die gibts noch Keines
Ich wollt ja auch nicht wissen obs nen Tape Out gab.Ich hab mal in den Raum gestellt, dass die reale Umsetzung bezüglich der relativen Lage zueinander ja nicht 1 zu 1 sein muss. Und wollte mal eure fachkundige Meinung dazu hören.
MfG
PS Danke für das Blockdiagramm Dresdenboy
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Blöde Frage: Wieso ?
Ne Pipline muss doch immer gefüllt sein, wenn da kein Nachschub da ist -> idle -> ineffizient, sollte nach dem von Dir geschilderten Design Credo aber vermieden werden
Oder übersehe ich etwas ?
Apropos ... da fallen mir die Registersätze auf. Wenn alles so effizient genutzt werden sollte, dann sollten beide Cluster auch einen gemeinsamen Register Pool benützen (Hinweis für die, die es nicht wissen, es gibt mehr Register als x64 vorsieht, wg. Register Renaming). Gabs da nicht auch in einem Patent was dazu ?
Ist auf alle Fälle auch praktisch, wenn Cluster 2 spekuliert, da durch Renaming dann die Ergebnisse schnell in Cluster 1 zur Verfügung stünden.
Auf was ich raus will: Die FPU dazwischen bei sowas "etwas" störend
Ansonsten ... fürs nächste Bild könntest Du Dir überlegen, noch ne Map Unit hinzuzufügen, die ist ja für das spekulative Ausführen in Cluster 2 nötig:
http://www.planet3dnow.de/vbulletin/showthread.php?p=3929261#post3929261
Oder sparst Du Dir das, da es zu einem Bulldozer 2.0 gehört ?
ciao
Alex
Zuletzt bearbeitet:
Falls es noch keiner gesehen hat:
httx://wwx.computerbase.de/news/wirtschaft/unternehmen/intel/2009/august/intel-technologie-ausblick_4_jahr_2022/
Intel gibt einen Ausblick auf das, was sie erreichen WOLLEN.
Was meint ihr dazu? Bis wohin (Jahr/Fertigungsgröße) kann man das realistisch sehen?
httx://wwx.computerbase.de/news/wirtschaft/unternehmen/intel/2009/august/intel-technologie-ausblick_4_jahr_2022/
Intel gibt einen Ausblick auf das, was sie erreichen WOLLEN.
Was meint ihr dazu? Bis wohin (Jahr/Fertigungsgröße) kann man das realistisch sehen?
ich denke, dass es genauso zu sehen ist - was sie erreichen wollen - Intel haelt es fuer realistisch und man darf das 'Mooresche Gesetz' nicht vergessen - das zwingt ja nun gerade zu diesen Verbesserung.
Dass es nicht mehr haelt wurde ja schon oft prophezeit...
Intel sieht ja selbst grosse Schwierigkeiten in der Entwicklung auf sich zu kommen - spaetestens bei 16/11nm kennt selbst Intel den Loesungsweg nicht wirklich, aber bis 2014 fliesst noch viel Wasser den Rhein runter.Wer weiss wie dann die Halbleiterwelt aussieht.
Zuletzt bearbeitet:
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Sorry, da bekomme ich Kopfschmerzen. Es handelt sich weder um eine Gesetzmässigkeit rund um das Mohrsches Salz, noch eine französische Ortschaft.
Sein Gesetz ist nach dem Intel-Mitgründer Gordon Moore benannt.
MFG Bobo(2009)
Zuletzt bearbeitet:
Ups...ist nun korrigiert...!!
Dann sollte man Mooresches Gesetz in eine Mooresche Regel umbennen, denn eine Regel muss nicht immer eingehalten werden im Gegensatz zu einem Gesetz. (Hab ich mal in der Schule gelernt, warum es nur RGT-Regel (Reaktionsgeschwindigkeit-Temperatur-Regel) heißt und kein Gesetz ist, da die Gesetze allgemeingültig sind.
Edit:
Kleines Wikizitat:
Edit:
Kleines Wikizitat:
Zuletzt bearbeitet:
Ja, sicher..aber der Begriff 'Gesetz' in diesem Zusammenhang hat sich etabliert - bislang hat es auch gehalten - und wer sagt denn, dass man Gesetze nicht auf brechen kann?
!!Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Jetzt mach dir nicht ins Hemd
. Member TNT war so frei uns sogar gleich einen Link auf die Wikipdia zu setzen, worin die schillernde Vielgestalt des scheinbaren Gesetzes beschrieben wird. Diese Faustregel hat sich nun mal als "Gesetz" in der Umgangssprache festgesetzt.MFG Bobo(2009)
rkinet
Grand Admiral Special
http://www.computerbase.de/news/wir...ugust/intel-technologie-ausblick_4_jahr_2022/Ja, sicher..aber der Begriff 'Gesetz' in diesem Zusammenhang hat sich etabliert - bislang hat es auch gehalten - und wer sagt denn, dass man Gesetze nicht auf brechen kann?
Zumindest im Massenmarkt könnte sich langsam ein Ende der Strukturverkleinerung etablieren. Allerdings wäre dann das 'Gesetz' länger in der Verwendung gewesen als viele juristische Gesetze auf Erden.
Ein 'Erfolg' des Gesetztes ist ja auch die Abkehr von Single-Thread bei GPU und zuletzt CPU da ja mehr Bausteile (elektronisch) vernünftiger als GHz-Orgien sind.
Und es stellt sich die Frage ob wir wirklich noch deutlich unterhalb von 22nm Mainstream-Produkte einmal benötigen werden. Da sind dann auch Produkte die Milliarden funktionsfähige Transistoren enthalten müssen. Bei DRAMs landen wird selbst bei 'nur' 16nm einmal in der 50-100 Milliarden Transitoren je DIE Liga.
Und für CPUs bleibt jenseits der Shrinks und Multicore die Frage wer kann und will die Entwicklungskosten für immer ausgetüftetere CPU-Designs bezahlen ?
Zudem lassen Ideen wie Windows 8 (= höhere IPC-Zahl) erahnen dass wir im Softwarebereich noch lange nicht optimiert arbeiten was gerade bei zunehemder Mobilverwendung und low power Desktop sinnvoller als Shrinks wäre.
Ähm rkinet. Jetzt hast du wieder deine bunten 5 Minuten, oder?
Ja, wir werden mit weiteren Strukturverkleinerungen in ganz neue Bereiche der Transistorenmengen vorstoßen. Die Ramgröße verhält sich allerdings direkt proportional zur Transistormenge, wir werden dort also noch lange keinen Stillstand feststellen können. Selbst wenn wir im Mobil- und Desktopbereich diese Mengen nicht brauchen. Wissenschaftliche Simulationen werden immer mehr Ram benötigen, weil man nur durch höhere Datenmengen näher an die Realität heran kommen kann. Und die Wissenschaft ist nun mal auch eine große Triebkraft hinter der Rechnerentwicklung.
Und zu deiner "Frage": wir befinden uns schon heute bei den Entwicklungskosten in Bereichen, die sich vor 10 Jahren noch niemand hätte träumen lassen. Trotzdem hat sich auf diesem Weg der Erhöhung noch nie jemand darüber Gedanken gemacht. Warum? Ganz einfach, weil der Bedarf an Rechenleistung nicht einfach zum Stillstand kommt. Es wird sich also immer jemand finden, der für höhere Rechenleistungen bezahlen wird.
Auch wenn es DIR momentan so schein, als würden Rechner mit höherer Leistung nutzlos sein: Wer sagt denn, das ewig mit Rechnern arbeiten werden, die eine GUI besitzen und über Maus und Tastatur steuerbar sind. An den Hochschulen etabliert sich gerade eine neue Wissenschaft (kognitive Psychologoie), welche sich nur damit beschäftigt neue Methoden zu finden, die Bedienung von Maschinen für den Menschen einfacher zu machen. Vll kommt von dort ja bald ein neues Konzept zur Mensch-Maschine-Interaktion, die ganz andere Dimensionen an Rechenleistug fordern. Was im Umkehrschluss bedeutet: neue Wege können nur gefunden werden, wenn die Rechenleistung auch weiterhin gesteigert wird.
Das ding ist ja, dass wir Irgedwann in Strukturbreiten vordringen, die nicht mehr weit weg von einzelnen Atomen sind (Bindungslänge beim Silizium rd 220pm je nach Art der Verbindung). Und wenn man an diesem Punkt angelangt ist, ist man mit Shrinks am Ende. Ich kann mir net vorstellen, dass einzelne Atome die Aufgaben eines Transistors übernehmen. Das kleinste Halbmetallatom mit drei Valenzelektronen ist das Bor.
Ich denk da eher an die Quantencomputer, die nun erstma noch 20 Jahre Zeit haben zu reifen. Und wenn diese dann nix taugen, dann hat man was neues gefunden, oder muss es halt hinnehmen, dass die DIEs immer größer werden. Vllt hat man ja bis dahin die Kühlung einfach besser im Griff. Wenn man das mal mit Autos vergleicht, sind diese in den Jahren auch größer geworden. Die Motoren laufen effizienter (war neulig mal im Benzmuseum. Als der Motor rauskam konnte man von einem PS bei einem Liter Hubraum ausgehen, heute sinds auch ohne Aufladung über 100). Es gab ja mal schöne Ansätze, die irgendwie wohl net Marktreif geworden sind, wie der Ionenwindlüfter. Naja. Warten mer ma bis 2025. Da ist der Launch der Evergreen noch recht Zeitnah ^^
Ich denk da eher an die Quantencomputer, die nun erstma noch 20 Jahre Zeit haben zu reifen. Und wenn diese dann nix taugen, dann hat man was neues gefunden, oder muss es halt hinnehmen, dass die DIEs immer größer werden. Vllt hat man ja bis dahin die Kühlung einfach besser im Griff. Wenn man das mal mit Autos vergleicht, sind diese in den Jahren auch größer geworden. Die Motoren laufen effizienter (war neulig mal im Benzmuseum. Als der Motor rauskam konnte man von einem PS bei einem Liter Hubraum ausgehen, heute sinds auch ohne Aufladung über 100). Es gab ja mal schöne Ansätze, die irgendwie wohl net Marktreif geworden sind, wie der Ionenwindlüfter. Naja. Warten mer ma bis 2025. Da ist der Launch der Evergreen noch recht Zeitnah ^^
rkinet
Grand Admiral Special
Bezahlen ?
Anno 2022 ... K17+4 Sempron X16 mit 4 GHz (Turbomudsus bis 4 aktive Cores) & 32MB Cache für 19€ - boxed ...
Der Fall 'Atom 2xx' zeigt dass wir das Ende der Fahnenstange in einigen Marktsegmenten schon erreicht haben.
Und bei DRAM / 3-4 GByte und 64 Bit hat sich ja schon deutlich Widerstand gezeigt.
Und einige HighEnd Rechenprofis greifen heute schon zu GPUs (wie in Cern) um Daten vorzuverarbeiten.
Ob man das selbst einmal zuhause so bekommt ist fragwürdig. Eher vorstellbar eine Art Signalverarbeitungs-Google, wo stationär in großem Umfang optische und akustische Informationen ausgewertet werden. Und die heimischen Clients blieben kompakt und stromsparend.
Wie die Äußerungen und die Roadmap bei Intel zeigen ist bald Ende der Fahnenstande erreicht. Zudem benötigt es viel Käuferbeiträge um noch in mehr Technik zu investieren.
Und da ist kaum eine Perspektive erkennbar.
Markus Everson
Grand Admiral Special
Du konstruierst einen Widerspruch wo keiner ist. Rechenleistung der GPU ist immer noch Rechenleistung und Rechenleistung der GPU skaliert bisher und auf absehbare Zeit mit der Zahl der Transistoren.
Ja, ist es. Allerdings war es für ct auch mal fragwürdig ob nach dem 50MHz 486er noch größere Taktsteigerungen möglich sind. Vor 15 Jahren wären mehr als 16 MB Ram in einem Computer fraglich gewesen, vor 10 Jahren mehr als 1 Gigabyte auf einer Festplatte.
Sicher ist das es Grenzen des Wachstums gibt. Auch bei Computern. Fakt ist aber das wir die noch nicht gefunden haben.
rkinet erzählt Geschichten...gähn...
rkinet
Grand Admiral Special
a) Intel Atom statt Penryn ... wie http://www.computerbase.de/news/har...2009/august/asus_termin_ion-eee-box_-eee-top/
b) AMD 'BE'-Edition ab $100 statt $800 FX-Modelle ...
Die Grenzen beim Wachstum sind längst sichtbar. Und gleichzeitig sind ja die 32/28nm bzw. teils 22/18nm schon recht realistisch in der Umsetzung. Das Wachstum wird also bis dahin laufen und gleichzeitig immer mehr Kunden im low budget Bereich ordern.
AMD hat dies sogar einmal in seiner 50x15 Initiative vorgemacht. Obige 'Ion-Eee-Box und -Eee-Top' liegen Faktor 3-5 über dem alten Geode Design.
Wie http://50x15.amd.com/en-us/internet_usage.aspx zeigt betracht selbst AMD low budget als sehr relevant für die Zukunft bei den Kunden.
Nur, um ins Internet zu kommen wird man 2015 locker mit 32/22nm Produkten auskommen und nicht nach 4nm Technik lechzen.
Du vergisst immer, das du nur die Hardwareentwicklungen bis 2015 absehen kannst. Du betrachtest aber keine möglichen Softwareentwicklungen bis dahin. Was weißt du, wie sich das Internet in 5 Jahren bedienen lässt und ob diese Form der Bedienung nicht einiges mehr an Rechenleistung erfordert, als du es dir heute vorstellen kannst?
Markus Everson
Grand Admiral Special
Du solltest wirklich mal versuchen wenigstens für 15 Millisekunden beim gleichen Thema zu bleiben.
Es ging um Transistoren pro Chip. Es ging nicht um neue Märkte und nicht um Preisverfall.
Aber was red ich ... bringt eh nichts.
rkinet
Grand Admiral Special
Natürlich gehts um Preisverfall.
Auch Intel kann sich keinen Okta-Core Atom in 22nm für $15/ Stück erlauben.
Entweder es gibt gut zahlende Märkte oder der technische Aufwand für die Produkte muss überschaubar klein sein.
Die möglichen Kunden fürs Internet leben in Schwellenländern und werden zunehemend weltweit interessant.
Ob wir hingegen 2015 bei ebay in 3D bieten können und planet3dnow nur ab 100 MBit/s Leistung noch performant geladen werden kann wird kaum die Produktentwicklung beeinflussen. Und Microsoft hat schon bei Win 7 und noch mehr bei Win 8 mehr Performance bei geringeren Verbrauch an Rechentakten angekündigt.
Was auch daran liegt dass Mobilanwender immer zahlreicher werden und hier Kompaktheit bei Code und Resourcenbedarf wichtig ist.
Zuletzt bearbeitet:
Dresdenboy
Redaktion
☆☆☆☆☆☆
Blöde Frage: Wieso ?
Ne Pipline muss doch immer gefüllt sein, wenn da kein Nachschub da ist -> idle -> ineffizient, sollte nach dem von Dir geschilderten Design Credo aber vermieden werden
Nach derzeitigem Stand hat jeder INT Cluster je 2 ALUs u. 2 AGUs. Die 4 Operationen in einem Dispatch-Paket dürften, wenn ich nichts übersehen habe, bis zu 4 macro-operations, also 8 micro-ops enthalten, nach altem Schema [ALU|AGU]. Das reicht für 2 Takte -> volle Auslastung erreichbar.
Apropos ... da fallen mir die Registersätze auf. Wenn alles so effizient genutzt werden sollte, dann sollten beide Cluster auch einen gemeinsamen Register Pool benützen (Hinweis für die, die es nicht wissen, es gibt mehr Register als x64 vorsieht, wg. Register Renaming). Gabs da nicht auch in einem Patent was dazu ?
Ist auf alle Fälle auch praktisch, wenn Cluster 2 spekuliert, da durch Renaming dann die Ergebnisse schnell in Cluster 1 zur Verfügung stünden.
Auf was ich raus will: Die FPU dazwischen bei sowas "etwas" störend
Ansonsten ... fürs nächste Bild könntest Du Dir überlegen, noch ne Map Unit hinzuzufügen, die ist ja für das spekulative Ausführen in Cluster 2 nötig:
http://www.planet3dnow.de/vbulletin/showthread.php?p=3929261#post3929261
Oder sparst Du Dir das, da es zu einem Bulldozer 2.0 gehört ?
Was mal ein überarbeiteter Kern wird, wissen wir nicht. Da bleibt nur Raten anhand von Filing Dates
Ein gemeinsamer Register Pool erfordert aber noch mehr Arbitration usw. Ein Patent war ja schon dafür gedacht, nur noch 6 read u. 4 write ports zu haben (passend für einen Cluster). Das ist auch effizienter ("divide and conquer"
). Normalerweise ist eine Map-Unit in jedem Cluster dabei (nur noch nicht dargestellt, aber OOO-typisch). Aber das (auch notwendige) Renaming über 4 ALUs, 4 AGUs u. 2 Threads wäre ganz schön happig. Sowieso würde eager execution öfters unabhängige Codestückchen abarbeiten, wo separates Renaming stattfände. Sehe ich also eher nicht so.Wenn die Int-Cluster nebeneinander liegen, können sie auch besser kommunizieren. Nur die FPU hat's dann etwas weiter zu den LSUs u. Caches, was ja physikalisch recht große Brocken sind. Aber da schwebt mir schon ein Design vor (auf Ebene der Funktionsblöcke auf dem Die).
Damit wäre eben auch möglich, 2 Cluster an einen Dispatch Bus zu hängen u. die FPU an den anderen. Da wahrscheinlich irgendwelche microcoded instructions (Known Good Code) eher an die FPU gerichtet sind, passt das auch. Ich werde so etwas mal zeichnen.
Zuletzt bearbeitet:
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Jo, für einen Cluster, aber bis zum Dispatcher muss man doch noch an Cluster 2 (und FPU) denken ... deren Queue will auch gefüllt werden. Wenn ich Dich jetzt richtig verstehe buchst Du die ganze Decoder/Dispatch Bandbreite nur auf den einen INT Cluster, oder ?
Ja da war was, sogar mit den FPU Register wenn ich mich recht erinnere, aber gut, das wird kompliziert ^^Ein gemeinsamer Register Pool erfordert aber noch mehr Arbitration usw. Ein Patent war ja schon dafür gedacht, nur noch 6 read u. 4 write ports zu haben (passend für einen Cluster). Das ist auch effizienter ("divide and conquer"
Ok, na dann lassen wirs mal
Jo das meinte ich, ich wüßte gar nicht, wies anders gehen sollte
ciao
Alex
Dresdenboy
Redaktion
☆☆☆☆☆☆
Woran ich dachte, war folgendes Timing:
Takt 0: 4 Ops -> Cluster 1, 4 Ops -> FPU (wenn eine Gruppe davon von microcoded x86-Befehlen kommt)
Takt 1: 4 Ops -> Cluster 2, 4 Ops -> FPU (dito)
Auslastung wäre gegeben, aber nur unter den µCode-Einschränkungen. Wenn aber AVX erstmal über µCode abgebildet wird, wäre das auch kein Problem.
Effizienz entsteht ja auch, wenn ein guter Kompromiss zwischen idlen Einheiten u. Realität des Befehlsstroms gefunden wird. Es wäre ja auch nicht der Designphilosophie entsprechend, wenn die Decoder jeden Takt alle Einheiten proppenvoll stopfen könnten, während gerade INT-Code mit vielen Speicherreferenzen u. Sprüngen abläuft
Hier noch das neuere Bildchen:
Schau auch mal, was sich beim Dispatcher getan hat
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Ah nun ... hab schlicht und ergreifend den 2ten Dispatchport übersehen ... sind ja 8 insgesamt
Wie wärs wenn Du das noch ins Bildchen einbaust ? 4 Linien zu den INT Cluster, 4 zur FPU. Dann übersieht man nichts
Stimmt auch wieder, ich frag mich eh, wie das so gut zur Zeit klappt, da kommen nur 3 MacroOps pro Takt für 9 FUs (wenn man die AGUs mitzählt) durch. So oder so sind da jetzt 8 für 12(?) FUs weit besser.Effizienz entsteht ja auch, wenn ein guter Kompromiss zwischen idlen Einheiten u. Realität des Befehlsstroms gefunden wird. Es wäre ja auch nicht der Designphilosophie entsprechend, wenn die Decoder jeden Takt alle Einheiten proppenvoll stopfen könnten, während gerade INT-Code mit vielen Speicherreferenzen u. Sprüngen abläuft
Aja, der Cache, gutSchau auch mal, was sich beim Dispatcher getan hat
Hoffentlich ist der auch dabei.Ansonsten: Charlie hat einen Artikel zum Magny Cours online:
http://www.semiaccurate.com/2009/08/24/amd-outs-socket-g34/
AMD musste da zwar bei den HTr Links sparen, meistens gibts nur 8bit, aber besser als nichts
ciao
Alex
Zuletzt bearbeitet:
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Also ich bin beim Zählen auf einen zusätzlichen HyperTransport-Link gekommen.
Heise berichtet darüber ebenso: "Hot-Chips: Details zu AMDs Zwölfkerner". Im Forum dort habe ich die Bemerkungen des Texters kommentiert, das AMD da "halbe Links" nutze. Das mag zwar richtig sein, wenn man die Datenraten betrachtet. Aber das ist die Halbe Wahrheit, wenn man noch die Hops berücksichtigt, dann sind das 4 Links.
Hops-Zählweise:
16 Lanes nicht kohärent = 1
16 Lanes Kohärent extern = 1
8 Lanes Kohärent extern = 1
16 + 8 Lanes Kohärent intern = 1
-> 4 HyperTransport-Links
Datenratenzählweise:
16 Lanes nicht kohärent = 1
16 Lanes Kohärent extern = 1
8 Lanes Kohärent extern = "0,5"
16 + 8 Lanes Kohärent intern = "1,5"
-> 4 HyperTransport-Links
Zur Nomenklatur von Multicores
Ein Zwölfkerner kann man auch als Dodecacore bezeichnen, so wie man einen 16-Kerner als Hexacore bezeichnen kann. Chemiker haben da schon lange eine normierte Zähl-Nomenklatur.
Ach ja, RealworldTech hat noch erste Bemerkungen zum IBM Power7 und dem Niagara3 (Rainbow Falls) gemacht. Bis auf die Info von Quadcores beim neuen kommenden Power7, Embedded-RAM (eDRAM) mit 16 MByte L3 Cache und der Abkehr vom HochtaktDesign war da aber noch wenig drin.
MFG Bobo(2009)
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Äh ne ich meinte nicht die Anzahl, das sind vier Ports, ja, da braucht man nicht großartig zählen, das steht auch schon in der Grafik:
Was ich meinte ist die Bandbreite, teilweise 8 statt der üblichen 16bit.
Deine Zählweise finde ich aber ehrlich gesagt etwas gewagt. Hops benützt man nur zur Entfernungsangabe, und wenn Du die "Datenratenzählweise" anwendest ist das auch krude, da es u.a. 32bit Links gibt. Schreib vielleicht dazu, dass Du 16bit Links meinst, dann passts einigermaßen
Edit:
Hab erst jetzt den Text zum Bild gelesen .. weiss nicht, was der Autor da für ein Problem hat .. "halbe" Links gibts nicht, sind halt teilweise 8 bit anstatt der bisher üblichen 16bit ... na und ? 16 bit ist die Hälfte von 32 und es gibt auch 2bit Links, das sieht mal wieder nach Halbwissen aus.
Danke für die restlichen Links (http, nicht HTr ^^)
Alex
Was ich meinte ist die Bandbreite, teilweise 8 statt der üblichen 16bit.
Deine Zählweise finde ich aber ehrlich gesagt etwas gewagt. Hops benützt man nur zur Entfernungsangabe, und wenn Du die "Datenratenzählweise" anwendest ist das auch krude, da es u.a. 32bit Links gibt. Schreib vielleicht dazu, dass Du 16bit Links meinst, dann passts einigermaßen
Edit:
Hab erst jetzt den Text zum Bild gelesen .. weiss nicht, was der Autor da für ein Problem hat .. "halbe" Links gibts nicht, sind halt teilweise 8 bit anstatt der bisher üblichen 16bit ... na und ? 16 bit ist die Hälfte von 32 und es gibt auch 2bit Links, das sieht mal wieder nach Halbwissen aus.
Danke für die restlichen Links (http, nicht HTr ^^)
Alex
Zuletzt bearbeitet:
Ähnliche Themen
