Δείκτες και MPI

[computeras13]

Καλησπέρα,

 

γράφω έναν κώδικα σε C ο οποίος δουλεύει μέσω MPI για κατανεμημένη επεξεργασία. Πέραν αυτού προσπαθώ να εκμεταλευτώ στο έπακρο τις δυνατότητες που μπορώ να έχω για να μειώσω τους χρόνους εκτέλεσης.

 

Είχα λοιπόν την παρακάτω ιδέα την οποία προσπαθώ να δω αν είναι υλοποιήσιμη. Αφόσον κάποιες διεργασίες τρέχουν στον ίδιο υπολογιστή αντί να τους στείλω το κομμάτι από έναν πίνακα που θα πρέπει να τις απασχολεί για παράδειγμα να στείλω μόνο ένα δείκτη για να έχουν άμεση πρόσβαση στην περιοχή μνήμης της "μαμάς" διεργασίας.

 

Απ'ότι είδα μέσω MPI δεν γίνεται να στείλεις απλά δείκτη (αντιγράφει όλη την περιοχή μνήμης) εκτός αν κάτι μου διαφεύγει.

 

Μια άλλη λογική θα ήταν να αναπαραστήσω τον δείκτη σε μια άλλη μορφή (ακέραιο, string κτλ), να τον στείλω και μετά να το μετατρέψω ξανά σε δείκτη. Δεν ξέρω όμως αν αυτό είναι σενάριο επιστημονικής φαντασίας ή αν γίνεται.

 

Αν ξέρει κανείς αν γίνεται να λειτουργήσει ένας από τους δύο αυτούς τρόπους θα εκτιμούσα να δώσει τα φώτα του

 

Ευχαριστώ, Γιώργος

[V.I.Smirnov]

Το σωστό είναι να χρησιμοποιηθεί μικτό πρότυπο :

οι κόμβοι επικοινωνούν και ανταλλάσουν δεδομένα με το MPI,

ενώ στον ίδιο κόμβο, εφόσον είναι multicore, χρησιμοποιείται το openMP.

 

Έτσι το έχω δει πολλάκις.

Αντίθετα, την ιδέα που αναφέρεις δεν την έχω συναντήσει πουθενά.

Αν δεν την μνημονεύουν οι ειδικοί, μάλλον δεν θα δουλεύει.

 

Η ουσία είναι ότι στον ίδιο κόμβο μπορείς να εκμεταλευτείς το πλεονέκτημα της κοινής μνήμης άμεσα με

το openMP (ή κάποιο άλλο API νημάτων), δεν υπάρχει λόγος να προσπαθήσεις να κάνεις το ίδιο με το MPI.

To σημαντικότερο που πρέπει να προσέξεις είναι η διατήρηση της τοπικότητας των δεδομένων

(κάτι στο οποίο τα ΑPIs με νήματα γενικά υστερούν και είναι πολύ εύκολο να την καταστρέψουν...)

 

-

[computeras13]

Ναι σκέφτηκα να χρησιμοποιήσω και openMP απλά είπα να αποκλείσω πρώτα αυτό το ενδεχόμενο.

[pagratios]

Επειδή είχα δουλέψει λίγο σε MPI έχω την εντύπωση ότι αυτό που ζητάς μάλλον δεν γίνεται για αυτό λέγεται και κατανεμημένης μνήμης. Ο κάθε επεξεργαστής έχει τον δικό του χώρο στην μνήμη και ξεκινάει δική του αρίθμηση στην μνήμη οπότε αν εσύ στείλεις την διεύθυνση από τον έναν επεξεργαστή στον άλλο, ακόμα και αν είναι στο ίδιο μηχάνημα, θα βρει κάτι διαφορετικό από αυτό που θες

[computeras13]

Ευχαριστώ για τις απαντήσεις παιδιά. Δοκίμασα και ένα υβριδικό σύστημα (MPI+OpenMP) μαζί αλλά τελικά είδα οτι η απόδοση χρονικά είναι καλύτερη μόνο με την χρήση του MPI. Δεν μπορώ να εξηγήσω το γιατί όμως. Ο βελτιστοποιημένος κώδικας για OpenMP υπήρχε ήδη οπότε δεν νομίζω να είναι εκεί το θέμα. Εν κατακλείδι καταστάλαξα στην τελική υλοποίηση η οποία είναι αρκετά ικανοποιητική χρονικά

[V.I.Smirnov]

Το openMP ανταλλάσει την ευκολία γραφής με τις επιδόσεις - εν μέρη κατά βούληση.

 

Οι παράγοντες που επηρεάζουν περισσότερο τις επιδόσεις με το openMP

είναι έμμεσοι, μεγάλης σημασίας και δύσκολο να ελεγχθούν.

Με το βάλεις απλοϊκά τις εντολές "parallel" δεν κερδίζεις πολλά, ενίοτε μάλιστα μπορεί να χάσεις !

False sharing, τοπικότητα δεδομένων (αυτά τα δύο είναι τα χειρότερα !),

ισοκατανομή φορτίου, συγχρονισμός, vecrorization.

Kαι - δυστυχώς και κυρίως - και σε συνδυασμό μεταξύ τους.

Αν δεν έχεις ειδικό λογισμικό που που να κάνει ανάλυση του κώδικα,

είναι δύσκολο να πιάσεις το μέγιστο.

Σε μια δική μου δοκιμή, σε μηχάνημα με 8 cpus έθεσα 13 νήματα και η επατάχυνση ήταν περίπου 5.2

έναντι του ιδανικού 8, ήτοι 65%. Μεγάλο μέρος της ισχύος χανόταν.

 

Δυστυχώς η δυσκολία γραφής και συντήρησης κώδικα σε MPI,

το καθιστά πρακτικώς ασύμφορο για κοινές πρακτικές χρήσεις...

 

-

[computeras13]

Για να εξηγήσω την κατάσταση. Όλα αυτά είναι στα πλαίσια εργασιών σε μάθημα για HPC. Η πρώτη εργασία ήταν λύση ενός προβλήματος μέσω OpenMP με την χρήση έως 4 πυρήνων. Σε σχέση με το ιδανικό x4 έπιασα ένα x3 (θα μπορούσε να βελτιωθεί λίγο με μια μικρή απόκλειστη στην ακεραιότητα των δεδομένων που δεν την ήθελα). Θα μπορούσε βέβαια να γίνει περαιτέρω βελτιώση - πάντα γίνεται.

 

Η δεύτερη που ασχολούμαι τώρα είναι ο ίδιος κώδικας να γίνει μέσω MPI με την χρήση έως και 16 cpus. Οπότε δοκιμάζω διάφορα πράγματα και ο κώδικας σε OpenMP που χρησιμοποιήσα στο υβρίδιο ήταν αυτός που είχα χρησιμοποιήσει στο πρώτο κομμάτι της εργασίας. Οπότε περίμενα λογικά να έχει σχετικά καλή απόδοση. Όμως το υβρίδιο στους 1-4 πυρήνες ήταν χειρότερο από την λύση με MPI και από εκεί και πέρα ήταν στα ίδια επίπεδα. Οπότε είπα να μείνω μόνο στο MPI.

 

Το επόμενο κομμάτι θα είναι OpenCL! Εκείνο πιστεύω θα έχει αρκετό ενδιαφέρον

[dop]

Το κάθε MPI process έχει το δικό του address space - οπότε το να μοιράζεσαι μνήμη δεν είναι δυνατόν μέσω MPI, εκτός και αν καταφύγεις σε shared-memory interprocess communication (υπάρχουν αρκετοί τρόποι για αυτό).

 

Τώρα, το μεγαλύτερο πρόβλημα με το MPI είναι η αντιγραφή δεδομένων και με το OpenMP το sharing, τα threads να ανταγωνίζονται για το ίδιο κομμάτι μνήμης, είτε για σωστούς λόγους (true sharing) είτε για τελείως τεχνητούς λόγους (false sharing). Σε shared-memory systems, αν το πρόβλημα είναι το data copying (πολλά δεδομένα πρέπει να αντιγράφονται συνέχεια) τότε πηγαίνοντας από MPI σε OpenMP θα βοηθήσει. Αν το πρόβλημε είναι το sharing, τότε η μετάβαση από OpenMP σε MPI θα βοηθήσει. Σε distributed memory systems (clusters) το MPI ή το hybrid OpenMP+MPI είναι μονόδρομος (εκτός και αν έχεις πρόσβαση σε πιο εξωτικές βιβλιοθήκες).

 

Για να κάνεις τον κώδικά σου γρήγορο, δες που υπάρχουν synchronization και contention points (περιμένεις κάποιο μήνυμα, έχεις critical section ή αν μοιράζεσαι δεδομένα).

[computeras13]

Ευχαριστώ πολύ παιδιά για όλες τις απαντήσεις. Κατέθεσα την εργασία μου προχθές όπου τελικά την υλοποίησα μόνο με MPI. Πήγε καλά κιόλας μιας και σε σχέση με το perfect scalability που έδινε ο σειριακός κώδικας, ο MPI κώδικας τα πήγαινε αρκετά καλύτερα όταν έμπαιναν πάνω από 2 υπολογιστές στο παιχνίδι. Παράδειγμα στους 16 πυρήνες είχε επιτάχυνση περίπου x18-x19 φορές.

[dop]

Αν δεν έχεις αλλάξει αλγόριθμο, superlinear speedups σημαίνουν ότι το problem size σου είναι μικρό. Άμα το αυξήσεις, τότε θα δεις την απόδοση να πέφτει κατά πολύ. Και αυτό συμβαίνει γιατί όταν "ρίχνεις" και άλλους επεξεργαστές στο computation, αυξάνεις ταυτόχρονα και την cache (οπότε το superlinear speedup είναι τελείως τεχνητό). Ο καθηγητής σας θα έπρεπε να το είχε αναφέρει...

[V.I.Smirnov]

Έχει δίκιο ο dop.

Ενας αλγόριθμος είναι κλιμακώσιμος αν το επίπεδο παραλληλισμού του

αυξάνεται τουλάχιστον γραμμικά με το μέγεθος του προβλήματος που λύνει.

Για να εξεταστεί αυτό πρέπει να γίνει το διάγραμμα ellapsed time vs memory footprint

ή ακόμα καλύτερα speedup vs memory footprint

(για κάθε πλήθος νημάτων ή διεργασιών) μέχρι περίπου το όριο της διαθέσιμης μνήμης.

Αλλιώς προβλήματα όπως το παραπάνω δεν εντοπίζονται...

 

-

[dop]

Memory footprint vs time δε σου λέει και πολλά. Από την άλλη, cache hits/misses vs #cores σου λέει πολλά. Αν κάνει plot τα cache hits με τον αριθμό των cores που χρησιμοποιεί, τότε θα δει γιατί έχει superlinear speedup (τα cache hits θα αυξάνονται, γιατί το πρόβλημα είναι μικρό και "χωράει" στην L2 ή την L3 cache.

 

Ή πολύ απλά αντί για strong scaling (σταθερό μέγεθος προβλήματος - μεταβλητός αριθμός cores) μπορεί να κάνει weak scaling (σταθερό μέγεθος προβλήματος/core). Σε τέλειο αλγόριθμο, το weak scaling δίνει ευθεία γραμμή.

[computeras13]

Είναι ακριβώς αυτό που είπες. Μειώνονται τα cache missed όσο αυξάνει ο αριθμός των cpu και γίνεται καλύτερη χρήση της cache. Ο αλγόριθμος άλλαξε μόνο και μόνο για να γίνει η επικοινωνία μεταξύ των nodes, τίποτα περισσότερο (μιας και ήταν βελτιστοποιημένος - σε κάποιο βαθμό τουλάχιστον - από πριν).

 

Όσον αφορά το μέγεθος του προβλήματος δοκίμασα 2-3 διαφορετικά μεγέθη. Έχω και ένα τρίτο που θέλω να δοκιμάσω αλλά δεν μπορώ αυτή την στιγμή γιατί έχουν πλακώσει όλοι στον υπερυπολογιστή και περιμένει η "εργασία" στην ουρά εδώ και ώρες....

[V.I.Smirnov]

Tα cache misses/hits πώς θα τα δεις δίχως ειδικό λογισμικό ;

(π.χ. σε ένα κοινό pc)

 

Εγώ όσες φορές έκανα δοκιμές σε παραλληλία, είχα ένα πρόγραμμα-οδηγό που

καλούσε τοκύριο πρόγραμμα σε προοδευτικά αυξανόμενο μέγεθος προβλήματος

(π.χ. από πλέγμα 10x10 έως 200x200 με βήμα αύξησης 10)

και αυξανόμενο πλήθος νημάτων ή διεργασιών (2,4,...)

Το speedup ή (ellapsed time) vs memory footprint μου έδινε το efficiency....

 

 

-

[computeras13]

Θα χρησιμοποιήσεις κάποιον profiler πχ τον tau.