Add section about binding

[gkaf89]

There is no description on how binding works. We should add a section.

Useful resources

1. Julic - Processor Affinity
2. Lumi - Distribution and binding options

[gkaf89]

This is from a chat I had with Dionysios STEFANITSIS on Teams. I will translate and adjust for the documentation. Basically, they noticed that it is better to run on 4 nodes and 32 cores per socket rather than on 2+1/2 nodes with 64 nodes per socket. They are core limited by their license.

The disparity is explained by the cache structure of Zen 2.

P.S.

They are also using: # echo 3 > /proc/sys/vm/drop_caches

---

Με 2 nodes έχεις 32 memory channels, ενώ με 4 nodes έχεις 64!

Γενικά η FEA καταλήγει να καλεί sparse matrix multiplication συναρτήσεις, κι αυτές οι συναρτήσεις είναι κατά βάση περιορισμένες από τη ταχύτητα προσπέλασης στη μνήμη. Με 4 nodes ουσιαστικά διπλασιάζεις το memory bandwidth.

1. Η θεωρία

Ο επεξεργαστής που έχουμε στον Aion:https://en.wikichip.org/wiki/amd/epyc/7h12

• έχει 2 memory channels ανά Non-Uniform Memory Access (NUMA) node
• 8 channels συνολικά ανά socket και κάθε node έχει 2 sockets
• έχουμε χωρίσει 1 NUMA node/virtual socket για 4 virtual socket ανά μηχάνημα ή 8 virtual socket ανά node

Γενικά 1 NUMA node = 1 memory controller με 2 memory channels ανά controller

Θα μπορούσαμε να έχουμε 2 virtual socket ανά μηχάνημα, δηλαδή 1 virtual socket ανά pshysical socket, με 4 NUMA nodes ανά virtual socket. Αλλά το MPI δουλεύει γρηγορότερα αν όλοι οι πυρήνες στο socket ανήκουν στο ίδιο NUMA node, οπότε σπάμε το physical socket σε 4 virtual sockets με 1 NUMA node το καθένα.

Γενικά, ο συγχρονισμός μνήμης αν έχεις να περάσεις από memory controller σε άλλο memory controller είναι αργός, γιατί οι momory controllers πρέπει να συγχρονίσουν όλα τα L3 caches που εμπλέκονται στον συγχρονισμό (8 στο σύνολο). Για το λειτουργικό όλη η μνήμη (8 NUMA nodes) εμφανίζεται ενιαία. Για MPI εφαρμογές χρησιμοποιούμε το πρόγραμμα hwloc ώστε να μην συγχρονίζουν μνήμη μεταξύ NUMA nodes για να αποφύγουμε τους αργούς συγχρονισμούς.

Δες λίγο το hwloc: https://hwloc.readthedocs.io/en/stable/

Με αυτές τις εντολές μπορείς να δεις πώς βλέπει το MPI ένα node:

module load system/hwloc 
lstopo

2. Τι αξίζει να δοκιμάσεις

Αν χρησιμοποιήσεις 128 processes ανά μηχάνημα έχεις 4 processes ανά L3 cache unit. Όταν έχεις 64 proceses ανά μηχάνημα δε ξέρεις πώς κατανέμονται ανά L3 cache unit! Μπορεί κάποια L3 cache units να πάρουν 4 processes κι άλλα κανένα. Ιδανικά θέλεις 2 ανά L3 cache unit.

Στο LUMI κάνουν πολύ δουλειά στο τομέα, και θα περάσουμε μερικά από αυτά στο documentation μας:https://lumi-supercomputer.github.io/LUMI-training-materials/2day-20240502/07_Binding/#further-material

Αξίζει να δοκιμάσεις ξανά 4 nodes με 64 processes/node, αλλά να θέσεις το binding ώστε να έχεις 2 processes ανά L3 cache unit. Πιστεύω θα υπάρξει διαφορά!

Αν υπάρχουν αρκετές άδειες, δοκίμασε και 4 nodes με 128 processes ανά node.

Διαφορετικά καλύτερα να δουλεύεις με 4 nodes με 64 processes. Ουσιαστικά καταναλώνεις περισσότερα corehours για να μειώσεις τη κατανάλωση licensehours. Έχουμε πολύ περισσότερα corehours από licensehours!

Να επικοινωνήσουμε από Τρίτη αν έχεις χρόνο.