Thomas Zeiser

Some comments by Thomas Zeiser about HPC@RRZE and other things

Content

Remotevisualisierung mit VirtualGL

Das RRZE hat seit Ende 2009 acht Rechenknoten mit jeweils zwei NVIDIA Tesla M1060 Grafikkarten (baugleich zur C1060 jedoch rein passiv gekühlt) und DDR-Infiniband-Vernetzung: TinyGPU-Cluster

Diese Rechner können nicht nur als Rechenknechte (via CUDA oder OpenCL) genutzt werden, sondern auch zur Remote-Visualisierung mittels VirtualGL). Das LRZ betreibt zum gleichen Zweck bereits seit längerer Zeit einige leistungsfähige Systeme: LRZ-Dienst Visualisierung

Das GPU-Cluster am RRZE ist als experimentelles Forschungscluster ausgelegt. Daher ist, sowohl was CUDA/OpenCL als auch die Remote-Visualisierung betrifft, stets mit Änderungen zu rechnen, insbesondere da derzeit die Umstellung von CUDA-Tookit 2.3 auf Version 3.0 ansteht, was mit einem Upgrade des NVIDIA-Kernel-Treibers verbunden ist. (Update August 2010: inzwischen läuft sogar schon 3.1)

Um VirtualGL nutzen zu können, muss auf dem lokalen Rechner entweder VirtualGL (inkl. TurboJPEG oder libjpeg-turbo) oder aber TurboVNC (oder TigerVNC) installiert sein. Wenn dann eine Remote-Visualisierung ansteht, besorgt man sich auf TinyGPU am besten einen interaktiven Batchjob (ggf. auf einem bestimmten Knoten, da VirtualGL derzeit nicht auf allen Knoten installiert ist). Während der Batchjob läuft, kann man sich auf dem entsprechenden Knoten auch direkt per SSH einloggen. Sofern man VirtualGL nativ verwendet (bietet sich von Linux-Clients aus an), so verwendet man ein vglconnect -s kennung@tgXXX um auf den reservierten Knoten zu kommen. Dort kann man dann die Grafik-intensive Applikation mit vglrun ./a.out starten. (Für STAR-CCM+ muss vglrun -nodl starccm+ verwendet werden, wenn STAR-CCM+ im parallelen Modus laufen soll.) Wie man die beide GPUs via VirtualGL sinnvoll nutzen kann, ist derzeit noch unklar.

Bezüglich der aktuellen Konfiguration und weiterer Nutzungshinweise wenden Sie sich bitte an die HPC-Gruppe.

Seit 19. Juli 2010 muss die Eigenschaft virtualgl explizit von den Jobs angefordert werden, damit beim Jobstart ein X-Server gestartet wird.

Defaults or special options of different MPI implementations to remember

More and more MPI implementations try to scope with the increasing complexity of modern cluster nodes. However, sometimes these automatic defaults are counterproductive when trying to pinpoint special effects …

Things to remember:

  • Open MPI:
  • Mvapich2:
    • recent version of mvapich2 default to MV2_ENABLE_AFFINITY=1 which enables internal pinning and overwrites any taskset given on the command line. Either use MV2_CPU_MAPPING (containing colon-separated CPU numbers) to make the correct pinning or set MV2_ENABLE_AFFINITY=0 and do external pinning. RRZE’s mpirun wrapper (as of Feb. 2010) disables the internal mvapich2 affinity routines to make our -pin argument work (again).
    • pinning of hybrid codes (mvapich2 + OpenMP) using RRZE’s pin_omp: PINOMP_SKIP=1,2 (cf. http://www.blogs.uni-erlangen.de/JohannesHabich/stories/3414/#4721)
      The resulting command line can be rather length: e.g. env PINOMP_SKIP=1,2 OMP_NUM_THREADS=4 KMP_AFFINITY=disabled mpirun -npernode 2 -pin 0,1,2,3_4,5,6,7 env LD_PRELOAD=/apps/rrze/lib/ptoverride-ubuntu64.so ./a.out
  • Intel MPI:
    • starting large jobs over Infiniband: using the socket connection manager (SCM) instead of the default connection manager (CMA) might improve the start-up sequence. One might try env I_MPI_DEVICE=rdssm:OpenIB-mthca0-1 on Woody and TinyGPU, env I_MPI_DEVICE=rdssm:ofa-v2-mthca0-1 on Townsend or I_MPI_DEVICE=rdssm:OpenIB-mlx4_0-1 on TinyBlue or TinyFat.
      (The newer syntax to use together with I_MPI_FABRICS is I_MPI_DAPL_PROVIDER or I_MPI_DAPL_UD_PROVIDER.)
      Thanks to Intel for pointing out this OFED/Intel-MPI option. Unfortunately, there is only very little OFED documentation on the differences between CMA and SCM: http://www.openfabrics.org/downloads/dapl/documentation/uDAPL_release_notes.txt (Release notes from December 2009 for OFED-1.5).
      UCM might be even more scalable; use I_MPI_DAPL_UD=enable I_MPI_FABRICS=shm:dapl. — on Townsend, Woody and Tiny{Blue,FAT,GPU} UCM is available if the experimental “dapl” moule is loaded before any Intel MPI module.
    • bug (at least) in Intel MPI 3.1.0.038: connections to MPD daemons may fail if $TMPDIR is set to something different than /tmp
    • bug in Intel MPI 4.0.0.025: Intel’s mpirun as shortcut for mpdboot - mpiexec - mpdallexit cannot read properly from STDIN; the problem is the newly with this release introduced sequence of mpiexec "$@" & wait $! instead of the traditional mpiexec "$@". RRZE’s PBS-based mpirun is not affected by this problem.
    • incompatibilities between RRZE’s PBS-based mpirun (i.e. Pete Wyckoff’s mpiexec) and I_MPI_DEVICE=rdssm: from time to time we observe that processes hang either during startup (at MPI_Init or at the first larger scale communication) or even more often at MPI_Finalize. I_MPI_DEVICE=rdma usually does not have these problems but is noticeable slower for certain applications. As the behavior is non-deterministic, it’s hard/impossible to debug and as the PBS-based start mechanism is not supported by Intel we cannot file a problem report neither. And of course Intel’s extensions of the PMI startup protocol also not publically documented …
    • you have recent Qlogic Infiniband HCA? I_MPI_FABRICS=tmi I_MPI_TMI_PROVIDER=psm should be appropriate (PS: I_MPI_FABRICS is the replacement for I_MPI_DEVICE introduced with Intel-MPI 4.0)
  • HP-MPI:
    • The environment variable MPIRUN_OPTIONS can be used to pass special options to HP-MPI, e.g. "-v -prot" to be verbose and report the used interconnect; –"-TCP -netaddr 10.188.84.0/255.255.254.0" to force TCP and select a specific interface (e.g. for IPoIB).
    • HP-MPI has its own pinning mechanism; cf. page 16/17 of /apps/HP-MPI/latest/doc/hp-mpi.02.02.rn.pdf dor details; MPIRUN_OPTIONS="-cpu_bind=v,map_cpu:0,2,1,3" should be fine for regular jobs on Woody. If you require a lot of memory and would like to use only one MPI process per socket, the correct option should be MPIRUN_OPTIONS="-cpu_bind=v,map_cpu:0,1"
  • Parastation MPI as e.g. used on JUROPA of FZ-Jülich
    • Any pointer to pinning mechanisms for processes would highly be appreciated.
    • The latest versions (cf. psmgmt 5.0.32-0) have the environment variable __PSI_CPUMAP which can be set to individual cores or core ranges, e.g. "0,2,4,6,1,3,5,7" or "0-3,7-4".
  • to be continued

32-bit Intel compiler on 64-bit Ubuntu system

The 32-bit Intel compilers fail to produce 32-bit executables on a 64-bit Ubuntu (or Debian) system as they append (hardcoded) /usr/lib/crt?.o to the linkage command. On 64-bit Ubuntu or Debian systems, however, /usr/lib contains 64-bit code and 32-bit code is in /usr/lib32. The workaround is to prevent the compiler from using the standard startup files when linking and supplying the correct ones manually, i.e. -L/usr/lib32 -nostartfiles /usr/lib32/crt1.o /usr/lib32/crti.o /usr/lib32/crtn.o. As specifying these command line arguments is cumbersome, they can be written to some file and referenced using the ICCCFG, ICPCCFG or IFORTCFG environment variable. This is now done automatically on RRZE’s system via the Modules system. But of course it would be preferential if Intel could determine the correct directories and files itself – but probably, Debian/Ubuntu is not supported officially or nobody tries to create 32-bit code on a 64-bit system …

Win a notebook

KONWIHR and Intel just opened the call for a competition on the topic “Innovative Multi- and Many-Core Programming”. Notebooks and travel grants are awarded. Students and staff members of Bavarian Universities and Bavarian Universities of Applied Sciences are eligible to participate. Check http://www.konwihr.uni-erlangen.de/ and the official flyer for more details.

Arbeiten des RRZE auf dem Gebiet des Hochleistungsrechnens erneut mit dem “Golden Spike Award” ausgezeichnet

Für den Beitrag "Vector computers in a world of commodity clusters, massively parallel systems and many-core many-threaded CPUs: recent experience based on advanced lattice Boltzmann flow solvers", erhielt Thomas Zeiser vom Regionalen Rechenzentrum (RRZE) der Friedrich-Alexander-Universität Erlangen-Nürnberg nach 2004 dieses Jahr erneut einen Golden Spike. Dieser begehrte Preis wird jährlich anlässlich des Results and Review Workshops am Bundeshöchstleistungsrechenzentrum Stuttgart (HLRS) in Form eines goldenen Nagels an drei herausragende Arbeiten auf dem Gebiet des Höchstleistungsrechnens vergeben. In seinem Vortrag berichtete Thomas Zeiser über aktuelle Arbeiten der HPC-Gruppe des RRZE zur Analyse, Modellierung und Optimierung von Anwenderprogrammen auf neuesten Rechnerarchitekturen. Der Bereich HPC Services am RRZE wurde in den letzten zehn Jahren durch Mittel der FAU, des bayerischen Staatsministeriums für Wissenschaft, Forschung und Kunst und insbesondere des Kompetenznetzwerks für technisch-wissen­schaft­liches Höchstleistungsrechnen in Bayern (KONWIHR) an der Schnittstelle zwischen Anwender und Technik etabliert.

In seiner Laudatio hob Prof. Nagel vom Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH) der Technischen Universität Dresden in seiner Funktion als Vorsitzender des Lenkungsausschusses des Bundeshöchstleistungsrechenzentrum Stuttgart die überregionale Bedeutung und Sichtbarkeit der Beratungs- und Forschungsaktivitäten der Mitarbeiten des Bereichs HPC Services am RRZE hervor. Der diesjährige Beitrag von Thomas Zeiser für den Results and Review Workshop hat die Jury insbesondere durch die gelungene Kombination von Theorie und Anwendung in Form von detaillierten Studien diverser HPC-Systeme, ihrer optimierten Programmierung sowie die gezeigte strömungsmechanische Anwendung überzeugt. Die vorgestellten detaillierten Strömungssimulationen zur Entwicklung von neuartigen Katalysatorträgern auf der Basis von offenen Schwammstrukturen werden in Zusammenarbeit mit der Arbeitsgruppe von Prof. Schwieger am Lehrstuhl für Chemische Reaktionstechnik (CRT) der Friedrich-Alexander-Universität Erlangen-Nürnberg sowie Dr. Hannsjörg Freund vom Max-Planck-Institut für Dynamik komplexer technischer Systeme in Magdeburg interdisziplinär durchgeführt.

Sun Studio 12 and open-mpi

The Sun Studio has a long tradition and provides a lot of tools beyond just the compilers. It’s available free of charge not only for Solaris (Sparc and x86/x64) but also for Linux (x64). To give it a try, I just installed it on one of our systems. Unfortunately, Sun does not (yet) provide the Sun ClusterTools for Linux. Thus, I had to compile a MPI library by my own.

As we also do not have any experience with open-mpi either, I gave that at the same time a try. Unfortunately, open-mpi (1.2.3) requires some patching to get compiled with the Sun Studio 12 compilers (as documented in the open-mpi FAQ). But besides that there were no problems to get the PBS/torque TM-interface and Open Fabrics Infiniband included.

Next, how to run MPI programs from within batch jobs? We are used to Pete Wyckoff’s mpiexec which we extended with a quite powerful wrapper to allow pinning of processes (using PLPA), specification of round robin or block assignment of processes, partially filled nodes, etc.. Open-mpi comes with its own PBM TM-interface, thus, the next steps will be to figure out how all functionality can be provided with open-mpi’s mpirun. So far, I did not find an option to use nodes only partially. But at least there is --bynode and --byslot (default) and I quickly got some MPI PingPong numbers between nodes – the numbers look reasonable. …

A promising start for more explorations in the future.

If you are running with many MPI processes on large SMP systems, e.g. SUN’s Niagara2 systems, you might need to increase the “open files” limit significantly, e.g. by issuing ulimit -n 32768 otherwise the MPI startup may fail with messages like unable to create shared memory mapping.

Vector-TRIAD on woody using different versions of the Intel EM64T Fortran compiler

Switching from one compiler version to an other can have significant influence on performance, but even moving one patch level ahead may change your performance …

The Vector-TRIAD benchmark (a(:)=b(:)+c(:)*d(:) according to Schoenauer) was run on the new Woodcrest cluster at RRZE which consists of HP DL140G3 boxes. The performance is given in MFlop/s for a loop length of 8388608. The value is the aggregated bandwidth of 4 MPI processes running on the node in saturation mode.

SNOOP filter of the 5000X chipset enabled

Performance in MFlop/s for loop length 8388608
on 2-socket Woodcrest node with 4 MPI processes
compiler| default | USE_COMMON
--------+---------+-----------
9.1-033 | 374.0   | 352.5
9.1-039 | 374.1   | 352.3
9.1-045 | 359.0 ! | 352.4
10.0-13 | 373.4   | 377.6 !
10.0-17 | 373.7   | 352.0

SNOOP filter of the 5000X chipset disabled (switching the snoop filter off only works with the latest BIOS (v1.12) released on April 16!)

compiler| default | USE_COMMON
--------+---------+-----------
9.1-033 | 376     | 332
9.1-039 | 376     | 331
9.1-045 | 341  !! | 331
10.0-13 | 376     | 380 !!
10.0-17 | 376     | 331

The “default” version always refers to arrays which were known at compile time; “USE_COMMON” meaans that the arrays have additionally been put into a common block.

 

And for reference the STREAM values in MB/s for 4 OpenMP threads (and added NONTEMPORAL directives and Array size = 20000000, Offset = 0) are also given:

      Snoopfilter on | Snoopfilter off
Function Rate (MB/s) | Rate (MB/s)
Copy:      7492.0444 | 6178.7991
Scale:     7485.3591 | 6174.8763
Add:       6145.5004 | 6180.6296
Triad:     6152.6559 | 6189.2369

The results were more or less identical when using fce-9.1.039 and fce-9.1.45!

Reasons for performance differences: The main reason for the performance differences is unrolling (add -unroll0 to avoid it – thanks to Intel for pointing this out). The 10.0 compilers seem to be much more aggressive when doing optimizations and vectorization. By default, non-temporal stores may now be used in certain cases automatically by the 10.0 compiler. If you want to avoid that use -opt-streaming-stores never. Even if non-temporal stores were disabled via command line, the compiler directive vector nontemporal will still be respected. A directive to avoid non-temporal stores for a specific loop only is not (yet) available.

Erfahrungen mit Intel 10.0-beta Compilern

Intel hat vor kurzem den Beta-Test für die kommenden Intel 10.0 Compiler begonnen. Laut Release-Notes hat sich einiges geändert …

Hier die ersten eigenen Erfahrungen mit der Linux-Version (x86_64 sofern nichts anderes vermerkt):

  • -tpp wird jetzt nur noch auf IA64 unterstützt; insbesondere -tpp7 auf x86/x86_64 wird nciht mehr erkannt. Da “Pentium4” sowieso der Default ist, kann diese Option einfach weggelassen werden. Druch -mtune= können jetzt Tuning-Hinweise gegeben werden. Die -x bzw. -ax gibt es dagegen unverändert (wobei für neue Prozessoren weitere Buchstaben hinzugekommen sind).
    -xK == -march=pentium3 und -xW == -march=pentium4

Leben jenseits des RRZE

Viele “HPC-Aktivisten” sind zur Zeit auf der Supercomputing SC06 Konferenz in Tampa (Florida, USA) zu treffen. Aber auch in Erlangen tut sich in Sachen HPC jenseits des RRZE einiges. Am Lehrstuhl für Strömungsmechanik ist eine W2-Professur für Technisch-Wissenschaftliches Höchstleistungsrechnen in der Strömungsmechanik ausgeschrieben. Drei Kandidaten sind heute in Erlangen zum “Vorsingen” weitere drei folgen am Donnerstag. Vorsingen genau in der SC06-Woche wo eigentlich alles was Rang und Namen hat in Tampa ist?? Laut gut unterrichteten Kreisen soll es terminlich nicht anders möglich gewesen werden – mindestens einer der Bewerber musste daher vorzeitig aus den USA zurückkommen …

Zu den Kandidaten nur so viel: sie sind sehr unterschiedlich und es wird sehr darauf ankommen, was die Berufungskommision als Schwerpunkte bei der Ausrichtung der Stelle haben möchte – einen Mathematiker, einer Numeriker, einen Strömungsmechaniker, einen Computermann, oder … alles in einem Kandidaten zu finden wird schwierig werden.

  • Höchstleistungsrechnen — aber bis jetzt nur Erfahrung auf dem lokalen PC-Cluster?
  • Höchstleistungsrechnen — aber noch nie etwas von ccNUMA gehört?
  • Höchstleistungsrechnen — aber noch nie “Parallele Effizienz” gehört?
  • … bei anderen fehlt es dann dafür an den Tiefen der Strömungsmechanik
  • … und je 30 Minuten für den wissenschaftlichen Vortrag und die Lehrprobe halbwegs einhalten kann auch schwer sein

Naja, vielleicht bin ich ja doch zu sehr voreingenommen …