Donnerstag Mrz 27, 2014

Ein paar Gedanken zu Single Thread Performance

Eines werde ich immer wieder gefragt: Wie misst man Single Thread Performance ?

So gerne ich auch wollte, die Antwort ist leider nicht so einfach wie die Frage.  Und leider auch ein wenig laenger.

Selbst die Definition von Single Thread Performance ist nicht immer die gleiche, weswegen ich damit anfangen moechte.  In diesem Blog ist Single Thread Performance die Menge an Arbeit die eine Software, die als einzelner Instruktions-Strom ablaeuft, in einer gewissen Zeit erledigt.

Das alles dient natuerlich dazu, die Leistung (schon wieder ein schwammiger Begriff..) eines Computersystems, oder manchmal einer Komponente davon, in Bezug auf die zu erwartende Single Thread Performance zu bewerten.

Genug der Vorrede, was uns jetzt interessiert sind die Moeglichkeiten, Single Thread Performance zu messen und natuerlich zu vergleichen.

Das erste, was einem hierzu einfaellt ist ein kleines Testprogramm.  Irgend etwas, von dem wir wissen dass es single threaded  ist und eine Weile dauert.  Je nachdem, was man im taeglichen Leben so macht, koennte das ein kleines Shell-Skript sein, das von 1 bis 1 Million zaehlt, ein SQL-Loop der Fibonacci-Zahlen berechnet oder ein kleines Programm zur Erzeugung kryptographischer Hashes.  Aber bekommen wir damit, was wir wirklich wollen - ein zuverlaessiges Mass der allgemeinen Single Thread Performance eines Systems?  Immerhin sind die Anforderungen all dieser Micro-Benchmarks sehr unterschiedlich.  Manche bevorzugen grosse Caches um die Memory-Latenz zu verstecken.  Andere brauchen hohen Memory-Durchsatz, wieder andere skalieren einfach mit der CPU-Taktrate.  Wie wuerden wir daher die allgemeine Single Thread Leistung eines Systems fuer diese sehr unterschiedlichen Anforderungen bewerten?  Hier ein Beispiel.  Das Diagram zeigt die Leistung verschiedener Tests einer kleinen Testsuite, die ich auf jedem SPARC-System laufen lasse, das ich in die Finger bekomme.  Was die Tests machen, ist nicht interessant.  Wichtig ist, dass sie alle single threaded laufen und nur CPU-gebunden sind

Folgendes ist dabei wichtig:

  1. Test 1 scheint sehr cache-freundlich zu sein - die 3 CPUs mit Caches groesser als 8MB liegen deutlich vorn.  Auch scheint dieser Test von Cache mehr zu profitieren als von Taktrate, da die 1.8 GHz CPU knapp vor der 2.66 GHz CPU liegt. 
  2. All die anderen Tests skalieren ungefaehr mit der Taktrate, das 3.6 GHz System liegt daher vorn.
  3. Es gibt kein festes Verhaeltnis von Leistung und Taktrate.  In Test 1 liegen alle Ergebnisse sehr nahe beinander, waehrend die Unterschiede in Tests 3 und 4 stark schwanken.

Das alles fuehrt letzten Endes zu der Erkenntnis: Single Thread Performance haengt in erster Linie von der Anwendung und den Daten ab - es gibt keine allein selig machende Antwort.  Das sollte natuerlich keine Ueberraschung sein, letztlich ist das bei jedem Benchmark so.  Bei der Bewertung von Single Thread Performance ist es jedoch besonders wichtig, da hier die Unterschiede besonders stark zu Tage treten.  Ein letzter Blick auf das obige Diagramm:  In Test 1 ist das 2.66 GHz System ca. 1/3 schneller als das 2.85 GHz System, und ungefaehr gleich schnell wie das mit 1.8 GHz.  Gemaess Tests 2 und 3 jedoch ist das 1.8 GHz System deutlich schneller als das 2.66 GHz System, aber alle anderen sind schneller als diese beiden.  Das Problem bei der ganzen Sache ist: Man weiss nie, welchen Fall man mit dem jeweils bevorzugten Testprogramm gerade erwischt.  Egal was man testet, egal wie die Resultate ausfallen, es ist zumindest sehr schwierig, damit Performancevorhersagen zu treffen.

Aber vielleicht helfen ja die "offiziellen" Benchmarks weiter.  Der einzige einigermassen relevante, der sich (noch) mit Single Thread Performance beschaeftigt ist SPECcpu2006.  Der Einfachheit halber beschraenke ich mich in dieser Betrachtung auf CINT2006.  Es gibt zwei Varianten davon, den single threaded SPECint_2006 und die Durchsatzvariante SPECint_rate2006.  Da uns Single Thread Performance interessiert, ist SPECint_2006 die natuerliche Wahl.  Leider gibt es auch hier zwei Probleme:
  1. SPECint_2006 ist nicht wirklich single threaded.  Einige der Teilbenchmarks koennen von modernen Compilern sehr gut parallelisiert werden.  Das wird von den Benchmark-Regeln erlaubt und natuerlich oft benutzt.
  2. Nicht alle Hersteller veroeffentlichen SPECint_2006.  Es gibt sehr viele Veroeffentlichungen von SPECint_rate2006 aber sehr viel weniger Veroeffentlichungen der entsprechenden single thread Variante des gleichen Systems.

Wegen dieser Probleme scheint auch SPEC CPU2006 nicht die Antwort auf unsere Frage zu liefern.  Es gibt jedoch viele die meinen, dieses Problem umgehen zu koennen.  Sie argumentieren ungefaehr so:

"SPECint_rate2006 ist nichts anderes als ein paralleler Lauf vieler Kopien von SPECint_2006 auf einem groesseren System.  Wenn ich also die Single Thread Performance dieses Systems wissen moechte, muss ich einfach nur das SPECint_rate2006 Ergebnis durch die Anzahl der CPU Threads oder evtl. durch die Anzahl der verwendeten Kopien, die in der Veroeffentlichung dokumentiert sind teilen, um das Single Thread Ergebnis zu bekommen."

Das klingt eigentlich ganz einfach.  Aber funktioniert es?  Das laesst sich anhand einiger Beispiele ueberpruefen, bei denen es gluecklicher Weise Ergebnisse fuer SPECint_2006 und SPECint_rate2006 gibt.  Um die Betrachtung einfach zu halten, werde ich hier nur den Sub-Benchmark perlbench betrachten, nicht das Gesamtergebnis.  Wer moechte, kann das gerne mit anderen Sub-Benchmarks ueberpruefen.

System SPECint_2006 perlbench SPECint_rate2006 perlbench Number of copies SPECint_rate2006 perlbench / Anzahl der Kopien
Genauigkeit der Single Thread Schaetzung
M3000 16.4 83.5 8 10.4 64%
Power780 4.14 GHz 28.1 1120 128 8.75 31%
Sun Fire X4-2
(Intel Xeon E5-2697 v2 2.7GHz)
41
894
96 9.3
23%

Alle diese Werte sind von spec.org vom 17. Maerz 2014.  Die jeweiligen Werte sind mit ihren Gesamt-Veroeffentlichungen auf spec.org verlinkt.

Es wird sehr deutlich, dass eine Abschaetzung der Single Thread Performance mit diesem einfachen Vorgehen nicht funktioniert.  Warum nicht?  Weil die heutigen CPUs alle multi-threading CPUs sind.  Sie haben nicht nur alle mehrere Kerne, die sich L2 oder L3 Caches und die Memory-Bandbreite teilen.  Sie haben darueber hinaus mehrere Threads, die sich einen Kern teilen.  Der Sinn dieser Threads liegt in einer hoeheren Kernauslastung:  Ein einzelner Thread ist nicht in der Lage, die modernen, schnell laufenden Kerne auch nur annaehernd auszulasten, hauptsaechlich weil die Memory-Latenz mit der Entwicklung der CPU-Taktraten nicht schrittgehalten hat.  Das bedeutet, dass ein zweiter, dritter oder vierter Thread in der Lage ist, zusaetzliche Arbeit zu verrichten ohne die anderen auf diesem Kern laufenden Threads wesentlich zu beeinflussen.  Natuerlich gibt es den Punkt, ab dem der Kern im Wesentlichen ausgelastet ist und daher die zusaetzliche Arbeit, die durch weitere Threads ausgefuehrt wird, mit zunehmender Threadanzahl abnehmen wird.  Das Diagram rechts stellt diesen Zusammenhang idealisiert dar.  Je nach Charakteristik der Rechenlast variiert die optimale Anzahl von Threads zwischen 1 und 8.  Das ist normal und im taeglichen Betrieb eines Rechenzentrums liefern diese CPUs daher hervorragenden Durchsatz.  Allerdings ist es fuer die Kapazitaetsplanung manchmal eine Herausforderung.  Im Falle einer Benchmark-Konfiguration fuer einen Durchsatz-Benchmark wie SPECint_rate2006 jedoch ist maximaler Durchsatz das einzige Ziel.  Daher sind auch die bspw. 2%, die ein weiterer Thread zum Gesamtergebnis noch beitraegt willkommen.  Durchsatz-Benchmarks wie SPECint_rate2006 oder SAP SD 2 Tier werden fuer maximalen Durchsatz optimiert. 

Das bedeutet jedoch zwingend, dass die durchschnittliche Leistung pro Thread deutlich unter der potentiellen Maximalleistung eines Threads liegt.  Und deswegen kann dieser Durchschnitt nicht zur Bewertung der Single Thread Performance herangezogen werden.

Aber welchen anderen Ausweg gibt es?  Hier hilft eine Rueckbesinnung auf das, was wir wirklich wissen wollen.  Single Thread Performance ist ja kein Wert an sich.  Sie hat einen Zweck.  In den meisten Faellen geht es um die Antwortzeit einer Anwendung - Antwortzeit, die unsere Erwartungen erfuellt oder unterschreitet.  Gluecklicher Weise gibt es einen Benchmark, der genau diese Anforderungen stellt:  SPECjbb2013.  Nun weiss ich natuerlich, dass dieser Benchmark sich speziell mit den Anforderungen an einen Application Server befasst.  Was sich stark von denen an bspw. ein Datawarehouse unterscheidet.  Nichts desto Trotz liefert er uns zuverlaessige Hinweise ueber die Single Thread Performance und, noch wichtiger, liefert er uns Hilfen zum Verstaendnis von Single Thread Performance im Vergleich verschiedener Systeme (wenn denn Ergebnisse vorhanden sind...)

Daher also nun ein kurzer Blick auf SPECjbb2013 und wie dieser Benchmark uns vielleicht helfen kann, unsere Frage zu beantworten:

Die Ergebnisse von SPECjbb2013 werden in zwei Werten gemessen:  max-jOPS und critical-jOPS.  max-jOPS ist dabei ein reiner Durchsatz-Wert, der diese Diskussion nicht weiter bringt.  critical-jOPS hingegen ist "a metric that measures critical throughput under service level agreements (SLAs) specifying response times ranging from 10ms to 500ms." (Zitat aus der Benchmark Beschreibung von SPEC.)  Es wird also Durchsatz unter einer Antwortzeiten-Bedingung gemessen.  Damit entsteht ein hoher Druck sowohl auf das System als auch auf die Benchmark-Teams.  Sie muessen das System fuer die sehr realistische Anforderung optimieren, niedrig-latente Antworten bei gleichzeitig hohem Durchsatz zu liefern.  Wie hilft uns das nun auf unserer Suche nach einem Vergleich der Single Thread Performance weiter?  Nun, angenommen wir haben zwei Systeme mit vergleichbarer Konfiguration und Preis.  System A liefert 10000 max-jOPS und 5000 critical-jOPS.  System B liefert 7500 max-jOPS und 6000 critical-jOPS.  System A schafft also einen hoeheren Durchsatz, allerdings nur, solange wir die Antwortzeiten ignorieren.  Der Durchsatz mit System B ist dagegen nicht so hoch, das System schafft jedoch mehr critical-jOPS als System A.  Das ist fuer uns ein Hinweis, dass die Single Thread Performance von System B besser ist als die von System A - es schafft einen hoeheren Durchsatz unter Antwortzeit-Bedingungen.  Zugegeben, auch das ist nicht die "allein selig machende" Antwort auf die Frage nach der absoluten Single Thread Performance, die wir evtl. gesucht haben.  Eine Aussage der Art "System A hat eine 3x hoehere Single Thread Performance als System B" wird es nicht geben.  Das liegt u.A. daran, dass Durchsatz und die Art und Weise wie ein System skaliert und mit einer hoch skalierenden Last umgeht eine grosse Rolle in diesem Benchmark spielt.  Es ist jedoch ein sehr realistisches Szenario das uns einige belastbare Hinweise gibt, was wir bzgl. der Single Thread Performance von verschiedenen Maschinen erwarten koennen.  Wie mit jedem anderen Benchmark auch, muessen diese Schlussfolgerungen natuerlich spezifisch fuer die jeweilige Anwendung, die verwendeten Daten, die Test-Umstaende und aehnliches sein.  Aber SPECjbb2013 ist ein gutest Beispiel dafuer, wie man Hinweise auf Single Thread Performance bekommen kann.

Eine letzte Bemerkung zu SPECjbb2013:  Die Benchmark Teams der verschiedenen Hersteller fangen gerade erst an, diesen neuen Benchmark zu verstehen.  So gibt es bspw. 3 Resultate fuer die Oracle SPARC T5-2, mit critical-jOPS Werte von 23334 bis 43963.  Das macht deutlich, dass man hier vorsichtig vorgehen sollte, moechte man nicht Aepfel mit Birnen vergleichen.  Der Loewenanteil an diesen Unterschieden ist auf die verwendete Java-Version zurueck zu fuehren.  Das erste Ergebnis wurde mit JDK 7u17 erzielt, das zweite, 1.89x bessere mit dem kuerzlich angekuendigten Java 8 JDK.  Das zeigt nicht nur, dass man bei Vergleichen die Software Version beruecksichtigen muss sondern auch, wie Vorteilhaft es sein kann, eine neue Version einzusetzen.  Gluecklicher Weise gibt es zunehmend mehr Einreichungen fuer diesen Benchmark, so dass es in Zukunft hoffentlich einfacher wird, Vergleiche anzustellen.

Geschafft - das war eine etwas lange Antwort auf eine kurze Frage...  Fuer all diejenigen, die noch mehr wissen moechte, hier noch ein paar Vorschlaege:

Vielen Dank an Ruud van der Pas und Patrick McGehearty fuer Ihre Beitraege zu diesem Eintrag!

Benchmark Disclosures:
SPEC and the benchmark names SPECjbb2013 and SPECint are registered trademarks of the Standard Performance Evaluation Corporation. Results as of March 17, 2014 from www.spec.org

Freitag Jan 22, 2010

Threadbar

Dieses Tool ist einen Blogeintrag ueber den Blogeintrag wert.  Wer kennt ihn nicht, den guten alten perfbar? Thrbar (eigentlich wohl Threadbar) ist ein Perfbar fuer die Threads eines Prozesses.  Damit wird es endlich moeglich, den Unterschied zwischen einem aktiven und einem existierenden Thread zu visualisieren.  Warum mussten wir eigentlich bis 2010 auf dieses Tool warten?  Dabei ist die Idee wirklich naheliegend.  Aber so ist es ja oft mit guten Ideen - wenn sie mal bekannt sind, schlagen wir uns alles ans Hirn und wundern uns, warum wir da nicht selbst schon lange darauf gekommen sind.  Deswegen meine doppelt ausgesprochene Hochachtung an Rickey Weisner fuer dieses Tool!

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