Intel Roadmap Xeon/Itanium

[Desti]

FYI

http://www.gzeasy.com/newsphoto/y2k4/01/14/intel2.jpg

http://www.gzeasy.com/newsphoto/y2k4/01/14/intel1.jpg

[Bokill]

Nanü... der Itani(c)um wird weitergepflegt (Mit den Alphajungs ist dann aber auch noch viel zu erwarten) und der P4 für Serverzwecke verschwindet langsam im Nebel der Ewigkeit?

MFG Bokill

[LOCHFRASS]

Wann ist mit den ersten PSB 800 Xeon Brettern zu rechenen? Gibts da schon Ankündigungen seitens der Hersteller? Werden die Boards Pin-kompatibel zu den derzeitigen Xeons sein?

[GloomY]

9 MB L3 Cache ... wtf? :O
Welche Anwendung soll denn davon profitieren? :???:

[Gast]

Original geschrieben von GloomY
9 MB L3 Cache ... wtf? :O
Welche Anwendung soll denn davon profitieren? :???:


9MB?....doch wohl eher 24MB

[GloomY]

Original geschrieben von Gast
9MB?....doch wohl eher 24MB Ja, das ist der Montecito. Bei dem dauert's noch eine Weile bis er kommt und ausserdem ist das eine Dual-Core CPU, also kann man die Cache Größe locker durch 2 teilen. Obwohl 12 MB pro Core natürlich auch nicht gerade wenig sind. Aber bis 2005 ist ja auch noch eine ganze Weile. Bis dahin ist die durchschnittliche Datenmenge, die eine CPU üblicherweise zum Verarbeiten braucht, auch schon wieder ein Stückchen angestiegen.

Als nächstes kommt der Madison mit 9 MB L3, und alleine da kann man schon die Frage stellen, was das bringen soll (und wer das bezahlen soll). Ich war damals bei der EV6 mit ihren 8 MB L2 Cache schon recht skeptisch und war froh, als die EV7 dann "nur noch" 1,75 MB L2 besaß (dafür dann aber on-die mit vollem Prozessortakt und breiter Anbindung =) ).

Interessant ist auch die zweite Zeile: "Leading $ / FLOP". Da hat sich Intel aber ein großes Ziel vorgenommen....

[BlackBirdSR]

Naja.. da bin ich aber gespannt.

Bisher hat Intel den L3 Cache innerhalb des Cores so verteilt, dass man möglichst viel Platz spart. Also nicht so, wie AMD oder bei den IA32 einfach dranpacken und fertig.
Ich will gar nicht wissen, welch Arbeit das bei 9 bzw 12MB wird.

Naja und so langsam scheint der Cache auch nicht zu sein.
Intel gibt immerhin mit ca 64GB/s Gesamtbandbreite! bei 1GHz an.

Was ich aber gerne wüsste: Macht es den Alpha Leuten wirklich so viel Spass, statt am EV8 an diesem Monster zu arbeiten? Ob wir da die Tarantula Erweiterungen für den EV8, oder dessen SMT Funktionalität überhaupt jemals in IA64 CPUs sehen werden?

[Smoking_Red]

Original geschrieben von GloomY
9 MB L3 Cache ... wtf? :O
Welche Anwendung soll denn davon profitieren? :???:
SAP, DB2 etc. pp. - Ich geb dir aber recht: Für den Heim-oder SoHo-Bereich ist das wirklich nix mehr...Reine DataCenter CPUs...:D

[Endorphine]

Original geschrieben von GloomY
9 MB L3 Cache ... wtf? :O
Welche Anwendung soll denn davon profitieren? :???: Praktisch alle technisch-wissenschaftlichen Anwendungen sowie Datenbanken etc.? Die laufen häufig vollständig cachegrössenlimitiert.

Da gab's mal einen schönen Graphen in der iX. Speicherbandbreite (bzw. Latenz, je nach Anwendungsfall) hat in diesem Anwendungsfeld eine immense Bedeutung und limitiert sehr häufig.

[Muh-sagt-die-Kuh]

Original geschrieben von BlackBirdSR
Was ich aber gerne wüsste: Macht es den Alpha Leuten wirklich so viel Spass, statt am EV8 an diesem Monster zu arbeiten? Ob wir da die Tarantula Erweiterungen für den EV8, oder dessen SMT Funktionalität überhaupt jemals in IA64 CPUs sehen werden? SMT ist bei IA-64 CPUs so eine Sache...


Predication hat prinzipiell eine ziemlich hohe interne Auslastung zur Folge
Das in-Order Desgign macht die Sache nicht gerade einfach bzw begrenzt sinnvoll
Anderernseits könnte man vielleicht einfach 128-bit Instruction Packages aus 2 Threads nehmen


Wäre sicherlich einfacher zu beurteilen, wenn ich die interne Auslastung kennen würde.

[Gast]

Original geschrieben von LOCHFRASS
Wann ist mit den ersten PSB 800 Xeon Brettern zu rechenen? Gibts da schon Ankündigungen seitens der Hersteller? Werden die Boards Pin-kompatibel zu den derzeitigen Xeons sein?

Kommen die nicht schon im LGA Pakage?

[GloomY]

Original geschrieben von BlackBirdSR
Naja.. da bin ich aber gespannt.

Bisher hat Intel den L3 Cache innerhalb des Cores so verteilt, dass man möglichst viel Platz spart. Also nicht so, wie AMD oder bei den IA32 einfach dranpacken und fertig.
Ich will gar nicht wissen, welch Arbeit das bei 9 bzw 12MB wird.Du meinst, dass sie den L3 so schön um den Core herum gesetzt haben, während AMD einfach eine Rechteckfläche für ihren L2 genommen hat?
Original geschrieben von BlackBirdSR
Naja und so langsam scheint der Cache auch nicht zu sein.
Intel gibt immerhin mit ca 64GB/s Gesamtbandbreite! bei 1GHz an.

Was ich aber gerne wüsste: Macht es den Alpha Leuten wirklich so viel Spass, statt am EV8 an diesem Monster zu arbeiten? Ob wir da die Tarantula Erweiterungen für den EV8, oder dessen SMT Funktionalität überhaupt jemals in IA64 CPUs sehen werden? Wem Brot isch ess, dem lied ich sing ;)


Original geschrieben von Smoking_Red
SAP, DB2 etc. pp. - Ich geb dir aber recht: Für den Heim-oder SoHo-Bereich ist das wirklich nix mehr...Reine DataCenter CPUs...:D Original geschrieben von Endorphine
Praktisch alle technisch-wissenschaftlichen Anwendungen sowie Datenbanken etc.?Alle? Also zumindest die numerischen Sachen, die ich von meinem Hiwi-Job kenne, fallen nicht in diese Kategorie. Sonst hätten wir dort längst Xeons statt normaler P4 ;)

Datenbanken sehe ich ein, klar :)
Original geschrieben von Endorphine
Die laufen häufig vollständig cachegrössenlimitiert.War mir bisher nicht wirklich bewußt...
Original geschrieben von Endorphine
Da gab's mal einen schönen Graphen in der iX. Speicherbandbreite (bzw. Latenz, je nach Anwendungsfall) hat in diesem Anwendungsfeld eine immense Bedeutung und limitiert sehr häufig. Hmm, würde mich interessieren. Könntest du das irgendwie raussuchen?

[GloomY]

Original geschrieben von Muh-sagt-die-Kuh
SMT ist bei IA-64 CPUs so eine Sache...


Predication hat prinzipiell eine ziemlich hohe interne Auslastung zur Folge
Das in-Order Desgign macht die Sache nicht gerade einfach bzw begrenzt sinnvoll
Anderernseits könnte man vielleicht einfach 128-bit Instruction Packages aus 2 Threads nehmen


Wäre sicherlich einfacher zu beurteilen, wenn ich die interne Auslastung kennen würde. SMT verbessert ja nicht nur den "vertical waste" (also die Auslastung) sondern auch den "horizontal waste" (k.A. wie man das übersetzen soll). Das heißt, dass man seltener einen Context Switch machen muss, weil mehrere Threads gleichzeitig aktiv sind. Und das spart Overhead, da nach jeder Zeitscheibe erstmal ein paar Takte der Scheduler des Betriebssystems die CPU nutzt, um festzulegen, welche(r) Thread(s) die nächste Zeitscheibe bekommen.

Da wir gerade beim Thema Zeitscheiben sind: SMT ist auch hier vorteilhaft. Die Wahl der Länge der Zeitscheibe ist nämlich eine verzwickte Sache. Lange Zeitscheiben führen zu wenig Context Switchen und sparen damit an Zeit, die die CPU mit dem OS Scheduler verbringt. Kurze Zeitscheiben hingegen veringern aber die "Verschwendung", wenn ein Thread schon nach einem Bruchteil der Dauer seiner zugeteilten Zeitscheibe nichts mehr zu tun hat und danch nur noch NOPs ausführt.
Wenn nun zwei (oder mehr) Threads bei SMT aktiv sind und der eine nichts mehr zu tun hat, dann beinhaltet dieser nur noch NOPs. Diese werden aber innerhalb der CPU vom Scheduler, der die Befehle auf die Pipelines verteilt, ignoriert. Damit werden praktisch nur noch Befehle des zweiten Threads in die Ausführungseinheiten geschickt, so dass dieser automatisch die volle Rechenpower der CPU bekommt. Insgesamt ergibt sich hier also ein Performancegewinn, da die CPU weniger Zeit mit Nichtstun verbringt. :)

Prinzipiell halte ich das In-Order Design mit SMT schon für recht sinnvoll. Bei einer CPU, die nur einen Thread unterstützt, muss diese bei einem Cache Miss die Pipeline solange komplett anhalten, bis die Daten aus dem Hauptspeicher verfügbar sind (was relativ lang dauert). Wenn die CPUs nun aber mehrere Threads unterstützt, dann muss die Pipeline nur für den einen Thread angehalten werden. Bei einem Cache Miss kann die CPU sich dann quasie einfach dem zweiten Thread zuwenden und den mit voller Geschwindigkeit weiter ausführen.
Auch hier bringt SMT insgesamt wieder einen Performancevorteil. =)

edit: Das ist quasie auch das Prinzip von SUNs Niagara Prozessor. Dieser ist seht einfach gebaut (wahrscheinlich auch in-order), dafür passen aber 8 physikalische CPUs auf das Die. Jeder dieser CPUs ist 4-fach SMT fähig. Cache haben die Prozessoren auch nicht viel.
Bei einem Cache Miss wendet sich die CPU einfach den restlichen drei Threads zu, um die Zeit sinnvoll zu nutzen. Man braucht hier quasie nur genügend Speicherbandbreite.

[BlackBirdSR]

Original geschrieben von GloomY
Du meinst, dass sie den L3 so schön um den Core herum gesetzt haben, während AMD einfach eine Rechteckfläche für ihren L2 genommen hat?


Das sagt zumindest Intel.
Da der Cache ja einen ganz großen Großteil ;) der Fläche einnimmt, macht es durchaus Sinn, den L3 Cache um den Core herum anzuordnen. Die Platzverschwendung wäre sonst ja immens.
Aber ich kann mir vorstellen, sowas kostet erheblichen Aufwand, besonders Zeit und Tests.

[Muh-sagt-die-Kuh]

Original geschrieben von GloomY
SMT verbessert ja nicht nur den "vertical waste" (also die Auslastung) sondern auch den "horizontal waste" (k.A. wie man das übersetzen soll). Das heißt, dass man seltener einen Context Switch machen muss, weil mehrere Threads gleichzeitig aktiv sind. Und das spart Overhead, da nach jeder Zeitscheibe erstmal ein paar Takte der Scheduler des Betriebssystems die CPU nutzt, um festzulegen, welche(r) Thread(s) die nächste Zeitscheibe bekommen.Jep.Da wir gerade beim Thema Zeitscheiben sind: SMT ist auch hier vorteilhaft. Die Wahl der Länge der Zeitscheibe ist nämlich eine verzwickte Sache. Lange Zeitscheiben führen zu wenig Context Switchen und sparen damit an Zeit, die die CPU mit dem OS Scheduler verbringt. Kurze Zeitscheiben hingegen veringern aber die "Verschwendung", wenn ein Thread schon nach einem Bruchteil der Dauer seiner zugeteilten Zeitscheibe nichts mehr zu tun hat und danch nur noch NOPs ausführt.
Wenn nun zwei (oder mehr) Threads bei SMT aktiv sind und der eine nichts mehr zu tun hat, dann beinhaltet dieser nur noch NOPs. Diese werden aber innerhalb der CPU vom Scheduler, der die Befehle auf die Pipelines verteilt, ignoriert. Damit werden praktisch nur noch Befehle des zweiten Threads in die Ausführungseinheiten geschickt, so dass dieser automatisch die volle Rechenpower der CPU bekommt. Insgesamt ergibt sich hier also ein Performancegewinn, da die CPU weniger Zeit mit Nichtstun verbringt. :)Tritt solch eine Situation bei einem heutigen OS überhaupt noch auf? Prinzipiell sollte doch ein Thread, der nichts mehr zu tun hat, am Ende einen Syscall absetzen der dann den Scheduler triggert.Prinzipiell halte ich das In-Order Design mit SMT schon für recht sinnvoll. Bei einer CPU, die nur einen Thread unterstützt, muss diese bei einem Cache Miss die Pipeline solange komplett anhalten, bis die Daten aus dem Hauptspeicher verfügbar sind (was relativ lang dauert). Wenn die CPUs nun aber mehrere Threads unterstützt, dann muss die Pipeline nur für den einen Thread angehalten werden. Bei einem Cache Miss kann die CPU sich dann quasie einfach dem zweiten Thread zuwenden und den mit voller Geschwindigkeit weiter ausführen.
Auch hier bringt SMT insgesamt wieder einen Performancevorteil. =)Volle Geschwindigkeit? Die Ausführungseinheiten die von dem Befehl, der den Cache-Miss verursacht hat und allen von ihm abhängigen benutzt werden blockieren doch immer noch einen Teil der Resourcen.
Muss bei IA-64 nicht auch ein 128 bit Befehlspaket immer synchron durch die Pipeline wandern? Das würde bedeuteten, dass ein Cache-Miss nicht nur einen, sondern bis zu 3 Befehle bzw Execution Units blockiert...
Prinzipiell ist SMT auch hier möglich, nur der Leistungsgewinn sollte lange nicht so hoch wie bei einem OOO-Design ohne Befehlsbündelung sein.
edit: Das ist quasie auch das Prinzip von SUNs Niagara Prozessor. Dieser ist seht einfach gebaut (wahrscheinlich auch in-order), dafür passen aber 8 physikalische CPUs auf das Die. Jeder dieser CPUs ist 4-fach SMT fähig. Cache haben die Prozessoren auch nicht viel.
Bei einem Cache Miss wendet sich die CPU einfach den restlichen drei Threads zu, um die Zeit sinnvoll zu nutzen. Man braucht hier quasie nur genügend Speicherbandbreite. Über diese CPUs gibt es noch zu wenig Informationen.....aber mal nebenbei....Sun hat doch sowieso nie ein OOO Design hinbekommen :D

[GloomY]

Oh, ich hätte deine Antwort beinahe übersehen... :|
Original geschrieben von Muh-sagt-die-Kuh
Tritt solch eine Situation bei einem heutigen OS überhaupt noch auf? Prinzipiell sollte doch ein Thread, der nichts mehr zu tun hat, am Ende einen Syscall absetzen der dann den Scheduler triggert.Tun sie das wirklich? Imho tun das nur Programme, die auch wirklich so dafür geschrieben sind. Imho gibt es dafür eine eigene Funktion der Windows-API, die aber logischerweise auch von dem Programm genutzt werden muss.
Vielleicht kann sich hier einer der vielen Profi-Progger ( :D ) aus dem Forum mal zu Wort melden... :)
Original geschrieben von Muh-sagt-die-Kuh

Volle Geschwindigkeit? Die Ausführungseinheiten die von dem Befehl, der den Cache-Miss verursacht hat und allen von ihm abhängigen benutzt werden blockieren doch immer noch einen Teil der Resourcen.Wenn du mehrere Threads hast, dann kannst du quasie den einen anhalten und den anderen weiter ausführen. Dafür mußt du nur die Zustände der einzelnen teilbearbeiteten Befehle des wartenden Threads zwischenspeichern und später wieder reaktivieren. Das kostet nur ein paar Bytes Speicherplatz auf dem Prozessor. Das wird bei 9 MB L3 Cache wohl hoffentlich drin sein, oder? ;)

Es wäre zumindest eine große Chance für IA64 die auftretenden Pipelinestalls deutlich zu verringern.
Original geschrieben von Muh-sagt-die-Kuh
Muss bei IA-64 nicht auch ein 128 bit Befehlspaket immer synchron durch die Pipeline wandern? Das würde bedeuteten, dass ein Cache-Miss nicht nur einen, sondern bis zu 3 Befehle bzw Execution Units blockiert...Nein, das mit den drei Befehlen hat nur damit zu tun wie diese als IA64 Code in den Speicher gepackt werden. Nach dem Fetchen und Dekodieren der Befehle hat das keinerlei Relevanz mehr.

btw: Imho gibt es ein (oder zwei? Naja, also sagen wir mindestens ein) Bit pro 3er-Befehlsbündel, welches die Parallelität mit dem nächsten 3er Bündel festlegt. Dadurch wird der Parallelität bei IA64 keine Grenzen gesetzt, weil man beliebig viele Bündel (und damit Befehle) als Parallel markieren kann.

(Auch dieses Bit ist übrigends ein Grund, warum eine Run-Time Compilierung von x86 zu IA64 schlecht ist. Dem x86 Code fehlen die Informationen über die Parallelität, IA64 braucht dies zwingend zum Ausführen von Code. Das meinte ich übrigends hier (http://www.forum-3dcenter.de/vbulletin/showthread.php?s=&postid=1489579#post1489579) u.a. auch mit den Informationen des Compilers für die CPU. )
Original geschrieben von Muh-sagt-die-Kuh
Prinzipiell ist SMT auch hier möglich, nur der Leistungsgewinn sollte lange nicht so hoch wie bei einem OOO-Design ohne Befehlsbündelung sein.Da bin ich mir mal nicht so sicher.

[GloomY]

Original geschrieben von Muh-sagt-die-Kuh
Über diese CPUs gibt es noch zu wenig Informationen.....Doch gibt es :D

http://www.aceshardware.com/read.jsp?id=55000245
http://www.aceshardware.com/read.jsp?id=55000247

Zwei sehr interessante Aussagen:
Dr. Marc Tremblay: Well the main idea is that while running large commercial programs we find the processors sometimes waiting 70% of the time, so being idle 70% of the time.

Chris Rijk [Ace's Hardware]: Stalled on waiting for data, basically.

Dr. Marc Tremblay: Yes. In large multiprocessor servers, waiting for data can easily take 500 cycles, especially in multi-GHz processors. So there are two strategies to be able to tolerate this latency or be able to do useful work. One of them is switching threads, so go to another thread and try to do useful work, and when that thread stalls and waits for memory then switch to another thread and so on. So that's kind of the traditional vertical multithreading approach.und dann speziell über Niagara:
Dr. Marc Tremblay: These processors, as you notice, are fairly simple so we're not talking about the deep very [aggressive] pipeline like Pentium 4. These chips, by the way, will waste like 28 cycles on misprediction. So here we're talking about a fairly shallow pipeline that doesn't suffer much from branches. So the focus is truly on hiding the much higher cost of cache misses that go to main memory. And there, you take an application like TPC-C or a large database app, and it's typical to see at least a 1% per instruction miss-rate. Meaning that once you normalize the instructions, you're saying that if you have 1 instruction every 100 that misses, and that one takes 300 cycles to service, and assuming all other instructions execute in one clock, so the first 99 take 99 clocks, and 100 takes 300 clocks. So, roughly the whole thing takes 400 clocks. Your IPC is 0.25, and your CPI is 4.

Chris Rijk [Ace's Hardware]: I was hoping that you could actually give us some examples of current stuff at least so that we can have a way to [see] where things are currently having problems. So if you at like that 25% efficiency value, if you raise that to 75%-80%, the performance will naturally go up a lot. One of the things I want to try and be able to explain to our readers is effectively from basics is why the current methodology isn't the best way to go about things.

Dr. Marc Tremblay: Well, the example I gave you is not far-fetched. So that should give you an example and then say 'wow, that processor is idle a lot', in this particular case 75% of the time. So then you start sizing how many threads [you] need to cover that latency, and then notice that if you do this with multiple threads and multiple cores, you also end up with this constructive sharing. Each thread has a pretty small cache, the miss-rate might actually go up, but that's ok.

Chris Rijk [Ace's Hardware]: As long as you have enough memory bandwidth.

Dr. Marc Tremblay: That's right, so we turn a latency problem into a bandwidth problem. And as you guys know, trying to cut the latency of DRAM in half or by 75% is basically impossible, but providing a lot of bandwidth is a lot easier.
Original geschrieben von Muh-sagt-die-Kuh
aber mal nebenbei....Sun hat doch sowieso nie ein OOO Design hinbekommen :DVielleicht haben sie es auch nie ernsthaft versucht? ;)

[zeckensack]

Original geschrieben von GloomY
Tun sie das wirklich? Imho tun das nur Programme, die auch wirklich so dafür geschrieben sind. Imho gibt es dafür eine eigene Funktion der Windows-API, die aber logischerweise auch von dem Programm genutzt werden muss.
Vielleicht kann sich hier einer der vielen Profi-Progger ( :D ) aus dem Forum mal zu Wort melden... :)Das tun sie wirklich ;)
Es gibt selbst für mit der heissen Nadel gestrickte Software drei naheliegende Möglichkeiten, den Task-Scheduler seine Arbeit verrichten zu lassen:
1)Sleep(0)
Sleep dient eigentlich dazu, eine gewisse Zeit zu warten. Während dieser Wartezeit führt das OS natürlich andere Threads aus. Sleep(0) ist ein kleiner Spezialfall, und beendet die aktuelle Timeslice.

2)GetMessage
Win32-GUI-Programme sollen rein auf Event-Handling basieren, also nur auf User-Aktionen reagieren. GetMessage holt diese Aktionen, kodiert in "Messages". Sind keine Messages für das zum abfragenden Prozess gehörende Fenster verfügbar, wird der Thread vom OS schlafen gelegt.

3)WaitForMultipleObjects bzw WaitForSingleObject
Damit kann man Synchronisations-Objekte (Timer, Mutex, etc, aber auch Threads) 'abhören', um zB auf das Ende eines mutex blocks zu warten. Auch hier kann wieder der Scheduler in Aktion treten.

[Muh-sagt-die-Kuh]

Original geschrieben von GloomY
Wenn du mehrere Threads hast, dann kannst du quasie den einen anhalten und den anderen weiter ausführen. Dafür mußt du nur die Zustände der einzelnen teilbearbeiteten Befehle des wartenden Threads zwischenspeichern und später wieder reaktivieren. Das kostet nur ein paar Bytes Speicherplatz auf dem Prozessor. Das wird bei 9 MB L3 Cache wohl hoffentlich drin sein, oder? ;)

Es wäre zumindest eine große Chance für IA64 die auftretenden Pipelinestalls deutlich zu verringern.Moeglich ist das sicherlich, man muss nur eben alle genutzten temporaeren Register sowie die den Zustand der Pipelinesteuerung sichern und wiederherstellen koennen...das waere dann aber im Prinzip nichts anderes als ein hardwareunterstuetzter Kontext-Switch wie von Sun fuer die neuen CPUs vorgesehen. Ob das bei einem heutigen IA-64 etwas bringen wuerde halte ich fuer fraglich.
Nein, das mit den drei Befehlen hat nur damit zu tun wie diese als IA64 Code in den Speicher gepackt werden. Nach dem Fetchen und Dekodieren der Befehle hat das keinerlei Relevanz mehr.3 Befehle bilden doch ein Paket weil sie eben parallel ausgefuehrt werden koennen, oder?

Hast du eine Quelle dafuer? Das wuerde ich gerne nochmal nachlesen...was du hier schreibst hoert sich schon fast nach OOOE an ;)btw: Imho gibt es ein (oder zwei? Naja, also sagen wir mindestens ein) Bit pro 3er-Befehlsbündel, welches die Parallelität mit dem nächsten 3er Bündel festlegt. Dadurch wird der Parallelität bei IA64 keine Grenzen gesetzt, weil man beliebig viele Bündel (und damit Befehle) als Parallel markieren kann.
(Auch dieses Bit ist übrigends ein Grund, warum eine Run-Time Compilierung von x86 zu IA64 schlecht ist. Dem x86 Code fehlen die Informationen über die Parallelität, IA64 braucht dies zwingend zum Ausführen von Code. Das meinte ich übrigends hier (http://www.forum-3dcenter.de/vbulletin/showthread.php?s=&postid=1489579#post1489579) u.a. auch mit den Informationen des Compilers für die CPU. )Richtig, ansonsten wuerde es keinen Sinn machen, dass der I2 zwei 128-bit Pakete pro Takt annehmen kann.

Man kann dem x86 Code doch Parallelitaetsinfomation entnehmen, genau das machen doch aktuelle x86 CPUs ;)

[Muh-sagt-die-Kuh]

Original geschrieben von GloomY
Doch gibt es :D

http://www.aceshardware.com/read.jsp?id=55000245
http://www.aceshardware.com/read.jsp?id=55000247

Zwei sehr interessante Aussagen:
und dann speziell über Niagara:

Vielleicht haben sie es auch nie ernsthaft versucht? ;) Das sind konzeptuelle Informationen...und auch die einzigen, die ich kenn ;)

War wohl ein kleines Missverstaendnis, der Kommentar mit den "kaum Informationen" bezog sich eher auf die konkrete Implementation dieser Chips, was das angeht ist der Sun-Mensch nicht besonders auskunftsfreudig gewesen ;)

[GloomY]

Original geschrieben von Muh-sagt-die-Kuh
Moeglich ist das sicherlich, man muss nur eben alle genutzten temporaeren Register sowie die den Zustand der Pipelinesteuerung sichern und wiederherstellen koennen...das waere dann aber im Prinzip nichts anderes als ein hardwareunterstuetzter Kontext-Switch wie von Sun fuer die neuen CPUs vorgesehen. Ob das bei einem heutigen IA-64 etwas bringen wuerde halte ich fuer fraglich.Es ist etwas anderes, da wirklich gleichzeitige Ausführung von Threads möglich wäre. Bei einem Cache Miss, ist der Prozessor sonst komplett untätig, bis die Daten da sind. Hier kann er den anderen Thread weiterrechnen lassen und die Zeit sinnvoll nutzen.
Original geschrieben von Muh-sagt-die-Kuh
3 Befehle bilden doch ein Paket weil sie eben parallel ausgefuehrt werden koennen, oder?Ja, wenn sich drei Befehle in einem Paket befinden, dann können diese sicher auch parallel ausgeführt werden. Die Parallelität ist aber nicht zwangsläufig auf drei Befehle beschränkt, nur weil nunmal drei Befehle in ein 128 Bit Paket reinpassen.

Ich mach's mal ganz ausführlich und fange ganz vorne an: :)
Befehle werden nicht einzeln gespeichert, sondern in Dreierbündeln, welche die feste Länge 128 bit haben. Man kann prinzipiell auch nur einen oder zwei Befehle in ein Bündel reinpacken, dazu später mehr. Befehle, die in einem Bündel drin sind, können parallel zueinander ausgeführt werden. Wenn man also drei Befehle hat, die parallel zueinander ausgeführt werden können, dann kann man diese in ein Dreierbündel reinpacken (gibt ein paar Beschränkungen, aber dazu gleich mehr). Wenn man drei Befehle hat, die nicht parallel zueinander ausgeführt werden können, dann müssen diese in drei verschiedene Bündel, und die jeweils restlichen 2 Befehle in den Dreierbündeln werden mit NOPs aufgefüllt.

Weiterhin ist es möglich, mehr als drei Befehle parallel auszuführen. Dazu muss man durch das Setzen eines speziellen Bits im Bündel signalisieren, dass dieses parallel mit dem nachfolgenden Bündel ausgeführt werden kann, d.h. die Befehle des ersten Bündels plus die Befehle, die sich im zweiten Bündel befinden. Das zweite Bündel kann dann wiederrum das Bit für das nächstfolgende Bündel gesetzt haben usw., so daß man durch dieses Schema beliebig viele Befehle als parallel markieren kann.

Die Befehle sind in mehrere Gruppen eingeteilt (Int, FP, Mem, Branch; wenn ich mich richtig erinnere). Leider darf man nicht jede Kombination von Befehlsgruppen in ein Dreierbündel reinpacken. So weit ich mich richtig erinnere, darf z.B. nur ein FP Befehl pro Dreierbündel rein. Wenn man also zwei FP Befehle hat, dann muss man diese in zwei verschiedene Bündel packen und wenn's dumm läuft den Rest mit NOPs auffüllen, wenn keine anderen Befehle parallel dazu ausgeführt werden können.
Es gibt noch ein paar andere Beschränkungen von Kombinationen, die nicht erlaubt sind; hab' ich aber in der Zwischenzeit wieder vergessen. Wenn du willst, kann ich das mal nachgucken.
Original geschrieben von Muh-sagt-die-Kuh
Hast du eine Quelle dafuer? Das wuerde ich gerne nochmal nachlesen...was du hier schreibst hoert sich schon fast nach OOOE an ;)Alles aus dem Kopf. Der Ursprung ist aber der Know-How Artikel in der C't über den Itanium (Imho die beste C't Ausgabe der letzten Jahre). Ich hab' das Heft leider nicht hier sondern bei meinen Eltern rumliegen, daher kann ich es momentan nicht verifizieren. Zu dem was ich aber hier (oben) geschrieben habe, kann ich aber mit Sicherheit sagen, dass dies wahr ist.

Meine Aussage, dass die Befehlsbündelung zu Dreierpaketen nach dem Decoden keine Auswirkung mehr hat, ist so zu verstehen, dass die Parallelität, die mit Hilfe der Bündel festgelegt wurden, natürlich weiterhin gilt, jedoch die Tatsache, dass es nunmal Dreierbündel (und nicht z.B. 5er, 6er Bündel oder einzelne Befehle) sind nur mit dem Reinpacken in den Speicher zu tun hat. Ein Befehle hat beim Itanium mit allem zusammen 41 Bit und das läßt sich alleine nunmal sehr schlecht im Speicher unterbringen. ;)
Original geschrieben von Muh-sagt-die-Kuh
Richtig, ansonsten wuerde es keinen Sinn machen, dass der I2 zwei 128-bit Pakete pro Takt annehmen kann.Diese Beschränkung auf 2 Bündel war mir nicht präsent. Liegt das an den Decodern oder wieso nur 2 Bündel?
Original geschrieben von Muh-sagt-die-Kuh
Man kann dem x86 Code doch Parallelitaetsinfomation entnehmen, genau das machen doch aktuelle x86 CPUs ;) Sicher kann man das, aber x86 CPUs haben dafür Hardware und der Itanium nicht, da er davon ausgeht, dass das der Compiler für ihn erledigt. Die Emulationsschicht muss also per Software die Parallelität des Codes ausfindig machen, was natürlich die Performance senkt.

Der Itanium hat einfach viel höhere Anforderungen an den Code. Er will ihn quasie perfekt zubereitet serviert bekommen, so dass er ihn nur noch durch die Ausführungseinheiten schieben muß. Inklusiv Informationen über Parallelität, Predication und spekulativer Loads. X86 macht das größtenteils selbst in Hardware. Ist doch klar, dass der Itanium sich dann allein gelassen fühlt :D

[Coda]

Zur Cache Anordnung:

http://cpus.hp.com/technical_references/isscc_2002/fig.25.5.6.jpg

[GloomY]

Original geschrieben von zeckensack
Das tun sie wirklich ;)
Es gibt selbst für mit der heissen Nadel gestrickte Software drei naheliegende Möglichkeiten, den Task-Scheduler seine Arbeit verrichten zu lassen:
1)Sleep(0)
Sleep dient eigentlich dazu, eine gewisse Zeit zu warten. Während dieser Wartezeit führt das OS natürlich andere Threads aus. Sleep(0) ist ein kleiner Spezialfall, und beendet die aktuelle Timeslice.

2)GetMessage
Win32-GUI-Programme sollen rein auf Event-Handling basieren, also nur auf User-Aktionen reagieren. GetMessage holt diese Aktionen, kodiert in "Messages". Sind keine Messages für das zum abfragenden Prozess gehörende Fenster verfügbar, wird der Thread vom OS schlafen gelegt.

3)WaitForMultipleObjects bzw WaitForSingleObject
Damit kann man Synchronisations-Objekte (Timer, Mutex, etc, aber auch Threads) 'abhören', um zB auf das Ende eines mutex blocks zu warten. Auch hier kann wieder der Scheduler in Aktion treten. Danke :)

Gut, dann ist bei mir aber immer noch die Frage, ob das Betriebssystem die Zeitscheibe für einen einzelnen Thread beenden kann oder nur für beide? Wie sieht das bei wirklich gleichzeitiger Ausführung bei SMT aus? :???:

Naja, selbst wenn das nichts bringen würde, bliebe immer noch der Vorteil des selteneren context Switching (weniger "Vertical Waste") und der (noch) besseren Auslastung (weniger "horizontal Waste") :)

[Demirug]

Original geschrieben von GloomY
Danke :)

Gut, dann ist bei mir aber immer noch die Frage, ob das Betriebssystem die Zeitscheibe für einen einzelnen Thread beenden kann oder nur für beide? Wie sieht das bei wirklich gleichzeitiger Ausführung bei SMT aus? :???:

Natürlich kann jeder Thread einzeln unterbrochen werden. Es hat ja auch jeder einen eigenen Instruktion Pointer.

[Muh-sagt-die-Kuh]

Original geschrieben von GloomY
Es ist etwas anderes, da wirklich gleichzeitige Ausführung von Threads möglich wäre. Bei einem Cache Miss, ist der Prozessor sonst komplett untätig, bis die Daten da sind. Hier kann er den anderen Thread weiterrechnen lassen und die Zeit sinnvoll nutzen.Du meinst damit also praktisch SMT bei dem die Anzahl der Registersätze größer ist als die Anzahl an Threads in Bearbeitung?Es gibt noch ein paar andere Beschränkungen von Kombinationen, die nicht erlaubt sind; hab' ich aber in der Zwischenzeit wieder vergessen. Wenn du willst, kann ich das mal nachgucken.
Alles aus dem Kopf. Der Ursprung ist aber der Know-How Artikel in der C't über den Itanium (Imho die beste C't Ausgabe der letzten Jahre). Ich hab' das Heft leider nicht hier sondern bei meinen Eltern rumliegen, daher kann ich es momentan nicht verifizieren. Zu dem was ich aber hier (oben) geschrieben habe, kann ich aber mit Sicherheit sagen, dass dies wahr ist.Nee, musst nicht nachschauen, ich hab alle c´t Artikel seit 1998 auf CD rumfliegen....hmmm du bringst mich gerade auf eine Idee, ich könnte mir die eigentlich mal auf einer DVD zusammenstellen :DMeine Aussage, dass die Befehlsbündelung zu Dreierpaketen nach dem Decoden keine Auswirkung mehr hat, ist so zu verstehen, dass die Parallelität, die mit Hilfe der Bündel festgelegt wurden, natürlich weiterhin gilt, jedoch die Tatsache, dass es nunmal Dreierbündel (und nicht z.B. 5er, 6er Bündel oder einzelne Befehle) sind nur mit dem Reinpacken in den Speicher zu tun hat. Ein Befehle hat beim Itanium mit allem zusammen 41 Bit und das läßt sich alleine nunmal sehr schlecht im Speicher unterbringen. ;)Jep, allerdings ist der Itanium eben ein reines In-Order Design...die Bündel können nach der Dekodierung nicht mehr umsortiert werden.Diese Beschränkung auf 2 Bündel war mir nicht präsent. Liegt das an den Decodern oder wieso nur 2 Bündel?Quelle ist auch hier die c´t, genauer Ausgabe 20/03 oder 13/02. Der Grund scheint einfach ein 256 bit breiter Bus zwischen I-Cache und Decoder zu sein.Sicher kann man das, aber x86 CPUs haben dafür Hardware und der Itanium nicht, da er davon ausgeht, dass das der Compiler für ihn erledigt. Die Emulationsschicht muss also per Software die Parallelität des Codes ausfindig machen, was natürlich die Performance senkt.

Der Itanium hat einfach viel höhere Anforderungen an den Code. Er will ihn quasie perfekt zubereitet serviert bekommen, so dass er ihn nur noch durch die Ausführungseinheiten schieben muß. Inklusiv Informationen über Parallelität, Predication und spekulativer Loads. X86 macht das größtenteils selbst in Hardware. Ist doch klar, dass der Itanium sich dann allein gelassen fühlt :D Hehe :D
Die Emulationsschicht des Itanium 2 ist deshalb auch immer noch Schrott, die Softwarelösung in Form des IA-32 Execution Layer arbeitet deutlich besser.