T2000 Enterprise vs. Sun Fire 280R

[Kaurik]

Hallo allerseits,

wie in vergangener Zeit mal erwähnt sitze ich bei einem neuen Arbeitgeber u.a. an ein paar T2000 Servern.

Das brachte aber auch ein paar interessante Probleme mit sich: performance. Wie ist es möglich, dass cgi Skripte (perl, single-threaded) auf einem 1Ghz Core einer T2000 maximal halb so schnell sind wie auf einer (750Mhz) Cpu einer Sun Fire 280r?

Es ist klar, dass man von der multicore Architektur nur Gebrauch machen kann, indem man sie eben auch benutzt (deswegen gibt es bei uns auch diverse Code-Umstellungen) und auch nur dann einen Vorteil davon hat, aber dass die Perfomance im quasi rohen Betrieb so divergiert, wundert mich doch schon sehr.

Hat jemand Erfahrung mit den neuen Kisten?
Ich kann auch einen zehn Zeiler (Perl) zur Verfügung stellen, den wir als groben Performance-Test verwenden - Vergleichtswerte würden mich sehr interessieren.

Claus

[CrystalPalace]

Wir betreiben momentan 4 T2000 und eine T5220 für Anwendungsentwicklung & -test parallel zu anderen Sparc Servern.
Ursprünglich sollten die T2000 bei uns die alten V240 als compile-server ablösen. Das haben wir aber relativ schnell wieder eingestellt da die performance unter aller kanone ist. Selbst eine V240 mit 2x1ghz war deutlich schneller als die T2000.
Wobei dieses Phänomen eigentlich schon im Vorfeld bekannt war 
Ich glaube irgendwo in den processor manuals gelesen zu haben, das die T1 cpu auf dem UltraSparc 2 Kern basiert, kann mich aber nicht mehr wirklich daran erinnern.
Das große Problem an der Kiste ist jedoch die single FPU für alle cores, die bei alten Anwendungen einfach nur die Kerne ausbremst. Und die Maschinen reagieren recht allergisch auf code, der nicht für die T1/T2 kompiliert wurde.

Die T5220 ist zwar spürbar schneller aber auch net wirklich so der große Renner, wenn die Applikationen einfach nicht auf Parallelität ausgelegt sind.
Endeffekt momentan ist, das wir zum Compilen und Entwickeln die V240/V440er nehmen, und nur die rechenintensiven Teile der Applikation auf die T5220 auslagern. Dort verkraftet die T5220 dann doch ein paar user mehr als die bisher dafür genutzte V440.

Mit den T2000 haben wir nun erst mal diverse alte Fileserver ersetzt (E450, E3000,etc). Dadurch konnten wir doch ein paar KW Strom und Hitze einsparen, da unsere Klimaanlage und die USV ziemlich ausgelastet sind.
Wir haben die T2000 und T5220 auch mal kurzzeitig als Sunray server getestet, wobei die performance dort auch deutlich schlechter war als mit einer - ich glaube - X4200.
Auf alle Fälle ist die x86er möhre nun unser Sunray Server. Aber das ist eine andere leidvolle Geschichte 

Fazit: Die Kisten mögen beide ihre Anwendungsbereiche haben, wenn man viele Tätigkeiten parallel erledigen kann. Da dies bei uns aber leider (noch) nicht wirklich der Fall ist, ist der Nutzen nich ganz so groß. Größter Vorteil ist der deutlich geringere Strom- & Platzverbrauch verglichen mit den alten Eisen.

Christian

[stiefkind]

'N Abend zusammen!

Das brachte aber auch ein paar interessante Probleme mit sich: performance. Wie ist es möglich, dass cgi Skripte (perl, single-threaded) auf einem 1Ghz Core einer T2000 maximal halb so schnell sind wie auf einer (750Mhz) Cpu einer Sun Fire 280r?

Ich musste gerade eine Weile nach der passenden Stelle suchen, wurde dann aber doch noch fündig:

The performance of a single thread on a system with UltraSPARC T1 processors is less than that of a single threaded processor. This is because the strands do not have exclusive access to the resources of the core and the pipeline is simpler. Although individual strands are weaker, aggregate performance is greater than in the previous generation of SPARC processors.

Quelle: http://www.sun.com/blueprints/1205/819-5144.pdf
Unter "strand" versteht Sun hier die physikalische Implementierung eines Threads als ein Satz Register nebst Beiwerk auf der CPU.

Ähnlich wie Christian meine auch ich, was im Hinterkopf zu haben, dass die einzelnen Cores einer T1 CPU auf einer älteren UltraSPARC-Cores basiert. Allerdings meine ich, dass das eine UltraSPARC III CPU ist, die da als Ausgangsmaterial diente. Kann mich aber täuschen. So oder so wurde die CPU soweit ich mich erinnere "erleichtert" um ein paar "überflüssige" Funktionen, um die Floating Point Unit und die Integer-Pipeline wurde verkürzt. In einem Taktzyklus können also weniger Maschinenbefehle parallel verarbeitet werden, als das bei einer richtigen UltraSPARC II, III oder IV der Fall ist. Dass die FPU nur einmal je Chip (also shared für alle 8 Cores) existiert, hat Christian ja auch schon geschrieben.

Man merkt das auch ganz schnell, wenn man auf einer UltraSPARC T1 Maschine (also T1000/T2000) einen Patchcluster einfährt. patchadd ist ein astreines Single-Thread Binary.

Lt. Aussage von Sun ist eine UltraSPARC T2 da weniger bis gar nicht mehr empfindlich und sehr wohl als General Purpose CPU geeignet. Meine Erfahrung deckt sich noch nicht so ganz mit dieser Aussage...


wolfgang

[escimo]

Ursprünglich sollten die T2000 bei uns die alten V240 als compile-server ablösen. Das haben wir aber relativ schnell wieder eingestellt da die performance unter aller kanone ist. Selbst eine V240 mit 2x1ghz war deutlich schneller als die T2000.
...
Und die Maschinen reagieren recht allergisch auf code, der nicht für die T1/T2 kompiliert wurde.
...

Damit hast du dir das "warum" selbst beantwortet.

Compiler sind - soweit mir bekannt - Sammlungen von single-thread Programmen (Scanner, Parser, Preprocessor, Zwischenübersetzer, Assembler, Linker usw.). Damit ist natürlich nicht die Möglichkeit für verteilte Übersetzungsläufe (z.B. mittels distributed make) gemeint. Hier könnte man auf einem CT-System mittels Container+Zones mehrerer virtuelle Übersetzungs-Server erstellen und dann mit dmake arbeiten. Oder bringt das auch nichts?

In wieweit die FPU allgemein beim Übersetzungslauf auf einem Core beansprucht wird, ist mir leider noch nicht bekannt.

Gruß
escimo

[CrystalPalace]

Ich weiß wieso das lahm ist, nur wollte mir das ganze im Vorfeld keiner glauben, da ich ja nur als Entwickler arbeite und net als Administrator  oder HW Manager
Desweiteren gab unser Sun "Consultant" dasselbe statement wie die Admins ab...das Ergebnis haben wir jetzt.
Diesselbe story lief ähnlich bei der T5220 ab.

Naja, zones und container setzen wir momentan aus verschiedenen organisatorischen Gründen net ein. Aber grundsätzlich könnte ich mir schon vorstellen das man dadurch zumindest einen Teil des compilens beschleunigen kann.
Aber auch das beste dmake hilft nix, wenn das makefile einfach nicht für parallelisierung geschrieben wurde und alle tätigkeiten seriell abfertigt. Und gerade alte legacy anwendungen sind da echt klasse drin.

Die Nennung der FPU als limit bezog sich allerdings net auf den compilier-prozeß, sondern eher allgemein auf anwendungen, die sehr stark FP-lastig sind - und dazu zähle ich unsere auch.
Auch die Festellung bzgl. der Codeallergie bezieht sich auf die grundsätzliche T1/T2. Klar kann man bei vorhandenem source code das ganze mal eben für T1/T2 builden, aber wenn bestimmte settings für zertifizierung und Test vorgeschrieben sind (z.B. US2 code only), dann mag das Niagara überhaupt nicht und macht das sehr deutlich bemerkbar. Da sind die anderen Maschinen (mit US3,4) deutlich besser.
Und auch Solaris beinhaltet ja primär code, der aufgrund minimum spec. für UltraSparc 2 compiliert wurde. Deshalb kann man ja mit den CoolTools ja teilweise beträchtlich bessere performance aus dem system holen.

Es kann durchaus sein das meine Antwort etwas "multi-threaded" geschrieben war, das bitte ich zu entschuldigen da ich mich vorher ein bischen dem Absinth gewidmet habe 

Christian

[stiefkind]

Die Nennung der FPU als limit bezog sich allerdings net auf den compilier-prozeß, sondern eher allgemein auf anwendungen, die sehr stark FP-lastig sind - und dazu zähle ich unsere auch.

Dazu fällt mir spontan ein: Kennst du cooltst? Das ist ein kleines Progrämmchen mit dem man den FP-Anteil der aktuellen "Belastung" einer SPARC-CPU festellen kann. Details hier: http://cooltools.sunsource.net/cooltst/

Wurde u. a. speziell dazu geschrieben und veröffentlicht, um vor dem Kauf einer T1000/T2000 zu testen, ob denn die Applikation darauf auch nicht zu viel FPU braucht.

wolfgang

[CrystalPalace]

Hmm, nein das hab ich mir no net angeschaut. Aber das werde ich wohl mal in den nächsten Tagen, wenn ich mein derzeitiges Projekt fertig codiert habe. Bin mal auf Ergebnisse gespannt 

Wurde u. a. speziell dazu geschrieben und veröffentlicht, um vor dem Kauf einer T1000/T2000 zu testen, ob denn die Applikation darauf auch nicht zu viel FPU braucht

Naja, dort wo ich momentan arbeite ist das mit dem Geld nicht ganz so kritisch, da kauft man halt mal auch ne Maschine um fest zu stellen, das sie net wirklich gut geeignet ist 
Aber das is anderes Thema.


Grüße,

Christian

[Kaurik]

Hallo,

danke für den Tip mit dem Tool, das werde ich am Montag gleich mal ausprobieren.

Claus

[escimo]

Dazu fällt mir spontan ein: Kennst du cooltst? Das ist ein kleines Progrämmchen mit dem man den FP-Anteil der aktuellen "Belastung" einer SPARC-CPU festellen kann. Details hier: http://cooltools.sunsource.net/cooltst/

Das wäre die letzte Stelle, wo ich nach einem Programm zum "Messen" des Anteils von FPU-Instruktionen gesucht hätte. Da bin ich ja mal gespannt, wie sich das Tool auf einem Oracle 9i RAC Node (V490 mit 4 US-IV, 16 GB RAM) so anstellt. Nett.

Kennt jemand zufällig so ein Tool für sun4m (SuperSPARC-II, hyperSPARC)?

Übrigens: Oracle 9i kann die CMT-Funktionalität der UltraSPARC-IV überhaupt nicht ausschöpfen. Das bedeutet, dass von den 8 virtuellen CPU's (V490), lediglich 4 effektiv genutzt werden. Zum Glück plant man bereits die Migration auf Oracle 11g.