Freitag Okt 10, 2008

Unerwartete Parallelisierung - Threads all ueberall

SPECint2006 ist, anders als der auf Skalierung setzende SPECint_rate2006 ein CPU-Benchmark, der die Singlethread-Leistung einer CPU misst.  Doch seit auch Intel und AMD erkannt haben, dass Taktfrequenzsteigerungen keine Leistungssteigerungen mehr bringen, wird in den Entwicklungsabteilungen der Compilerbauer intensiv, und offenbar erfolgreich, an den Parallelisierungsmoeglichkeiten der Compiler gearbeitet.  Und diese Arbeit bringt nun erste Fruechte, zu sehen an den neuesten Ergebnissen von SPECint2006.  Mein Kollege Lawrence Spracklen hat sie untersucht.  Sein Fazit: "So much for single-threaded performance improvements :-)"  Mein Fazit: Die Einsatzgebiete von CMT-Technologie werden durch die Kombination dieser Entwicklung mit der zunehmenden Verbreitung paralleler Programmiertechniken immer universeller werden.  Und daß sich auch bei diesen Programmiertechniken einiges tut, kann man an der baldigen Verfuegbarkeit von Transactional Memory sehen...

Mittwoch Sep 24, 2008

Netzwerkperformance, Memoryperformance und wie sie zusammenhaengen koennen

In Solaris 10 update 6 wird der nxge Treiber (fuer 10GBit Ethernet) "Software Large Segment Offload" unterstuetzen.  Damit wird der Netzwerk-Durchsatz erhoeht, und gleichzeitig die hierfuer noetige CPU-Last verringert.  Welche Leistung damit erreichbar wird, ist im Blog von Pure See nachzulesen.


Interessantes Detail dabei ist, dass der Netzwerkperformance hierbei auch von den verwendeten DIMMs abhaengt.  Die Memoryleistung bei 4GB DIMMs ist deutlich besser als bei 2GB DIMMs, was der Netzwerkleistung direkt zugute kommt.  Andere Anwendungen, die Memorybandbreite benoetigen, profitieren natuerlich genauso hiervon.

Mittwoch Jul 30, 2008

Leistung skaliert - Ein Nachtrag

Kuerzlich hatte ich Anlass, mir die Leistungssteigerung von UltraSPARC T1 auf UltraSPARC T2 noch einmal anzusehen.  Hier ein paar Ergebnisse - auch wenn die Werte natuerlich "alt und bekannt" sein sollten.







































Benchmark UltraSPARC T1 UltraSPARC T2 Einheit Skalierungsfaktor
SPECweb2005 16407 41847 SPECweb2005 2,55
SPECjbb2005 74365 192055 bops 2,58
Lotus R6iNotes 16061 36240 NotesMark 2,26
SAP SD2 5530 10950 SAPS 1,98

Rechtlichs: Die offiziellen Benchmark-Ergebnisse fuer die genannten SPEC-Benchmarks sind verlinkt.  Die SAP-Ergebnisse sind auf der Benchmark Seite von SAP zu finden, die Zertifikate haben die Nummern 2007051 und 2007059.  Die Lotus-Ergebnisse finden sich auf notesbench.org.

Donnerstag Jul 24, 2008

Oracle Parallel

Immer wieder werde ich gefragt, ob sich die CMT-Server denn auch fuer Datenbanken, insbesondere Oracle, eignen.  Meine Antwort darauf ist schon fast stereotyp: "Es kommt auf die Last an."  Ist die Last gut parallelisiert oder parallelisierbar, und sind die Antwortzeiten einer einzelnen Transaktion nicht das kritische Erfolgskriterium, dann sind die Server ideal.  So wie bei jeder anderen durchsatzorientierten Anwendung :-)


Wie man einige Standard-Szenarien bei Oracle ohne grossen Aufwand parallel, und damit fuer CMT Systeme ideal, ausfuehren kann, hat mein Kollege Glenn Fawcett in einer Serie von Blogeintraegen beschrieben.  Sie sind es wert, gelesen und ggf. als Bookmark gespeichert zu werden. 

Dienstag Mai 27, 2008

PCIe Leistung der T5240

Hier ist ein recht ausfuehrlicher Beitrag eines Kollegen zur Leistungsfaehigkeit der PCIe-Topologie der T5240.
 

Mittwoch Apr 16, 2008

Memory-Bandbreite der 2-Sockel T2+

Ein Kollege hat die Memory-Bandbreite der 2-Sockel Systeme mit dem bekannten "Stream" Benchmark gemessen.  Bis zu ca. 30 GB/sec. sind gar nicht so schlecht...  Fuer die Ein-CPU Systeme hat die RWTH Aachen bspw. ca. 16GB/sec. gemessen, die Uni Erlangen ca. 12GB/sec, im Peak 16GB/sec (Details in PDF).  Damit sollte auch geklaert sein, dass die Anzahl der Memory-Controller pro CPU nicht das allein ausschlaggebende Element bei der Bestimmung der tatsaechlichen Bandbreit sein muss.

Benchmarken ist eine Kunst...

Ich mache jetzt 8 Jahre Benchmarks.  In dieser Zeit ist mir so das eine oder andere untergekommen, nicht zuletzt auch der eine oder andere Fall, in dem nicht das Testsystem, sondern der Lastgenerator gemessen wurde.  Soll ja vorkommen, und schliesslich machen die meisten Leute so etwas nicht regelmaessig.  Bis auf die Profis eben, die u.A. jeder Hardwarehersteller dafuer bezahlt, dass sie so Benchmarks wie z.B. den SPEC CPU2006 auf neuer Hardware solange tunen, bis ein optimaler, fuer den Hersteller natuerlich guenstiger Wert, dabei herauskommt.  Wobei natuerlich streng darauf geachtet wird, dass dieser Wert auch reproduzierbar ist - schliesslich will man sich ja auch seine Glaubwuerdigkeit nicht beschaedigen.

Jetzt lese ich neulich in einer renomierten deutschen IT-Zeitschrift davon, dass ein Redakteur versucht hat, eben diesen Benchmark, den SPEC CPU2006, auf einer T5220 nachzumessen.  Das ist nicht verkehrt, schliesslich ist Reproduzierbarkeit ein Ziel solcher Benchmarks.  Wie das bei aufwendigeren Benchmarks so ueblich ist, stiess auch dieser Redakteur auf gewisse Schwierigkeiten.  Die einzelnen Jobs dauerten lange - zu lange fuer die ihm zur Verfuegung stehende Zeit auf dem Testsystem.  Desweiteren konnte er mangels Hauptspeicher nicht die Maximalzahl der Jobs starten, die er fuer das Nachstellen der offiziellen Werte gebraucht haette.  Dass sein Testsystem nicht mit 1.4 GHz, sondern nur mit 1.2 GHz getaktet war, war da dann auch nicht mehr wesentlich.  

Weil also nur ein einzelner Job tatsaechlich durchlief (einer von 64), und weil der Hauptspeicher fuer 64 Jobs und die Zeit fuer die Jobs mit z.B. 16 oder 32 Threads fehlte, blieb dem Redakteur nichts anderes uebrig, als das Ergebnis seines Einzellaufs hochzurechnen.  Er war enttaeuscht, dass 100% Skalierung bei einem Messpunkt am unteren Ende nicht zu erreichen war.

Das alles ist nicht ungewoehnlich.  Zeit gibt es bei Benchmarks eigentlich nie ausreichend.  Und man darf kaum erwarten, dass ein erster Schuss mit einer doch eher grossen Benchmark-Suite wie dem SPEC CPU2006 gleich sitzt.  Enttaeuscht war ich jedoch von den Schlussfolgerungen:

Weil Sun die Werte mit 64GB Hauptspeicher gerechnet hat schliesst der Redakteur, dass die CPU nur mit diesem Speicherausbau die entsprechende Leistung bringt.  Ja, natuerlich braucht die Benchmarksuite 64GB RAM, wenn man 64 Threads davon testen will.  Aber wenn die tatsaechlich bei einem Kunden im Einsatz befindliche Anwendung fuer 64 Threads weniger Hauptspeicher benoetigt, hat es doch die selbe CPU zur Verfuegung, oder?

Weiter wird in Frage gestellt, ob denn 64GB RAM in "professionellen Umgebungen" ueblich sind.  Ist das nicht ganz stark davon abhaengig, welche Anwendung dieser Profi benoetigt?  Und die Leistungsfaehigkeit haengt ja, siehe oben, nicht vom RAM-Ausbau ab.  (Jedenfalls nicht erheblich - die Memory-Bandbreite ist durchaus von der Anzahl der DIMMs abhaengig, aber man kann ja auch 16 1GB DIMMs einbauen....)

Ich koennte jetzt noch weiter gehen und kleinere Unstimmigkeiten in diesem Artikel aufzaehlen.  Aber das fuehrt zu nichts.  Nur schade, dass es dem Redakteur nicht gelungen ist, nach dem einen SPEC CPU2006-Job und dem Nachschlagen von SPECjbb2005 noch weitere Benchmarks (wie z.B. Lotus Notes, SAP SD, SPECweb2005) zu betrachten, oder in einigen Blogs ( RWTH Aachen, Uni Erlangen) zu lesen, was an echtem Number-Crunching interessierte Forscher von der CPU halten.  Aber letztlich ist es eben doch eine Kunst, das Benchmarken.

Dienstag Apr 15, 2008

Wie schnell sind sie denn, die Crypto-Units?

Ein kleiner Nachtrag zu den Crypto-Units der T2/T2+ CPUs.  Ein Kollege fragte mich, wie man denn am einfachsten demonstriert, was diese Beschleuniger z.B. einem Webserver bringen.  Am einfachsten geht das mit dem Speedtest von OpenSSL:

 Ohne Hardware-Beschleunigung geht das auf einer T5120 so:

# openssl speed rsa1024             
Doing 1024 bit private rsa's for 10s: 407 1024 bit private RSA's in 10.01s
Doing 1024 bit public rsa's for 10s: 6994 1024 bit public RSA's in 9.99s
OpenSSL 0.9.7d 17 Mar 2004 (+ security patches to 2006-09-29)
built on: date not available
options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,risc1,16,long) aes(partial) blowfish(ptr)
compiler: information not available
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
                  sign    verify    sign/s verify/s
rsa 1024 bits   0.0246s   0.0014s     40.7    700.1

Mit Hardwarebeschleunigung so:

 # openssl speed rsa1024 -engine pkcs11
engine "pkcs11" set.
Doing 1024 bit private rsa's for 10s: 15551 1024 bit private RSA's in 0.60s
Doing 1024 bit public rsa's for 10s: 32649 1024 bit public RSA's in 0.99s
OpenSSL 0.9.7d 17 Mar 2004 (+ security patches to 2006-09-29)
built on: date not available
options:bn(64,32) md2(int) rc4(ptr,char) des(ptr,risc1,16,long) aes(partial) blowfish(ptr)
compiler: information not available
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
                  sign    verify    sign/s verify/s
rsa 1024 bits   0.0000s   0.0000s  25918.3  32978.8

Im Ueberblick:

  RSA1024 sign/s
 RSA1024 verify/s
 Ohne CryptoUnit
 40700
 Mit CryptoUnit
 25918 32978


 Zu Demozwecken hier natuerlich nur mit einem Thread.  Nicht vergessen: Die CPU hat 8 Cryptounits...

Nachtrag: Natuerlich wird hier nur der Crypto-Beschleuniger gemessen.  In einer Anwendung mit Webserver und ggf. Applicationserver ist dessen Beitrag natuerlich nicht 100% ;-)

Montag Apr 14, 2008

Little Rock...

Der inzwischen ja doch allgemein bekannte Codename "Rock" hat ja, was die Sunnies wissen koennten, seinen Ursprung in "R\* on a Chip".  Nun haben wir offenbar die Tester an der Uni Erlangen mit dem UltraSPARC T2+ so sehr begeistert, dass sie von dieser CPU sagen, es sei ein "IBM BlueGene on a chip".  Na, unsere Entwickler wird's freuen - oder anfeuern, je nachdem, in welchem Team sie arbeiten ;-)

Freitag Apr 11, 2008

Leistung skaliert

Nachdem vorgestern die neuen 2-Sockel CMT-Systeme angekuendigt wurden, hier nun ein paar Eckdaten zur Leistung und Skalierung:

 BenchmarkT5x20
T5x40
Skalierung
SPECint_rate2006 78.5 157x2
 SPECfp_rate2006 62.3 119x1.91
 SAP SD 2-tier
 2,175 4,170x1.91
 Lotus R6 iNotes
 43,000 65,000x1.51
 SPECjbb2005 192,055 373,405x1.94

 

Auf den hier gelinkten Seiten sind auch noch weitere Benchmarks veroeffentlicht, aber ich denke, als Anhaltspunkte fuer eine doch recht lineare Skalierung sollte dies reichen.  Natuerlich kann man diese Werte auch auf den offiziellen Seiten der jeweiligen Benchmarks nachlesen.

 Was man im uebrigen hier beachten sollte:  Die mit diesen Werten bewiesene Skalierbarkeit bezieht sich nicht nur auf die Hardware, sondern auch auf das Betriebsystem.  Man sollte nicht vergessen, dass man hier von 64 Threads auf 128 Threads skaliert - das OS muss also nun auf 128 "CPUs" skalieren.  Solaris hat das schon fuer die SF25k "gelernt" und stellt es hier erneut unter Beweis.  Man darf sich auf weitere Hoehenspruenge freuen ;-)

About

Neuigkeiten, Tipps und Wissenswertes rund um SPARC, CMT, Performance und ihre Analyse sowie Erfahrungen mit Solaris auf dem Server und dem Laptop.

This is a bilingual blog (most of the time). Please select your prefered language:
.
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Categories
Archives
« April 2014
MoDiMiDoFrSaSo
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Heute