Parallelrechner (war: 2006: 10 neue Itanium-CPUs - meist DC)

[Stone2001]

So optimal nicht. Wenn von 11 Teraflops nur 1 Terraflop genutzt werden, dann haben die entweder GCC eingesetzt, oder der Intel/HP-Compiler arbeitet noch nicht richtig optimal.

hmm, ich finde so eine Ausbeute schon recht ordentlich für einen Cluster. Das der Rechner auch seine 7-8 Teraflop im Linpack haben wird ist klar, aber bei echten Anwenungen liegt jeder Rechner weit davon entfernt.

Selbst der Vektorrechner in Stuttgart kommt mit seinen 12 Teraflops unter dem Strich auf nur 3-4 Teraflop wirkliche Leistung, was ein sehr guter Wert ist.
Ich bin mal gespannt, was man von dem neuen Rechner im Leibniz-Rechenzentrum erfährt. 66 Teraflop sind geplant, abwarten ob sie sagen, was unter dem Strich dabei rauskommt.

[Stone2001]

Ein Opteron-Cluster mit Infiniband direkt am Hypertransport ist trotzdem um einige effektiver und kostengünstiger ;)
Ein wirkliches Schmuckstück an Superrechner ist ein Cray XD1. ;)
2 ms MPI-Latenz durch Cray RapidArray-Interconnect! Die Interconnects sind direkt an einen Hypertransportchannel angebunden und über eine Backplane verbunden. Da kommt Freude auf. ;)
Leider nicht mehr ganz billig. 12 DualCore Opterons und 6 Virtex II Pro FPGAs in einem Chassis kosten ca. 100 000€ ;)

[GloomY]

Ja schon, aber für den Preis lassen sich ja auch bestimmt 3-4 Opterons kaufen, oder nicht?Ja, das wahrscheinlich schon. Aber sind 1000 Itaniums nicht vielleicht trotzdem schneller als 3000-4000 Opterons? (Amdahl's Law)
So optimal nicht. Wenn von 11 Teraflops nur 1 Terraflop genutzt werden, dann haben die entweder GCC eingesetzt, oder der Intel/HP-Compiler arbeitet noch nicht richtig optimal.

@Coda
Hätte es nicht besser ausgedrückt :up:
Aber sind die beim Optimieren noch nicht weiter? :conf2:Die 11 TFlop/s sind doch das theoretische Maximum. Wenn man wirklich mit Real-World-Anwendungen bencht und keine synthetischen Tests nimmt, ist es immer schwierig, an das theoretische Maximum heranzukommen.
[...] Wie Coda schon angab: Infiniband am Hypertransport gegenüber den Infiniband und Gigabit Ethernet Verbindungen bei Columbia.
In Sachen Leistung pro Takt besteht natürlich kein Zweifel.Gigabit Ethernet ist wohl eine der schlechtesten (einigermaßen aktuellen) Verbindungsnetzwerke für einen Parallelrechner. ;)

Trotzdem wird es verwendet, weil die Anforderungen oftmals ziemlich unterschiedlich sind. Einige parallele Algorithmen sind CPU-limitiert, andere hingegen durch den Interconnect (speziell: die Latenz) limitiert. Je nachdem, was man mit seinem Parallelrechner ausrechnet, ist eben mal das eine und mal das andere wesentlich wichtiger.
Insofern ist die Top500 Liste eigentlich auch nur was für die Leute aus der Verkaufsabteilung, aber keine technische Referenz...

[Coda]

Ja, das wahrscheinlich schon. Aber sind 1000 Itaniums nicht vielleicht trotzdem schneller als 3000-4000 Opterons? (Amdahl's Law)Vielleicht. Kommt wohl auch auf die Aufgabe an.
Ich gebe zu das Statement war etwas undifferenziert.

Gigabit Ethernet ist wohl eine der schlechtesten (einigermaßen aktuellen) Verbindungsnetzwerke für einen Parallelrechner.Und Hypertransport mit Infiniband ist wohl ungeschlagen. HT wurde ja extrem kurze Latenzen ausgelegt, weil man das auch bei den CPU-Verbindungen braucht. Alles was über PCI-X o.ä. geht ist weitaus schlechter, von PCIe will ich garnicht reden, das ist besonders übel.

[Coda]

Ah, hab's gefunden: http://www.hypertransport.org/tech/tech_latency.cfm

[kelo]

Ja, das wahrscheinlich schon. Aber sind 1000 Itaniums nicht vielleicht trotzdem schneller als 3000-4000 Opterons? (Amdahl's Law)
Anwendungsabhängig
Die 11 TFlop/s sind doch das theoretische Maximum. Wenn man wirklich mit Real-World-Anwendungen bencht und keine synthetischen Tests nimmt, ist es immer schwierig, an das theoretische Maximum heranzukommen.
Aber weniger als 10% der theoretischen Maximalleistung sind etwas zu wenig. Normalerweise sollten es um die 30-50% sein.
Selbst die Intel und HP Compiler sind trotz des besseren Codes gegenüber den GCC immer noch nicht optimal, vor allem beim Cluster-Betrieb.
Gigabit Ethernet ist wohl eine der schlechtesten (einigermaßen aktuellen) Verbindungsnetzwerke für einen Parallelrechner. ;)

Trotzdem wird es verwendet, weil die Anforderungen oftmals ziemlich unterschiedlich sind. Einige parallele Algorithmen sind CPU-limitiert, andere hingegen durch den Interconnect (speziell: die Latenz) limitiert. Je nachdem, was man mit seinem Parallelrechner ausrechnet, ist eben mal das eine und mal das andere wesentlich wichtiger.
Insofern ist die Top500 Liste eigentlich auch nur was für die Leute aus der Verkaufsabteilung, aber keine technische Referenz...
Dass hängt auch von der Anwendung ab, wie weit er auf Bandbreite aus ist.
Dann noch vom Compiler, speziell im Clusterbetrieb.
Ich weiß ;)

Aber ich verstehe nicht, warum Intel dem Itanium keinen On-Die-Memory-Controler verpasst.
Der sollte doch kommen !? Aber zuerst im Desktop (>P-M), dann ab 2007 (?)

[Coda]

Ich versteh den Zusammenhang nicht, warum ein Compiler im "Clusterbetrieb" schlechteren Code ausspucken sollte :|

[Stone2001]

Aber weniger als 10% der theoretischen Maximalleistung sind etwas zu wenig. Normalerweise sollten es um die 30-50% sein.
Sorry, aber 30-50% ist für einen Clustser absolut unrealistisch. Der Leiter unseres Rechenzentrums würde es freuen, wenn er durch die Bank weg 30% der Maximalleistung seines Clusters hätte.
Nenn mir mal eine Software zur Strömungssimulation, sowie den dazugehörigen Cluster, mit der du mehr als 50% der Maximalleistung herausbekommst, ich werde dann diese Kombination sofort an den Leiter unseres Rechenzentrums weiterleiten. ;)

Selbst die Intel und HP Compiler sind trotz des besseren Codes gegenüber den GCC immer noch nicht optimal, vor allem beim Cluster-Betrieb.

Naja, der Itanium ist nicht gerade das, was man unter dem Tisch stehen hat, oder?

Dass hängt auch von der Anwendung ab, wie weit er auf Bandbreite aus ist.
Dann noch vom Compiler, speziell im Clusterbetrieb.

Naja, Ethernet verwendet man doch nur, wenn man zu wenig Kohle für ein ordentliches Verbindungsnetzwerk hat, oder? ;) Vorallem wenn ich mir die Latenzzeiten von Gigabitethernet anschaue ... .
Man muß sich halt überlegen, ob man mit weniger Prozessoren und einem besseren Verbindungsnetzwerk nicht die gleiche Leistung, wie mit Gigabit Ethernet und mehreren Prozessoren erreicht. Bevor ich mir so ein System zulege: http://www.top500.org/sublist/System.php?id=7137, dann schon etwas in dieser Richtung: http://www.top500.org/sublist/System.php?id=7595 (wobei ich mal ausgehe, das die XT3 trotzdem teuer ist).

BTW: Mit diesem Thema driften wir vom eigentlichen Thema ab, oder? ;)

[GloomY]

Aber weniger als 10% der theoretischen Maximalleistung sind etwas zu wenig. Normalerweise sollten es um die 30-50% sein.
Selbst die Intel und HP Compiler sind trotz des besseren Codes gegenüber den GCC immer noch nicht optimal, vor allem beim Cluster-Betrieb.Das liegt doch aber nicht am Compiler. Wenn in einem Cluster ein Knoten auf Daten vom einem anderen wartet, dann kann der Compiler da gar nichts für. Das ist einfach die Latenz des Verbindungsnetzwerks, welche hier die CPU warten lässt und damit die Performance reduziert.
Durch den Austausch des Compilers kannst du da nicht viel ändern. Man könnte sich höchstens überlegen, ob man nicht einen anderen Algorithmus für das Problem findet, welcher die Wartezeiten für die einzelnen Knoten reduziert.

Und ob 30-50% des Peaks "normal" sind, bezweifel ich mal. Auch hier kommt es sehr stark auf die Anwendung an. Kann man die Kommunikation zwischen den Knoten reduzieren oder die Latenz dieser Operationen hinter gleichzeitig stattfindender Arithmetik verstecken, so kann man sicher auch mal 50% vom Peak erreichen. Bloß hängt das eben sehr stark von der Anwendung ab.
Dass hängt auch von der Anwendung ab, wie weit er auf Bandbreite aus ist.Bandbreite ist meist nicht das Problem. Die Latenz ist hier oftmals sehr viel mehr ausschlaggebend.
Naja, Ethernet verwendet man doch nur, wenn man zu wenig Kohle für ein ordentliches Verbindungsnetzwerk hat, oder? ;) Vorallem wenn ich mir die Latenzzeiten von Gigabitethernet anschaue...Ja, die sind imho nicht viel besser als 100BaseTX.
Man muß sich halt überlegen, ob man mit weniger Prozessoren und einem besseren Verbindungsnetzwerk nicht die gleiche Leistung, wie mit Gigabit Ethernet und mehreren Prozessoren erreicht.Absolut richtig.
Bevor ich mir so ein System zulege: http://www.top500.org/sublist/System.php?id=7137, dann schon etwas in dieser Richtung: http://www.top500.org/sublist/System.php?id=7595 (wobei ich mal ausgehe, das die XT3 trotzdem teuer ist).Hrhr. Der Xeon-Cluster mit seinen 3200 Prozessoren ist beim Linpack-Benchmark langsamer als der Opteron-Cluster mit nur 1100 Prozessoren. :D
Und das, obwohl Linpack imho noch nicht mal so große Anforderungen an die Latenz des Verbindungsnetzwerks stellt.

[Stone2001]

Ja, die sind imho nicht viel besser als 100BaseTX.

Doch schon etwas. ;) Ich hab hier leider keine unabhängigen Quellen, aber 100BaseTX hat eine MPI-Latenz so um 120 ms, Gigabit so um die 50-70ms.
Mal schaun, ob ich ein paar unabhängige Tests finde. Auch ist die MPI-Latenz von der Implementierung abhängig.

Hrhr. Der Xeon-Cluster mit seinen 3200 Prozessoren ist beim Linpack-Benchmark langsamer als der Opteron-Cluster mit nur 1100 Prozessoren. :D
Und das, obwohl Linpack imho noch nicht mal so große Anforderungen an die Latenz des Verbindungsnetzwerks stellt.
Ok, ich muß zugeben, das Xeon-Cluster ist ein schlechtes Beispiel, aber man kann z.b. diesen Cluster nehmen http://www.top500.org/sublist/System.php?id=7535 da kommt Gigabit Ethernet etwas besser weg, aber wirklich gut ist es trotzdem nicht.
Anmerken sollte man noch, das Linpack sehr flexibel ist. Das Problem und die Lösungsmethode ist vorgeben, aber die Problemgröße ist frei wählbar, da gibt es also viel Spielraum beim optimieren. ;)