LRZ-Mitteilungen Oktober 2000

Verteiler für dieses Rundschreiben

Diese Mitteilungen sind im Benutzerarbeitsraum und in der Anmeldung im LRZ-Gebäude sowie an den Außenstationen des LRZ erhältlich und über

http://www.lrz-muenchen.de/services/schriften/rundschreiben/

abrufbar. Sie werden auch an alle Lehrstühle der Münchner Hochschulen sowie an alle anderen bayerischen Hochschulen versandt. Übersichten über die Netzbenutzung am LRZ sind über

http://www.lrz-muenchen.de/services/netz/statistik/

erhältlich.

Einige wichtige Telefonnummern:

LRZ-Hotline (für alle Fragen) (089) 289-28800

LRZ-Anmeldung (Benutzersekretariat) (089) 289-28784 und (089) 289-28886

Fax: (089) 289-28761

Herausgeber: Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften

Anschrift: Leibniz-Rechenzentrum
der Bayerischen Akademie der Wissenschaften
Barer Straße 21
D-80333 München

Telefon: (089) 289-28784
Telefax: (089) 280 9460
E-Mail: lrzpost@lrz.de

Redaktion:

Dr. Michael Wiseman
Wolfgang Beyer
Dr. Helmut Richter

Termine, Veranstaltungen, Allgemeines

Termine

Weitere Informationen zu folgenden Terminen finden Sie in den Beiträgen der vorliegenden Mitteilungen.

Beachten Sie bitte auch unser aktuelles Kurs- und Schulungsangebot! Siehe:

http://www.lrz-muenchen.de/services/schulung/kurse-ws2000/

27.11.2000	Anmeldeschluss für die Teilnahme an dem Tutorial Programming and Optimization Techniques for the Hitachi SR8000-F1
30.11.2000	Anmeldeschluss für die Teilnahme an der Sonderveranstaltung Professionelles Data Mining

Personalversammlung

Wegen einer Personalversammlung der Beschäftigten des Leibniz-Rechenzentrums werden am

die Beratung und das Benutzersekretariat geschlossen und Mitarbeiter des LRZ nicht erreichbar sein. Die Zugänglichkeit zu den Rechnern und Arbeitsräumen wird dabei jedoch nicht eingeschränkt. Die Hotline ist in dieser Zeit mit einem "Notdienst" besetzt. Wir bitten um Ihr Verständnis.

Michael Wiseman
Wiseman@lrz.de

Verlängerung der DV-Projekte am LRZ für 2001

Die Berechtigung zur Nutzung von LRZ-Systemen (mit persönlichem Login) wird im Rahmen eines DV-Projekts erteilt, das von der jeweiligen Einrichtung jährlich verlängert werden muss. Diese Regelung gilt nicht für Projekte am Bundeshöchstleistungsrechner.

Ein DV-Projekt am LRZ ist als organisatorischer Rahmen notwendig, wenn Angehörige einer Einrichtung oder von dieser Einrichtung (etwa im Rahmen von Diplomarbeiten) betreute Studenten LRZ-Rechner benutzen möchten, für die ein persönliches Login erforderlich ist. Dagegen sind die allgemeinen Dienstleistungen des LRZ wie Beratung in DV-Fragen, Beschaffung von Software oder Zusendung der LRZ-Mitteilungen nicht an die Existenz eines DV-Projekts gebunden. Die Verlängerung von so genannten Studentenkennungen, die vom LRZ direkt vergeben werden, ist von dieser Aktion für DV-Projekte von Einrichtungen nicht betroffen und erfolgt unabhängig davon, jeweils semesterweise.

Die Aufforderung zur Verlängerung für das Jahr 2001 wird in den nächsten Wochen an die Leiter der jeweiligen Einrichtungen verschickt; die derzeitigen Master User werden per E-Mail davon verständigt. Wie schon im letzten Jahr praktiziert und bestens bewährt, enthalten die Verlängerungsunterlagen für jedes Projekt nur noch ein einziges Blatt "Verlängerung des Projekts ...", das vom LRZ bereits mit dem ihm bekannten Daten ausgefüllt ist. In vielen Fällen wird es daher genügen, wenn der Leiter der Einrichtung und der jeweilige Master User dieses vorbereitete Blatt unterschreiben und an das LRZ zurücksenden.

Den Verlängerungsunterlagen liegt auch das Formblatt "Antrag auf Benutzerausweise" bei. Beachten Sie aber bitte, dass ein Benutzerausweis nur dann notwendig ist, wenn der betreffende Benutzer Schriften oder Software im LRZ-Benutzersekretariat erwerben oder ausleihen möchte und nicht über einen Studenten- bzw. Dienstausweis verfügt. Dagegen ist es unbedingt erforderlich, dass der jeweilige Master User bei der Vergabe einer persönlichen LRZ-Kennung das Formblatt "Erklärung des Endbenutzers" ausfüllen und unterschreiben lässt. Dieses Formblatt liegt ebenfalls den Verlängerungsunterlagen bei, kann aber auch beim LRZ-Benutzersekretariat bzw. beim Betreuer angefordert werden; außerdem ist es online abrufbar:

Was geschieht, wenn ein Projekt nicht verlängert wird? Nutzer von LRZ-Hochleistungssystemen (VPP700, IBM SP2, Cray T90) werden ab Anfang Dezember beim Login gewarnt; ab Anfang des neuen Jahres sind dann jedenfalls keine Batchjobs mehr möglich. Nutzer anderer LRZ-Plattformen erhalten Anfang des Jahres einen entsprechenden Hinweis per Mail; ab Anfang März wird generell kein Login mehr zugelassen. Davon betroffene Nutzer sollten sich umgehend an ihren Master User wenden.

Paul Sarreither
Sarreither@lrz.de

Tutorial: Programming and Optimization Techniques for the Hitachi SR8000-F1

Gemeinsam mit dem Regionalen Rechenzentrum Erlangen (RRZE) und dem Kompetenznetzwerk für Technisch-Wissenschaftliches Hoch- und Höchstleistungsrechnen in Bayern (KONWIHR) veranstaltet das Leibniz-Rechenzentrum unter dem Titel

Programming and Optimization Techniques for the Hitachi SR8000-F1

ein dreitägiges Tutorial zur Nutzung des Höchstleistungsrechners Hitachi SR8000-F1.

Folgende Themen sind vorgesehen:

Dienstag 5. Dezember 2000, 9:00-17:00 Uhr:

Concepts of Modern High Performance Computers

Understanding Parallelism

High Performance Platforms of the LRZ and in Germany: Which is the most appropriate for my problem?

Writing Parallel Message Passing Programs with MPI (Part 1)

Kursniveau: 65% Einführung, 35% Fortgeschr., 0 % Experte

Mittwoch 6. Dezember 2000, 9:00-17:00 Uhr:

Writing Parallel Shared Memory Programs with OpenMP

The Next Step: Hybrid Programs OpenMP/MPI

Optimization for RISC Processors

Overview of the SR8000-F1 at the LRZ (Part 1)

Writing Parallel Message Passing Programs with MPI (Part 2)

Kursniveau: 55% Einführung, 35% Fortgeschr., 10 % Experte

Donnerstag 7. Dezember 2000, 9:00-17:00 Uhr:

Overview of the SR8000 at the LRZ (Part 2) Managing the Compilers on the SR8000

Tuning Programs

Tools and Libraries for Optimization on the SR8000

Specific Optimization Techniques

Kursniveau: 40% Einführung, 40% Fortgeschr., 20 % Experte

Der Kursinhalt der beiden ersten Tage ist nicht auf die SR8000 beschränkt, sondern ist für all diejenigen interessant, die sich mit der Parallelisierung beschäftigen, sei es auf LINUX-Clustern oder Hochleistungsrechnern. Deshalb kann natürlich auch eine Anmeldung gezielt für einzelne Kurstage erfolgen. Umgekehrt, wer sich schon mit MPI und OpenMP auskennt, kann auch nur zum dritten Kurstag kommen. Auch bei der Wahl der Kurssprache sind wir für die ersten beiden Tage noch flexibel, je nach Teilnehmerkreis können wir zwischen deutsch oder englisch wechseln, am dritten Tag wird die Kurssprache wegen des Dozenten aber zumindest teilweise englisch sein.

Ort :

Leibniz-Rechenzentrum

Barer Str. 21

80333 München

Seminarraum: S3532

Dozenten:

Dr. Matthias Brehm, Dr. Helmut Heller, Dr. Reinhold Bader (alle LRZ), Dr. Gerhard Wellein (RRZE), Dr. Tim Lanfear (Hitachi Europe).

Anmeldung:

Anmeldeschluss ist der 27.11.2000. Die Anmeldung sollte über das Webformular in

http://www.lrz-muenchen.de/services/compute/hlrb/kurse

erfolgen.

Matthias Brehm
Brehm@lrz.de

Sonderveranstaltung: Professionelles Data Mining

Die professionelle Data Mining-Workbench Clementine von SPSS setzt laut dem Ovum Data Mining Report einen "Standard für Data Mining-Workbenches, da die Software den Anwender durch sämtliche Schritte des Data Mining-Prozesses begleitet".

Das Programm verfügt dazu u.a. über Neuronale Netze, Entscheidungsbäume und weitere Statistiken. Auf einer grafischen Oberfläche wird der komplette Data Mining-Stream vom Datenzugriff bis hin zur Ergebnisausgabe mit Icons via "drag-and-drop" aufgebaut und visualisiert.

Ziel von Data Mining ist es, Muster und Trends in vorhandenen Datenbeständen aufzudecken. Die Anwendungsgebiete sind dabei äußerst vielfältig. Sie reichen beispielsweise von der Betrugsaufdeckung über die Aufdeckung von Kreditrisiken, das Erkennen von potentiellen Vertragskündigern bis hin zur Erforschung des Konsumentenverhaltens (Stichwort: Cross-Selling-Potenziale). Aber auch Analysen aus dem akademischen Bereich (Medizin, Verhaltenswissenschaften u.v.a.m.) können bequem und übersichtlich mit Clementine durchgeführt werden.

Es findet am LRZ zu diesem Themenkreis ein Workshop statt, der von der SPSS GmbH Software, dem Entwickler von Clementine und dem LRZ ausgerichtet wird:

Ort und Zeit:

Datum: Montag, 29.01.2001

Zeit: 14:00 bis ca. 18:00 Uhr

Ort: Seminarraum S3532 im 3. OG des LRZ

Eine Agenda zu dieser Veranstaltung erscheint demnächst unter

http://www.lrz-muenchen.de/services/schulung/veranstaltungen/

Schriftliche (auch E-Mail-) Anmeldungen für diese Veranstaltung bitte bis spätestens 30.11.2000 an mich!

Michael Wiseman
Wiseman@lrz.de

Stellenangebot

Stellenangebot der Abteilung Benutzerbetreuung

Das Leibniz-Rechenzentrum (LRZ) der Bayerischen Akademie der Wissenschaften ist das regionale Rechenzentrum für alle Hochschulen Münchens, eines der Höchstleistungsrechenzentren in Deutschland und Betreiber des Münchner Wissenschaftsnetzes.

Die Abteilung Benutzerbetreuung sucht zum 1.1.2001 eine(n)

wissenschaftliche(n) Mitarbeiter(in)

Als Aufgabengebiete warten auf Sie:

• Betreuung und Pflege von Informationssystemen am LRZ ("Webmaster")
• Betreuung des (LRZ-intern eingesetzten) elektronischen Kalenders
• Betreuung von Anwendersoftware aus den genannten Gebieten
• Mitarbeit bei den allgemeinen Aufgaben der Abteilung Benutzerbetreuung

Unsere Anforderungen sind:

• Erfolgreich abgeschlossenes Universitätsstudium in einem IT-orientierten Studiengang
• Teamfähigkeit und selbständiges Arbeiten
• Bereitschaft zur Aneignung fehlender Kenntnisse auf dem zukünftigen Arbeitsgebiet
• kreatives Engagement für das zukünftige Arbeitsgebiet

Die Anstellung erfolgt nach BAT, die Eingruppierung richtet sich nach Ausbildung und Berufserfahrung. Schwerbehinderte werden bei gleicher Eignung bevorzugt.

Für eine erste Kontaktaufnahme oder für nähere Auskünfte wenden Sie sich bitte an:

Herrn Dr. Sarreither, Tel. 089/289-28745, E-Mail: Sarreither@lrz.de

Herrn Haarer, Tel. 089/289-28714, E-Mail: Haarer@lrz.de

Schriftliche Bewerbungen mit den üblichen Unterlagen senden Sie bitte an:

Leibniz-Rechenzentrum
z. H. Frau Ch. Binder
Barer Straße 21
80333 München

Bundeshöchstleistungsrechner

Erste Erfahrungen mit der Hitachi SR8000-F1

Seit April 2000 betreibt das Leibniz-Rechenzentrum den neuen Höchstleistungsrechner SR8000-F1 der Firma Hitachi. Dieser Rechner, der eine Spitzenrechenleistung von 1.33 TeraFlop/s (1.330.000.000.000 Rechenoperationen pro Sekunde) hat, steht für wissenschaftliche Projekte aus ganz Deutschland mit besonders hohem Ressourcenbedarf zur Verfügung. In diesem Beitrag soll ein Überblick über die ersten Erfahrungen mit der Maschine aus Sicht des LRZ gegeben werden.

Benutzerprojekte und Auslastung

Es sind bislang 58 Projektanträge aus ganz Deutschland am LRZ eingegangen. Für das erste Betriebsjahr ergäbe das eine Überbuchung der Prozessorkapazität um fast das Dreifache. Von diesen Projekten sind bereits 34 durch das Gutachtergremium genehmigt, allerdings zum Teil mit Einschränkungen bezüglich der beantragten Ressourcen. Doch selbst diese 34 Projekte beantragen im ersten Jahr 103% mehr Rechenzeit als verfügbar sein wird. 16 weitere Projekte im Umfang von 1.3% der CPU-Gesamtkapazität sind durch das LRZ für Entwicklung von Tools, für Benchmarking sowie zu Ausbildungszwecken vergeben worden.

Das erste Bild zeigt zunächst die CPU-Auslastung auf dem parallelen Pool (96 Knoten) seit Anfang September 2000. Die Systemzeit-Anteile (mit %sys bezeichnete Kurve) sind vernachlässigbar, nur für den 10.9. ist auf dem zweiten Bild überhaupt ein kleiner Beitrag zu sehen:

Die SR8000 ist also über weite Strecken schon gut, aber nicht vollständig ausgelastet (die Verbrauchsabrechnungen zeigen seit Juli 2000 eine bei 75% liegende Nutzung des parallelen Pools); entsprechend gibt es im Moment (noch) kaum Wartezeiten für Batch-Jobs. Von dem großen Hauptspeicher (6 GByte pro Knoten für Benutzerprozesse) wird im Mittel ein Drittel genutzt.

Das nächste Bild zeigt die Gesamtrechenleistung des parallelen Pools, ebenfalls für September 2000.

 

Betriebs- und Ausfallzeiten der SR8000 von Mai bis September 2000:
	Benutzerbetrieb	Softwarefehler	Hardwarefehler an Prozessoren, Hauptspeicher, Verbindungsnetz	Hardwarefehler an Platten	Störungen wegen Elektroversorgung und Kühlung
Zeit	3513 h 47 min	66 h 54 min	34 h 13 min	23 h 30 min	33 h 36 min
%	95.69	1.82	0.93	0.64	0.92

Bei voller paralleler Partition der Maschine erreichen die derzeit laufenden Programme zusammen bis zu 220 GFlop/s Rechenleistung (untere Kurve), das entspricht einer Effizienz von 20%. Das LRZ hofft, dass weitere Bemühungen bei der Programm-Optimierung längerfristig zu einer Steigerung dieses Wertes auf 25-30% führen. Eine Grundlage hierfür soll auch ein vom LRZ herausgegebenes ergänzendes Optimierungshandbuch sein, welches auf dem LRZ-Webserver unter

(als Pre-Release) verfügbar ist. Die meisten auf der Hitachi laufenden Programme machen in großem Umfang von der Bandbreite zum Hauptspeicher Gebrauch und können daher nicht mehr als maximal etwa ein Drittel der Höchstrechenleistung erzielen (siehe hierzu auch den Beitrag über "Neuere Entwicklungen bei Mikroprozessoren" in diesem Rundschreiben).

Software-Infrastruktur

Neben den von Hitachi gelieferten Compilern gibt es weitere kommerzielle Werkzeuge zur Fehlerbehebung und Optimierung von Programmen, deren Portierung auf die SR8000 allerdings Zeit braucht. Bereits installiert ist das VAMPIR-Programmpaket der Firma Pallas, welches die Untersuchung von MPI-parallelen Programmen auf Fehler und Engpässe in der Kommunikation zwischen den Knoten wesentlich erleichtert. Hingegen ist der Totalview-Debugger für die Fehlersuche in (parallelen oder sequentiellen) Programmen noch nicht fertig gestellt, soll aber innerhalb der nächsten Wochen verfügbar sein. Längerfristig wünschenswert wären (im Sinne der Portabilität) vielleicht auch noch Werkzeuge zur automatischen Erstellung von OpenMP-parallelen Programmen, wie sie etwa von der Firma Kuck & Associates verkauft werden. Angesichts der Kosten für eine Implementierung wird das LRZ eine Anschaffung wohl erst auf intensiven Benutzerwunsch hin in Erwägung ziehen. Schließlich werden gegenwärtig Möglichkeiten untersucht, mit MPI parallelisierte Anwendungen über mehrere Rechner gekoppelt laufen zu lassen, also z. B. die SR8000 als Hintergrundrechner für eine in Echtzeit auf einer holografischen Visualisierungsstation laufenden Anwendung einzusetzen.

Betriebssituation

Die SR8000-F1 hat in den ersten Wochen des Betriebes vertragsgemäß eine Verfügbarkeit im Tagesbetrieb von mehr als 99% erreicht. Mit solchen Idealzahlen kann man natürlich im 24-Stunden-Betrieb nicht aufwarten (siehe Tabelle).

Im Wesentlichen kann man in den ersten Betriebsmonaten drei große Problemklassen identifizieren, die die Verfügbarkeit der Maschine reduziert haben:

1. Stromversorgung und Kühlung. Mit der Aufstellung der SR8000 musste auch die Elektro- und Kälteversorgung des LRZ wesentlich erweitert werden. Derzeit verbraucht die SR8000 etwas über 400 kW, im Endausbau werden es über 600 kW sein, die im Rechnerraum als Warmluft anfallen und rückgekühlt werden müssen: Ein Anstieg der internen Temperatur der Maschine über 55 °C führt zur Betriebsunterbrechung, d. h. schon ein partieller Ausfall der Kühlsysteme legt mit großer Wahrscheinlichkeit die gesamte SR8000 lahm. Zwar ist das ganze System durch eine neue unterbrechungsfreie Stromversorgung gegen kurzzeitige Spannungsinstabilitäten gesichert, doch haben sich leider noch einige Anlaufschwierigkeiten der neuen Anlagen in den ersten Betriebsmonaten ergeben, von denen wir hoffen, dass sie jetzt überwunden sind.
2. Hardware. Erfahrungsgemäß fallen in den ersten Betriebsmonaten häufiger Einzelteile aus als später. Zu nennen sind hauptsächlich Speichermodule, dann Prozessoren und Festplatten-Kontrolleinheiten. Defekte an Festplatten selbst sind unproblematisch, da hier eine Ausfallsicherung durch RAID ("Redundant Array of Independent Disks") im Normalfall die Fortsetzung des Betriebes erlaubt.
3. Software. Fehler in der Betriebssystem-Software führen ebenfalls noch gelegentlich zu Ausfällen, die allerdings normalerweise kurz dauern, da in vielen Fällen ein Neustart des Rechners innerhalb von 20 Minuten den Normalbetrieb wieder herstellt. Darüber hinaus reagiert die Firma Hitachi dankenswerterweise sehr schnell mit der Einspielung von Fehlerbereinigungen. Weniger gut quantifizierbar, aber für die Benutzer sicher stärker belastend sind Fehler der Compiler sowie wichtiger Systembibliotheken (etwa der für den Informationsaustausch zwischen den Rechenknoten), weil diese in der Regel den betroffenen Programmentwickler so lange behindern, bis eine fehlerbereinigte Version verfügbar ist. Das HPC-Team des LRZ ist hier bemüht, auf Software-Fehlern beruhende Probleme der Benutzerprogramme zu identifizieren (auf dem Hintergrund von solchen, die auf Programmierfehlern oder Fehlinterpretationen beruhen) und an Hitachi weiterzuleiten. Für die gravierendsten Probleme sind meist schon nach 2 Wochen Fehlerbehebungen verfügbar.

Insgesamt kann man sagen, dass sich die Ausfallzeiten im Rahmen des für einen so komplexen Rechner Erwarteten halten und sich die Situation sicherlich im Laufe der Zeit bessern wird.

Neben echten Ausfällen gibt es jedoch auch Behinderungen des Benutzerbetriebs, die erst längerfristig durch "Tuning" der Maschine und Verbesserungen am Betriebssystem und an Einzelkomponenten behoben werden können:

• Überraschend war das Auftreten von Engpässen bei der Netzwerkverbindung: Vermutlich aufgrund von Inkompatibilitäten der Netzwerk-Software verschiedener Hersteller für den sog. HiPPI-Adapter ("High Performance Parallel Interface") bekommt man im Moment nur etwa ein Zehntel der theoretisch verfügbaren Bandbreite. An der Behebung des Problems wird intensiv gearbeitet wobei ggf. der HiPPI-Anschluss durch einen Gigabit-Ethernet-Anschluss ersetzt wird.
• Lästig sind die (für einen Hochleistungsrechner im Übrigen nicht untypischen) langen Antwortzeiten beim interaktiven Arbeiten, die auf Ineffizienzen bei der Realisierung des Single System Image von HI-UX/MPP zurückzuführen sind. Das LRZ hofft hier mittelfristig auf von Hitachi zugesagte Verbesserungen in der Betriebssystem-Software.
• Durch eine Unkonfiguration der pseudo-temporären Dateisysteme Anfang September 2000 wurde versucht, den Benutzern verbesserte Auswahl-Möglichkeiten zur Verfügung zu stellen: Ein 8-fach block-striped Dateisystem /ptmp1, das für große Dateien (Blockgröße deutlich mehr als 64 kByte) eine I/O-Performance von bis zu 160 MByte/s zulässt, sowie ein file-striped Dateisystem /ptmp2, das für den gleichzeitigen Zugriff auf viele kleine Dateien (mit jeweils bis zu 20 MByte/s) geeignet ist.

Fazit

Die Hitachi SR8000 zeigt sich mit kleinen Abstrichen den Anforderungen des Alltagsbetriebes gewachsen; dies ist neben den schnellen Reaktionen des Hitachi-Personals auch den Operateuren des LRZ zu verdanken, die nachts und an den Wochenenden alle Rechner und die gesamte Infrastruktur des LRZ betreuen.

Reinhold Bader (Bader@lrz.de)
Horst-D. Steinhöfer (Steinhoefer@lrz.de)
Matthias Brehm (Brehm@lrz.de)

Neuere Entwicklungen bei Mikroprozessoren

Wie im Rundschreiben vom März dieses Jahres bereits angekündigt, steht demnächst die Migration vom inzwischen veralteten IBM SP2 auf Systeme mit deutlich leistungsfähigeren Prozessoren an. Dies soll zum Anlass dienen, eine Reihe aktueller Prozessor-Generationen ein wenig genauer unter die Lupe zu nehmen. Zum einen dient eine solche Untersuchung natürlich als Grundlage für eine Kauf-Entscheidung, andererseits – und deshalb diese Veröffentlichung unserer Resultate ­ hängt aufgrund der wachsenden Komplexität der Computersysteme (das gilt zunehmend auch für PCs) die zu erzielende Rechenleistung sehr stark von der Art ab, wie eine Anwendung programmiert ist. Dieser Beitrag soll demnach auch einige Hinweise darauf liefern, was man aus den einzelnen Systemen tatsächlich an Rechenleistung herausholen kann; diese Leistungszahlen sprechen oft eine ganz andere Sprache als die Werbebroschüren der Hersteller.

Untersuchte Systeme und Messverfahren

Mehrere Prozessor-Architekturen wurden untersucht (siehe Tabelle):

Bezeichnung:	Jahrgang:	Hersteller:	Taktfrequenz:	SMP:	Spitzenrechen- leistung pro CPU:	Betriebsumgebung:
Alpha EV6	1998	Compaq	500 MHz	1	1000 MFlops	Digital UNIX
Pentium III (Katmai)	1998	Intel	500 MHz	2	500 MFlops	Linux
Pentium III (Coppermine)	1999	Intel	800 MHz	2	800 MFlops	Linux
Xeon Cascades	1999	Intel	700 MHz	4	700 MFlops	Linux
R12000	1998	SGI	300 MHz	4	600 MFlops	IRIX
PPC+1	1999	Hitachi	375 MHz	8	1500 MFlops	HI-UX

¹ PCC+ steht hier und im Folgenden für den PowerPC-ähnlichen Prozessor, der von Hitachi in der SR8000 eingesetzt wird

Wir haben an dieser Stelle neben ganz "normalen" Workstation- und PC-Prozessoren auch den Prozessor des am LRZ betriebenen Höchstleistungsrechners Hitachi SR8000-F1 betrachtet, um darzustellen, wie sich auf der Ebene des einzelnen Prozessors ein Superrechner von einer normalen Workstation oder einem leistungsfähigen PC unterscheidet. Die Spalte SMP ("Symmetrisches Multi-Processing") gibt an, wie viele Prozessoren gleichzeitig an der Abarbeitung eines Einzelprogramms beteiligt sein können, ohne dass der Programmierer an seinem Code (wesentliche) Änderungen vornehmen muss. In dieser Liste fehlen natürlich einige wichtige Hersteller, für deren aktuelle Produkte noch kein Datenmaterial verfügbar war.

Zur Vermessung dient ein ganz einfaches Testprogramm, dessen Fortran-Code wie folgt aussieht:

DO I=1,N
A(I) = B(I) + C(I)*D(I)
END DO

In jeder Schleifen-Iteration werden also 3 Worte (zu je 8 Bytes) geladen, zwei Gleitkomma-Operationen ausgeführt, und das Resultat wieder geschrieben. Die Ausführungszeit für diese Schleifen wird als Funktion der Schleifenlänge N gemessen; daraus kann man dann die Rechenleistung in MFlops (Millionen Gleitkommaoperationen pro Sekunde) berechnen. Man bezeichnet eine solche Struktur als Triaden-Vektorschleife.

Datenhunger moderner Prozessoren

Die in der obigen Tabelle angegebenen Spitzenrechenleistungen für die Prozessoren erscheinen recht eindrucksvoll. Tatsächlich können alle Systeme pro Prozessortakt eine oder manchmal sogar mehrere Gleitkomma-Operationen ausführen, allerdings: falls die zu verknüpfenden Worte nicht schon in den Registern des Prozessors gespeichert sind, muss dieser sie erst anfordern. Woher? Hier gibt es mehrere Alternativen, von denen die relevantesten aufgezählt seien:

• Auf dem Prozessor selbst sind eine oder mehrere Hierarchie-Stufen an Zwischenspeicher (die so genannten first- und second-level Caches) verfügbar, die zwar schnell getaktet sind, aber die gewünschten Daten meist nicht so schnell anliefern können, wie sie der Prozessorkern anfordert. Ein solches Verhalten tritt insbesondere in naturwissenschaftlichen und technischen Applikationen häufig auf – erwünscht wäre hier eine größere Bandbreite.
• Wenn die angeforderte Datenmenge die Cache-Größe übersteigt, bleibt nur noch der Zugriff auf den deutlich langsamer getakteten Hauptspeicher.

Besonders relevant ist die Speicherbandbreite für Applikationen im naturwissenschaftlich-technischen Bereich, wo man z. B. zur Verbesserung der Qualität einer Simulation wachsende Datendurchsätze zu bewältigen hat. Sehen wir uns also die Leistungskurven für die verschiedenen Prozessoren an (siehe Grafik):

Prozessor:	Level 1 Cache (kB):	Level 2 Cache (kB):
Alpha	64	4096
Pentium II	16	512
Pentium III	16	256
Cascades	16	2048
R12000	32	8192
PPC+	128	­

Bei allen Prozessoren beobachtet man ab der Vektorlänge, ab der Zugriffe ausschließlich auf den Hauptspeicher erforderlich werden, einen erheblichen Einbruch der Performance, aber das Aussehen für kleine Vektorlängen ist recht differenziert. Zum besseren Verständnis enthält die zweite Tabelle die Cache-Eigenschaften der verschiedenen Systeme.

Der erste steile Abfall bei N» 600 für die Intel-Prozessoren wird also durch den Überlauf des relativ kleinen first-level Cache verursacht, während der Hitachi-Prozessor bis N» 6000 durchhält. Die sehr große Bandbreite des Hitachi-Prozessors zum Hauptspeicher sorgt dann – im Zusammenspiel mit speziellen Prozessor-Instruktionen sowie einem Fortran-Compiler, der diese ausnützen kann – dafür, dass das Leistungsniveau für beliebig lange Vektoren trotz fehlendem Level-2 Cache so hoch bleibt, wie es die anderen Hersteller bestenfalls bei Verwendung des Cache-Speichers erreichen. Auch der Alpha-21264 (EV6) profitiert von seinem relativ großen first level Cache, scheint jedoch die 4 MB second level Cache nicht voll ausnutzen zu können, da die Rechenleistung schon vorher allmählich auf das durch die Hauptspeicherbandbreite gegebene Limit einbricht. Im Falle des R12000 erreicht man durch den sehr großen second-level Cache über einen sehr weiten Bereich der Schleifenlänge N (man beachte die logarithmische Darstellung!) halbwegs ordentliche Rechenleistung. Die Entwicklung zu großem Level-2 Cache war notwendig, weil einerseits sehr viele gängige Applikationen sich in diesem Bereich momentan benötigter Speicheranforderungen bewegen, zum anderen sich die Geschwindigkeit der Prozessoren in den vergangenen zwei Jahrzehnten wesentlich schneller erhöhen ließ als die der Speichersysteme (jedenfalls zu einem für die Käufer annehmbaren Preis). Wie man am Cascades-Prozessor sieht, kann sich auch die Firma Intel diesem Argument nicht entziehen, allerdings sind Systeme, die solche Prozessoren enthalten, um mehr als eine Größenordnung teurer als ein Billig-PC. Es sei im Übrigen bemerkt, dass der Leistungseinbruch der Intel-Prozessoren bei Verlassen des first level Cache sehr wahrscheinlich auf einen Mangel der Compiler-Software zurückgeht:

Nach Schönauer [1] sollte man zwischen first und second Level Cache beim Pentium III nur 25% Leistungsverlust sehen, tatsächlich geht jedoch die Rechenleistung auf etwa die Hälfte zurück. Die angegebene Spitzenrechenleistung kann von keinem Kandidaten auch nur annähernd erreicht werden, da hier die tatsächlich erreichbare Rechenleistung durch die Speicherbandbreite zum first-level Cache limitiert ist (die Schleife ist "mager"). Das Missverhältnis wird umso schlimmer, je mehr Rechenwerke auf dem Prozessor verfügbar sind. Unser Beispiel ist hier sehr streng gewählt worden, um den Einfluss der Speicherhierarchie im schlimmsten Fall zu untersuchen, in der Praxis sieht es aber durchaus nicht viel besser aus: Viele Applikationen können nur wenige Prozent der Spitzenleistung eines Prozessors auch tatsächlich nutzen. Teilweise liegt das auch daran, dass bei der Programmierung nicht ausreichend auf die Eigenheiten eines speziellen Systems geachtet werden kann, auf dem die Anwendung dann läuft.

Symmetrisches Multi-Processing (SMP) und Skalierbarkeit

Betrachten wir nun die Fälle, in denen man mehr als einen Prozessor simultan für sich arbeiten lassen will. Die Erwartung ist, dass zwei Prozessoren für dieselbe Aufgabe nur halb so lange brauchen wie einer usw., aber in der Praxis erreicht man eine solche ideale Skalierung natürlich nicht. Das Bild zeigt die Rechenleistung pro Prozessor für die untersuchten Systeme; für ein gegebenes System wären die Kurven zu verschiedenen Prozessorzahlen also deckungsgleich, wenn ideale Skalierung vorläge.

Im Falle des PPC+-Prozessors stellt man zunächst für kurze Schleifenlänge schlechte Skalierungseigenschaften fest. Das liegt daran, dass für kurze Schleifen die bei der parallelen Abarbeitung erforderliche Initialisierung durch das Betriebssystem mehr Zeit benötigt als die eigentliche Rechenarbeit selber; mit wachsender Schleifenlänge verschwindet dieser Effekt natürlich, und man erreicht bezogen auf das Maximum der Rechenleistung etwa 90% Skalierbarkeit: Für die sequentielle Abarbeitung etwa 420 MFlops, für die parallele 380 MFlops. Der Performance-Einbruch erfolgt im parallelen Fall erst bei N» 50000, weil ja jetzt die Caches jedes Prozessors kumulativ zur Verfügung stehen. SMP bietet in diesem Bereich also eine weitere Lösung für das Speicher-Bandbreiten-Problem. Voraussetzung ist allerdings, dass die Applikation effizient parallelisierbar ist; die Triadenschleife erfüllt diese Voraussetzung (bei hinreichend großer Schleifenlänge) ohne weiteres Zutun des Programmierers. Noch stärker ausgeprägt ist der Initialisierungseffekt auf der SGI-Plattform (R12000): Hier werden die sog. Threads, die parallel auf den einzelnen Prozessoren laufen, dynamisch generiert, was einige 10000 Prozessorzyklen Zeit kostet, im Gegensatz zu Hitachis statischen Threads, wo bei der Initialisierung nur die Startadressen der Schleifen zu verteilen sind (ca. 840 Prozessorzyklen). Aufgrund des enorm großen Caches, den jeder Prozessor hat, bekommt man aber auch hier ein großes Fenster mit gut skalierender Performance. Am effizientesten erfolgt die Initialisierung der parallelen Schleifen auf der Intel-Plattform, weil die Linux-Betriebsumgebung von vornherein die dynamische Generierung von neuen Tasks sehr schnell ausführen kann. Auch hier spielt also die Qualität der Software (Betriebssystem und Compiler) eine erhebliche Rolle. Hingegen ist für Zugriffe aus dem Hauptspeicher die Hitachi die einzige skalierende Plattform; bei allen anderen Systemen müssen sich die Prozessoren die vorhandene Bandbreite teilen, sodass die Gesamtrechenleistung sich mit zunehmender Prozessorzahl nicht mehr erhöht.

Vorläufiges Fazit

Generell kann man als Fazit ziehen, dass die hier untersuchten Prozessoren einzeln betrachtet in ihrer Rechenleistung nicht Welten voneinander weg liegen. Das Geheimnis eines schnell laufenden Systems besteht in der Art, wie die Umgebung der Prozessoren entworfen wird, insbesondere also die Bandbreite zur Speicher-Hierarchie. Hier kann der Cascades-Prozessor der Firma Intel mit den etablierten Workstation-Herstellern durchaus mithalten. Ob das zukunftsträchtige Konzept, das Hitachi mit dem SR8000-Prozessor realisiert hat, auch außerhalb des Höchstleistungsrechnens kostengünstig eingesetzt werden kann, ist noch unklar. Die Tatsache, dass dieses Konzept einen großen Teil der Optimierungsarbeit von der Hard- auf die Software abwälzt, stimmt jedoch optimistisch, dass die vorhandene Lücke zwischen Allerwelts-Rechnern und Supercomputern auf diesem Weg verkleinert werden kann.

Referenzen:

[1] Willi Schönauer: Addendum to Scientific Supercomputing. Siehe die URL

http://www.uni-karlsruhe.de/Uni/RZ/Personen/rz03/addendum/

Reinhold Bader
Bader@lrz.de

Anhang

Aktuelle Landes-, Campus- und Sammellizenzen am LRZ

Zurzeit können mehrere Software-Produkte für Zwecke der Lehre und Forschung zu günstigen Bedingungen über das LRZ bezogen werden.

Dieser Anhang enthält sowohl eine Kurzbeschreibung dieser Programme als auch eine Übersichtstabelle, die deren Verfügbarkeit an verschiedenen Plattformen zusammenfasst. Landeslizenzen sind gesondert gekennzeichnet. Umfangreiche Produktsammlungen sind kursiv dargestellt.

Weitere Einzelheiten sind unter

http://www.lrz-muenchen.de/services/swbezug/lizenzen

zu finden.

			Plattformen
Produkt		Landes-Lizenz?	Personal-Computer	Unix- Systeme
3D Studio MAX	3D-Animationssoftware der Firma Autodesk		Win 95 Win NT
Adobe	Verschiedene Software-Produkte der Firma Adobe		Win Mac	nur einige Produkte für verschiedene Unix-Systeme
AIT	Cray-Workstation-Verbindungswerkzeuge	Ja		SunOS 4.1 Irix 3.3 + Ultrix 4.1
AFS	verteiltes Dateisystem			X
AMD	Autodesk Mechanical Desktop Zusatzpaket zu AutoCAD für die 3D- Konstruktion im Anwendungsbereich Maschinenbau		Win 95 Win NT
AutoCAD	2D-/3D-Computer-Aided-Design-System der Firma Autodesk Release 13 oder 14		DOS Win	Solaris (nur Rel.13) HP-UX AIX Irix
AVS	Visualisierungssystem	Ja	Win	X
BSD/386	Unix-Implementierung für PC		PC ab 386
CCSP	Anwender- und System-Software der Firma Compaq			Versch. ehem. DEC-Betriebs-Systeme
Corel	Verschiedene Softwarepakete der Firma Corel Word Perfect Suite u.a.		DOS Win Mac	Gängige Unix-Plattformen
ERDAS	Rasterbildsoftware		Win	X
ESRI	Geographische Informationssysteme		Win	X
FTN90	Fortran-90-Compiler der Firmen NAG und Salford		DOS Win Linux
FuLP	Verschiedene Softwareprodukte der Firma Inprise (vormals Borland)	Ja	Win DOS
HP-Software	Compiler und weitere System-Software der Firma HP			HP-UX 10.x /11.x
IBM-Software	Compiler und weitere Software der Firma IBM			AIX
IDL	Grafik- und Bildverarbeitung		Win Linux Mac	X
KHOROS	Visualisierungssystem	Ja		X
Lars	Archivierungs- und Recherche-System (Bezug über ASKnet)		DOS Win
LRZ-Grafik	Grafikpaket	Ja	DOS	X
Maple	Computer-Algebra-System		Win Mac Linux	X
Mathematica	Computer-Algebra-System		Win Mac Linux	X
Micrografx	Verschiedene Produkte aus dem Bereich Grafik	Ja	Win
MLA	Netware und weitere Produkte der Firma Novell		X
NAG	Fortran-Unterprogrammbibliothek	Ja	DOS Win	X
OnNet	TCP/IP für PCs (Bezug über ASKnet)		Win
OnNet32	TCP/IP für PCs (Bezug über ASKnet)		Win
OSF/DCE	Verteilte Anwendungen			X
OSF/Motif	Toolkit für Window System X11			X
PC/TCP	TCP/IP für PCs (Bezug über ASKnet)		DOS Win
PC-TeX	Textsatzsystem TeX (incl. LaTeX)		Win
Pro/Engineer	CAD/CAM-3D-Modellierer für den Bereich Maschinenbau	Ja	Win	X
SAS	Statistik-Programmsystem		Win 95/98 Win NT Win 2000
ScholarPAC	Software und Betriebssystem-Wartung von Sun Microsystems GmbH		X 86 (Solaris für PC)	Solaris
Scientific Word	Textverarbeitungsprogramm, das intern LaTeX benutzt		Win
Select	Microsoft-Software aus den Bereichen Anwender-, System- und Server-Software		DOS Win Mac
Softbench	CASE-Tool			HP-UX SunOS 4.1.x Solaris 2.x
Sophos Anti-Virus Toolkit	Software zum Schutz gegen Computerviren	Ja	DOS Win OS/2 Mac Netware	X
SPSS	Statistik-Programmsystem		Win Mac
SPSS Science	Statistik-Software-Pakete (AllClear, AMOS, DeltaGraph, Systat, SIGMAStat und weitere Produkte)		X
StarOffice	Office-Paket der Firma StarDivision		DOS Win Linux Mac OS/2	Solaris Irix
SYSTAT	Statistik-Programm		Win
Trumpet Winsock	TCP/IP für MS-Windows (mit PPP)		Win 3.X
TUSTEP	System von Textverarbeitungsprogrammen		DOS Win Linux
UniChem	Quantenchemieprogramm	Ja		Irix 3.3.1 + Irix 4.0.1 +
Varsity	Compiler und weitere Software der Firma SGI			Irix

X: auf allen gängigen Plattformen der jeweiligen Rubrik verfügbar
+: diese Systemversion oder höher
Kursiv gedruckt sind die Namen umfangreicher Produktsammlungen