Hochleistungsrechnen in Darmstadt: Der Lichtenberg- Hochleistungsrechner. Dr. Andreas Wolf. Gruppenleiter Hochleistungsrechnen Hochschulrechenzentrum

Transkript

1 Hochleistungsrechnen in Darmstadt: Der Lichtenberg- Hochleistungsrechner Dr. Andreas Wolf Gruppenleiter Hochleistungsrechnen Hochschulrechenzentrum

2 Überblick Randbedingungen der HPC Beschaffung an der TU Die Ausschreibung Was ist es geworden? Probleme 2

3 Randbedingungen der HPC- Beschaffung an der TU 3

4 Die TU Darmstadt braucht einen flexiblen Rechner Der neue Hochleistungsrechner dient der Verbesserung der Möglichkeiten der TU Darmstadt im wissenschaftlichen Wettbewerb. Die HPC-Anwendungsvielfalt an der TU ist groß. Codes, die auf dem TU HPC Rechner laufen, werden auch auf anderen Plattformen eingesetzt. Für die meisten unserer Nutzer ist die Programmierung Mittel zum Zweck, nicht Selbstzweck. 4

5 Die TU profitiert von architektonischer Vielfalt Mit der Beschaffung des Hochleistungsrechners der TU ein Systemkomplex ausgeschrieben, der durch architektonische Flexibilität den Anwendern die effiziente Nutzung von HPC Ressourcen erleichtert: 1. Cluster mit SMP Nodes 2. SMPs mit viel gemeinsamem Speicher 3. Beschleunigercluster mit NVIDIA GPU (wg. CUDA Programmierung) und Intel Xeon Phi (ehemals MIC). 5

6 Die Ausschreibung 6

7 Ziele der Ausschreibung Bis 2012 Power 5/6 Systeme Vorwiegend MPI Programme Rechenkerne (MPI Tasks) 2-4 GByte pro MPI-Task Eingeschränkter Nutzerkreis (auch wegen Softwarelimitierung) Neues System MPI-Programme mit 500 bis 2000 Tasks Neben Distributed-Memory auch Shared-Memory Unterstützung Besondere Applikationen mit Bedarf von 300 bis 1000 GByte Moderne und zukunftsträchtige Akzelerator-Unterstützung Linux 7

8 Nebenbedingungen zur Ausschreibung Administration Zuvor 2x Admins Großes System benötigt mehr Admin-Team wird vergrößert, muss aber auch erst noch Erfahrungen sammeln Ein wartungsarmes und stabiles System ist daher unbedingt notwendig Akzeleratoren Ein Teil muss CUDA programmierbar sein Wegen Zukunftsorientierung ansonsten möglichst flexibel und offen für alle Standards 8

9 Wartungsaufwand versus Komplexität des Systems Geringer Wartungsaufwand ist normalerweise ein Widerspruch zu dem Betreiben eines komplexen Systems. Wenn das System stabil und leicht wartbar ist, dann darf das System auch komplex sein. Deshalb Entscheidung für eine komplexes aber dafür flexibles System. Um so wichtiger wurde damit, dass es sich um ausgereifte und getestete Komponenten von Anbietern mit Erfahrung bei Projekten in dieser Größenordnung handelt. Rechenleistung durch Mindestanforderungen abgesichert, aber Raum für ausgereifte Komponenten, wenn auch zum höheren Preis 9

10 Fokus auf HPC-Anwendungen Erwartete Anwendungen Simulations-Anwendungen Bearbeitung großer Datenmengen (Bild oder Gitter- Verarbeitung) Aber auch Unterstützung kommerzieller wissenschaftlicher Produkte: z.b. Matlab und Ansys Was nicht passt wird passend gemacht Unterstützung der Nutzer bei Wahl der richtigen Plattform und der effizienten Programmierung (und Algorithmen) Kooperation mit Hessischem HPC Kompetenzzentrum -> Vortrag: Prof. C. Bischof morgen 10

11 Ausrichtung der Leistungsbeschreibung Bewertungskriterieren: Parallele Rechenleistung Speicherbandbreite Latenzprobleme müssen dann ggf. durch Code-Optimierung (Prefetching) ausgeglichen werden Auswahl der Leistungsbenchmarks Minimierung der Anzahl der Benchmark-Programme, und Einsatz von zusammenfassenden Benchmarks (z.b. SPEC MPI ausreichend komplex) Wichtig zur Vorhersagbarkeit der Leistung von zukünftiger Hardware (z.b. Prozessoren in 2014) Vermeidung von Systemen die nur auf sehr speziellen User- Code optimiert sind (Vorteil wenn einzige Anwendung) 11

12 Erfahrungen Ausschreibung trotzdem kompliziert wegen Zwei Phasen Wettbewerb: Offenheit für möglichst verschiedene Anbieter und Komponenten-Hersteller (z.b. AMD, Intel etc.) Erster Eindruck des gelieferten Systems Erste positive Erfahrungen in Hinblick auf die Rechenleistung der MPI-Knoten Für alles andere ist es noch zu früh 12

13 Was ist es geworden? 13

14 Infiniband Ethernet Installation Juni 2013 Phase I HOME MPI MEM ACC SCRATCH 704(+2) x MPI (inkl. 5x32 von Dez. 2012) 2 Prozessoren, Intel Sandybridge Je 8 Kerne mit 2,6 GHz 32 GByte (10% 64 GByte) 4 x MEM 8 Prozessoren, je 8 Kerne 1024 GByte (MAX5) 44+24(+2) x ACC 2 Prozessoren + 2 Akzeleratoren Nvidia Kepler Intel Xeon Phi (ehem. MIC) 32 GByte Platten Scratch: 768 TByte, 20 GB/s Home: 500 TByte, 5 GB/s Infiniband FDR-10 14

15 Infiniband Ethernet Installation Ende 2014 Phase II MPI MEM MPI MEM Zusätzliche MPI 2 Prozessoren Nachfolge Architektur 4 zusätzliche MEM 4 Prozessoren Nachfolge Architektur 1024 GByte ACC ACC Zusätzliche ACC 2 Prozessoren 2 Akzeleratoren Nachfolge Architektur HOME SCRATCH SCRATCH Platten Scratch: +768 TByte Summe 1,5 PByte Infiniband FDR 15

16 Offene Punkte Was sind die Nachfolge Architekturen Prozessoren: Haswell? Akzeleratoren: Nvidia oder Intel? Unser Ziel Nutzer sammeln Erfahrungen in Hinblick auf Programmierbarkeit und Leistung bei den Akzeleratoren Entscheidung für Nachfolge Architektur (Nvidia vs. Intel) Abwägung von Prozessoren zu Akzeleratoren z.b. 2x Prozessoren ~ 0,6-0,7 TFlops (Haswell) ~ 3-4 Knoten (1,8 2.8 TFlops) z.b. 1x Akzelerator ~ 1-1,3 TFlops (K20X) ~ 1 Knoten mit 2x Akzeleratoren (3-4 TFlops) 16

17 Probleme 17

18 Verzögerungen am Bau so sollte es aussehen 19

19 Verzögerungen am Bau so sieht es heute aus (Okt. 2013) 20

20 Der Dachkühler (Juni 2013) 26

21 Das Parkdeck (Okt. 2013) 28

22 Fragen? 31