dop Δημοσ. 25 Οκτωβρίου 2010 Δημοσ. 25 Οκτωβρίου 2010 Υπάρχουν εργαλεία που κάνουν αυτή την δουλειά σε μικρομετρικό επίπεδο. Π.χ. το analyzer της ίδιας της intel.Αλλά εγώ δεν τα χρησιμοποίησα διότι δεν ήταν συμβατά με την έκδοση του compiler που είχα (τα είχα βρει κλεψιμέικα). Δε χρειάζεται εργαλεία - ένας απλός timer κάνει. Τα εργαλεία θα παράξουν πολύ περισσότερες πληροφορίες από όσες χρειάζεται για να κάνει identify το bottleneck σε τόσο αρχικά στάδια. Όχι απλώς πιο δύσκολο, ΠΟΛΥ πιο δύσκολο. Και συμβαίνει το αντίθετο απ' ότι λες :το MPI γενικά κλιμακώνει καλύτερα κι' όχι το openMP. Σε αυτό δεν φταίει όμως τόσο το openMP όσο ο τρόπος γραφής του προγράμματος όπως ηδη είπα 3 φορές. Τα βιβλία που σύστησα εξηγούν τους λόγους. Για μηχανήματα desktop όπως αυτά που χρησιμοποιούμε καθημερινά και για γραφή σύνηθων προγραμμάτων το MPI είναι ακατάλληλο για πολλούς λόγους. Μακριά..... Δεν είναι "ΠΟΛΥ πιο δύσκολο", απλά είναι διαφορετικό. Στο κάτω-κάτω είναι μια βιβλιοθήκη για ανταλλαγή μηνυμάτων. Εντάξει, δεν το έκανες και στο δημοτικό, αλλά δεν είναι και rocket science. Άμα θέλεις επιδόσεις, θα δεις και το OpenMP και το MPI και όλα. Η κοινή λογική λέει ότι το να παραλληλίσεις κώδικα με threads (OpenMP) θα είναι πιο γρήγορο από το να το κάνεις με processes (MPI) λόγω λιγότερης καταναλισκούμενης μνήμης και memory sharing. Η σχετική βιβλιογραφία για hybrid OpenMP + MPI programming θα σε πείσει. Η πράξη διαφέρει στο γεγονός ότι το MPI σε κάνει να σκεφτείς λίγο περισσότερο για το data locality και να αποφύγεις όσο το δυνατόν τις shared μεταβλητές (που για το MPI χρειάζεται να κουβαλάς δεξιά και αριστερά τις τιμές, υλοποιώντας ένα είδος software cache coherency). Περισσότερα accesses σε shared variables σημαίνει περισσότερα cache line invalidations, μεγαλύτερο bandwidth consumption στο bus και άρα χειρότερες επιδόσεις. Ο ίδιος ακριβώς κώδικας σε MPI και OpenMP (άμα δηλαδή γράφεις OpenMP κάνοντας αντιγραφή ότι μεταβλητής χρησιμοποιείς) έχει την ίδια απόδοση με μικρότερο memory footprint. Όμως, αν σήμερα το MPI ξεπερνά το OpenMP σε επιδόσεις, αυτό δε σημαίνει ότι θα γίνει και αύριο: όσο οι compilers γίνονται πιο "έξυπνοι", τόσο γέρνει η πλάστιγγα προς τη μεριά του OpenMP, καθώς με το OpenMP ο compiler μπορεί να κάνει περισσότερα optimizations. Ίσως έχεις δίκιο για τα TBB. Εγώ το ξέρω σαν όνομα αλλά δεν το έχω ασχοληθεί. Δεν ξέρω όμως κατά πόσον είναι standard σαν τις άλλες επιλογές. Για τα υπόλοιπα που αναφέρεις, ήδη σε πρόλαβα.... Οτιδήποτε εκφράζεται με data parallelism, μπορείς να το εκφράσεις με task parallelism - απλά ο γράφος των εξαρτήσεων των tasks είναι ένα one-level tree. Το task parallelism είναι αρκετά πιο abstract από το data. Για την ιστορία, ούτε το MPI είναι standard ακριβώς - ό,τι θέλει υλοποιεί ο κάθε vendor. ΥΓ ένα καλό tutorial που βρήκα για την έκδοση 9 είναι στο http://www.ncsa.illinois.edu/UserInfo/Resources/Software/Intel/Compilers/9.0/training/optimize/index.htm Κάπου θα υπάρχει και για την 10 (ίσως στην Intel ή σε κάποιο από τα CD). ΥΓ2 όχι, δε με πρόλαβες, μας πρόλαβαν και τους δύο ο William Gropp, η Barbara Chapman και άλλοι πολλοί. Και εκτός των άλλων, σημείωσα ότι προαναφέρθηκαν.
V.I.Smirnov Δημοσ. 25 Οκτωβρίου 2010 Δημοσ. 25 Οκτωβρίου 2010 Δε χρειάζεται εργαλεία - ένας απλός timer κάνει. Τα εργαλεία θα παράξουν πολύ περισσότερες πληροφορίες από όσες χρειάζεται για να κάνει identify το bottleneck σε τόσο αρχικά στάδια. Συμφωνώ. Aλλά τα εργαλεία που είχα δει ήταν πράγματι πολύ χρήσιμα ακόμα ακόμα και στο αρχικό στάδιο. Δεν είναι "ΠΟΛΥ πιο δύσκολο", απλά είναι διαφορετικό.Στο κάτω-κάτω είναι μια βιβλιοθήκη για ανταλλαγή μηνυμάτων. Εντάξει, δεν το έκανες και στο δημοτικό, αλλά δεν είναι και rocket science. Διαφωνώ τελείως. Το MPI "είναι η assembly των παράλληλων συστημάτων". Το έχουν πει ειδικοί επί του θέματος. Η μεγάλη δυσκολία του έγκειται στα : 1) Απαιτεί την πλήρη αποδόμηση του προγράμματος και των δεδομένων του για οτιδήποτε σχεδόν κάνεις. Ακόμα και για μια απλή πρόσθεση πινάκων π.χ. 2) Απαιτεί σχεδόν αδιακρίτως καθολικό παραλληλισμό. Παραλληλίζεις ή τα πάντα ή τίποτε. Και το πρόγραμμα δεν μπορεί γενικά να τρέξει - άρα και να ελεχθεί - αν δεν γραφεί ολόκληρο. Εξάλλου υπάρχουν μέρη του προγράμματος που μπορεί να μην συμφέρει να παραλληλιστούν για διάφορους λόγους (π.χ. εισαγωγή δεδομένων) ενώ είναι μεγάλος μπελάς να τα κάνεις παράλληλα. 3) Λόγω του 2) η αποσφαλμάτωση και η τροποποίηση της δομής του καθώς γράφεται είναι πολύ πιο δύσκολες. Επιπλέον, debuggers για MPI πρόγραμμα δεν είναι ευρέως διαθέσιμοι. 4) Ένας σειριακός αλγόριθμος και η εκδοχή του σε MPI είναι συνήθως εντελώς άσχετοι. Αυτό συνεπάγεται ότι αν κάποιος έχει ήδη την σειριακή έκδοση έκδοση ενός προγράμματος ή αλγόριθμου, του είναι σχεδόν άχρηστη σε ότι αφορά την μετατροπή της σε MPI. Ένα ήδη γραμμενο πρόγραμμα, για να μεταγραφεί σε MPI πρέπει να γραφεί από την αρχή και με τελείως διαφορετικό τρόπο. Eπιπλέον, η συντήρηση και περαιτέρω ανάπτυξή του είναι πολύ πιο δύσκολες. Η κοινή λογική λέει ότι το να παραλληλίσεις κώδικα με threads (OpenMP) θα είναι πιο γρήγορο από το να το κάνεις με processes (MPI) λόγω λιγότερης καταναλισκούμενης μνήμης και memory sharing. Η σχετική βιβλιογραφία για hybrid OpenMP + MPI programming θα σε πείσει. Όχι, τουλάχιστον στην πράξη (εκτός αν δεν κατάλαβα καλά τι εννοείς). Κατά παράδοση και πρακτικά το MPI είναι αυτό που κλιμακώνει καλύτερα. Δεν θα παραθέσω links, υπάρχουν αμέτρητα. Και το πρώτο από τα βιβλία που παραθέτουμε κι οι δυό μας το υπαινίσσεται στην σελ. 206 όπου προσπαθεί να δείξει ακριβώς αυτό : ότι παρά την καλύτερη κλιμακωσιμότητα του MPI, το openMP το συναγωνίζεται αν γραφεί κατάλληλα το πρόγραμμα. Συνήθως όλοι ξεκινούν με το openMP και βλέπουν ότι δεν κλιμακώνει γραμμικά και απογοητεύονται. Αλλά στις περισσότερες περιπτώσεις φταίει κύρια ο τρόπος γραφής του προγράμματος. Δεν αρκεί να μπουν μόνον οι directives, τα είπαμε. Η πράξη διαφέρει στο γεγονός ότι το MPI σε κάνει να σκεφτείς λίγο περισσότερο για το data locality και να αποφύγεις όσο το δυνατόν τις shared μεταβλητές (που για το MPI χρειάζεται να κουβαλάς δεξιά και αριστερά τις τιμές, υλοποιώντας ένα είδος software cache coherency). Μακάρι να ήταν έτσι αλλά δεν είναι. H πράξη διαφέρει σε ότι απαρίθμησα πριν. Και σε καθημερινή δουλειά στην οποία δεν πρόκειται για tutorials των 50 γραμμών που απλώς πολλαπλασιάζουν πίνακες, τα 1) - 4) είναι πολύ σημαντικά. Οτιδήποτε εκφράζεται με data parallelism, μπορείς να το εκφράσεις με task parallelism - απλά ο γράφος των εξαρτήσεων των tasks είναι ένα one-level tree. Το task parallelism είναι αρκετά πιο abstract από το data. Εγώ ξέρω καλά το παρακάτω : Οι αλγόριθμοι παραλληλισμού δεδομένων είναι πιο κλιμακώσιμοι από τους αλγόριθμους παραλληλισμού ελέγχου. Ο λόγος : το επίπεδο παραλληλισμού ελέγχου είναι μια σταθερά, ανεξάρτητη από το μέγεθος του προβλήματος ενώ το επίπεδο παραλληλισμού δεδομένων είναι μια αύξουσα συνάρτηση του μεγέθους του προβλήματος. Αυτό σημαίνει ότι όταν κάτι γράφεται σε στυλ παραλληλισμού ελέγχου η επιτάχυνση έχει άνω όριο ανεξάρτητα από το πλήθος των χρησιμοποιούμενων cpus, ενώ o παραλληλισμός δεδομένων όχι. (Μπορώ και να παραθέσω παράδειγμα αλλά είναι μεγάλο και ας μην γράφω τώρα.,..) Αυτό που λες για τον γράφο των εξαρτήσεων ακούγεται λογικό - δηλ., αν κατάλαβα καλά, λες ότι ο παραλληλισμός δεδομένων είναι υποκατηγορία του παραλληλισμού ελέγχου (και άρα η διαφορά τους είναι μόνον στο στυλ γραφής ; ) Το γεγονός είναι ότι το ΜPI είναι ακατάλληλο για καθημερινή χρήση, ειδικά αν δουλεύεις με ήδη γραμμένα ή μεγάλα ή πολύπλοκα προγράμματα. -
V.I.Smirnov Δημοσ. 25 Οκτωβρίου 2010 Δημοσ. 25 Οκτωβρίου 2010 Δε χρειάζεται εργαλεία - ένας απλός timer κάνει. Τα εργαλεία θα παράξουν πολύ περισσότερες πληροφορίες από όσες χρειάζεται για να κάνει identify το bottleneck σε τόσο αρχικά στάδια. Συμφωνώ. Aλλά τα εργαλεία που είχα δει ήταν πράγματι πολύ χρήσιμα ακόμα ακόμα και στο αρχικό στάδιο. Δεν είναι "ΠΟΛΥ πιο δύσκολο", απλά είναι διαφορετικό.Στο κάτω-κάτω είναι μια βιβλιοθήκη για ανταλλαγή μηνυμάτων. Εντάξει, δεν το έκανες και στο δημοτικό, αλλά δεν είναι και rocket science. Διαφωνώ τελείως. Το MPI "είναι η assembly των παράλληλων συστημάτων". Το έχουν πει ειδικοί επί του θέματος. Η μεγάλη δυσκολία του έγκειται στα : 1) Απαιτεί την πλήρη αποδόμηση του προγράμματος και των δεδομένων του για οτιδήποτε σχεδόν κάνεις. Ακόμα και για μια απλή πρόσθεση πινάκων π.χ. 2) Απαιτεί σχεδόν αδιακρίτως καθολικό παραλληλισμό. Παραλληλίζεις ή τα πάντα ή τίποτε. Και το πρόγραμμα δεν μπορεί γενικά να τρέξει - άρα και να ελεχθεί - αν δεν γραφεί ολόκληρο. Εξάλλου υπάρχουν μέρη του προγράμματος που μπορεί να μην συμφέρει να παραλληλιστούν για διάφορους λόγους (π.χ. εισαγωγή δεδομένων) ενώ είναι μεγάλος μπελάς να τα κάνεις παράλληλα. 3) Λόγω του 2) η αποσφαλμάτωση και η τροποποίηση της δομής του καθώς γράφεται είναι πολύ πιο δύσκολες. Επιπλέον, debuggers για MPI πρόγραμμα δεν είναι ευρέως διαθέσιμοι. 4) Ένας σειριακός αλγόριθμος και η εκδοχή του σε MPI είναι συνήθως εντελώς άσχετοι. Αυτό συνεπάγεται ότι αν κάποιος έχει ήδη την σειριακή έκδοση έκδοση ενός προγράμματος ή αλγόριθμου, του είναι σχεδόν άχρηστη σε ότι αφορά την μετατροπή της σε MPI. Ένα ήδη γραμμενο πρόγραμμα, για να μεταγραφεί σε MPI πρέπει να γραφεί από την αρχή και με τελείως διαφορετικό τρόπο. Eπιπλέον, η συντήρηση και περαιτέρω ανάπτυξή του είναι πολύ πιο δύσκολες. Η κοινή λογική λέει ότι το να παραλληλίσεις κώδικα με threads (OpenMP) θα είναι πιο γρήγορο από το να το κάνεις με processes (MPI) λόγω λιγότερης καταναλισκούμενης μνήμης και memory sharing. Η σχετική βιβλιογραφία για hybrid OpenMP + MPI programming θα σε πείσει. Όχι, τουλάχιστον στην πράξη (εκτός αν δεν κατάλαβα καλά τι εννοείς). Κατά παράδοση και πρακτικά το MPI είναι αυτό που κλιμακώνει καλύτερα. Δεν θα παραθέσω links, υπάρχουν αμέτρητα. Και το πρώτο από τα βιβλία που παραθέτουμε κι οι δυό μας το υπαινίσσεται στην σελ. 206 όπου προσπαθεί να δείξει ακριβώς αυτό : ότι παρά την καλύτερη κλιμακωσιμότητα του MPI, το openMP το συναγωνίζεται αν γραφεί κατάλληλα το πρόγραμμα. Συνήθως όλοι ξεκινούν με το openMP και βλέπουν ότι δεν κλιμακώνει γραμμικά και απογοητεύονται. Αλλά στις περισσότερες περιπτώσεις φταίει κύρια ο τρόπος γραφής του προγράμματος. Δεν αρκεί να μπουν μόνον οι directives, τα είπαμε. Η πράξη διαφέρει στο γεγονός ότι το MPI σε κάνει να σκεφτείς λίγο περισσότερο για το data locality και να αποφύγεις όσο το δυνατόν τις shared μεταβλητές (που για το MPI χρειάζεται να κουβαλάς δεξιά και αριστερά τις τιμές, υλοποιώντας ένα είδος software cache coherency). Μακάρι να ήταν έτσι αλλά δεν είναι. H πράξη διαφέρει σε ότι απαρίθμησα πριν. Και σε καθημερινή δουλειά στην οποία δεν πρόκειται για tutorials των 50 γραμμών που απλώς πολλαπλασιάζουν πίνακες, τα 1) - 4) είναι πολύ σημαντικά. Οτιδήποτε εκφράζεται με data parallelism, μπορείς να το εκφράσεις με task parallelism - απλά ο γράφος των εξαρτήσεων των tasks είναι ένα one-level tree. Το task parallelism είναι αρκετά πιο abstract από το data. Εγώ ξέρω καλά το παρακάτω : Οι αλγόριθμοι παραλληλισμού δεδομένων είναι πιο κλιμακώσιμοι από τους αλγόριθμους παραλληλισμού ελέγχου. Ο λόγος : το επίπεδο παραλληλισμού ελέγχου είναι μια σταθερά, ανεξάρτητη από το μέγεθος του προβλήματος ενώ το επίπεδο παραλληλισμού δεδομένων είναι μια αύξουσα συνάρτηση του μεγέθους του προβλήματος. Αυτό σημαίνει ότι όταν κάτι γράφεται σε στυλ παραλληλισμού ελέγχου η επιτάχυνση έχει άνω όριο ανεξάρτητα από το πλήθος των χρησιμοποιούμενων cpus, ενώ o παραλληλισμός δεδομένων όχι. (Μπορώ και να παραθέσω παράδειγμα αλλά είναι μεγάλο και ας μην γράφω τώρα.,..) Αυτό που λες για τον γράφο των εξαρτήσεων ακούγεται λογικό - δηλ., αν κατάλαβα καλά, λες ότι ο παραλληλισμός δεδομένων είναι υποκατηγορία του παραλληλισμού ελέγχου (και άρα η διαφορά τους είναι μόνον στο στυλ γραφής ; ) Το γεγονός είναι ότι το ΜPI είναι ακατάλληλο για καθημερινή χρήση, ειδικά αν δουλεύεις με ήδη γραμμένα ή μεγάλα ή πολύπλοκα προγράμματα. -
dop Δημοσ. 26 Οκτωβρίου 2010 Δημοσ. 26 Οκτωβρίου 2010 Διαφωνώ τελείως. Το MPI "είναι η assembly των παράλληλων συστημάτων". Το έχουν πει ειδικοί επί του θέματος. Η μεγάλη δυσκολία του έγκειται στα : 1) Απαιτεί την πλήρη αποδόμηση του προγράμματος και των δεδομένων του για οτιδήποτε σχεδόν κάνεις. Ακόμα και για μια απλή πρόσθεση πινάκων π.χ. 2) Απαιτεί σχεδόν αδιακρίτως καθολικό παραλληλισμό. Παραλληλίζεις ή τα πάντα ή τίποτε. Και το πρόγραμμα δεν μπορεί γενικά να τρέξει - άρα και να ελεχθεί - αν δεν γραφεί ολόκληρο. Εξάλλου υπάρχουν μέρη του προγράμματος που μπορεί να μην συμφέρει να παραλληλιστούν για διάφορους λόγους (π.χ. εισαγωγή δεδομένων) ενώ είναι μεγάλος μπελάς να τα κάνεις παράλληλα. 3) Λόγω του 2) η αποσφαλμάτωση και η τροποποίηση της δομής του καθώς γράφεται είναι πολύ πιο δύσκολες. Επιπλέον, debuggers για MPI πρόγραμμα δεν είναι ευρέως διαθέσιμοι. 4) Ένας σειριακός αλγόριθμος και η εκδοχή του σε MPI είναι συνήθως εντελώς άσχετοι. Αυτό συνεπάγεται ότι αν κάποιος έχει ήδη την σειριακή έκδοση έκδοση ενός προγράμματος ή αλγόριθμου, του είναι σχεδόν άχρηστη σε ότι αφορά την μετατροπή της σε MPI. Ένα ήδη γραμμενο πρόγραμμα, για να μεταγραφεί σε MPI πρέπει να γραφεί από την αρχή και με τελείως διαφορετικό τρόπο. Eπιπλέον, η συντήρηση και περαιτέρω ανάπτυξή του είναι πολύ πιο δύσκολες. Τα παραπάνω ισχύουν για οποιοδήποτε runtime ή βιβλιοθήκη που υπόσχεται παραλληλισμό - το να βάλεις ένα #pragma omp parallel σε ένα loop δεν έκανε τον αλγόριθμό σου παράλληλο ή τον προγραμματιστή parallel guru. Μια τρύπα στο νερό είναι - ειδάλλως δε θα είχα δουλειά. Χρειάζεται πολύ περισσότερη προσπάθεια. Όντως το MPI είναι η assembly των distributed memory συστημάτων, αλλά και το OpenMP δεν πάει πίσω - υπενθυμίζω ότι δεν υπόσχεται thread-safe δομές και δεν έχει έτοιμους αλγορίθμους. Αυτά τα δύο είναι που σε κάνουν high-level. Υπάρχουν ευρέως διαθέσιμοι debuggers, όπως το totalview (http://www.totalviewtech.com/home/) και το Allinea DDT (http://www.allinea.com/). Το Microsoft HPC Server έχει τον δικό του επίσης που κουμπώνει στο Visual Studio. Όχι, τουλάχιστον στην πράξη (εκτός αν δεν κατάλαβα καλά τι εννοείς). Κατά παράδοση και πρακτικά το MPI είναι αυτό που κλιμακώνει καλύτερα. ... Συνήθως όλοι ξεκινούν με το openMP και βλέπουν ότι δεν κλιμακώνει γραμμικά και απογοητεύονται. Αλλά στις περισσότερες περιπτώσεις φταίει κύρια ο τρόπος γραφής του προγράμματος. Δεν αρκεί να μπουν μόνον οι directives, τα είπαμε. Το ίδιο λέμε - αυτό που λέω παραπάνω είναι πως αν γράψεις ΣΩΣΤΑ το πρόγραμμα σε OpenMP με ελαχιστοποίηση των accesses σε shared μεταβλητές θα έχεις καλύτερη απόδοση από το MPI, επειδή το MPI θέλει μνήμη (πολύ μνήμη) για να λειτουργήσει. Άμα διαβάσεις σχετικά paper ο κύριος λόγος πίσω από OpenMP + MPI hybrid δεν είναι επειδή το πρώτο είναι πιο γρήγορο από μόνο του. Είναι πως σε 1.000.000 επεξεργαστές, το MPI ΔΕΝ κάνει scale (http://www.springerlink.com/content/v054l8q47wp74165/). Και σε έναν κόσμο που το ένα CPU socket θα έχει 100+ cores, θα ξοδέψεις όλη τη μνήμη απλά με το να κάνεις initialize το MPI. Ξανά, άμα έκανε scale, πάλι δε θα είχα δουλειά. Μακάρι να ήταν έτσι αλλά δεν είναι. H πράξη διαφέρει σε ότι απαρίθμησα πριν. Και σε καθημερινή δουλειά στην οποία δεν πρόκειται για tutorials των 50 γραμμών που απλώς πολλαπλασιάζουν πίνακες, τα 1) - 4) είναι πολύ σημαντικά. Μα έτσι είναι - το MPI απλά θέλει explicit object transfers. Δεν έχεις shared memory και άρα πρέπει να μεταφέρεις μνήμη και να κάνεις και το λογιστή, επιβάλλοντας coherency protocol. Μπορείς να το κρύψεις εντέχνως και να γίνει πολύ απλό (βλ Boost.MPI) αλλά στο τέλος πάντα ζητάει από τον προγραμματιστή να κάνει όλη τη δουλειά. Αυτό είναι η δυσκολία του - και δεν είναι μικρή - όχι ότι είναι περίπλοκο σαν βιβλιοθήκη. Εγώ ξέρω καλά το παρακάτω : Οι αλγόριθμοι παραλληλισμού δεδομένων είναι πιο κλιμακώσιμοι από τους αλγόριθμους παραλληλισμού ελέγχου. Ο λόγος : το επίπεδο παραλληλισμού ελέγχου είναι μια σταθερά, ανεξάρτητη από το μέγεθος του προβλήματος ενώ το επίπεδο παραλληλισμού δεδομένων είναι μια αύξουσα συνάρτηση του μεγέθους του προβλήματος. Αυτό σημαίνει ότι όταν κάτι γράφεται σε στυλ παραλληλισμού ελέγχου η επιτάχυνση έχει άνω όριο ανεξάρτητα από το πλήθος των χρησιμοποιούμενων cpus, ενώ o παραλληλισμός δεδομένων όχι. (Μπορώ και να παραθέσω παράδειγμα αλλά είναι μεγάλο και ας μην γράφω τώρα.,..) Αυτό που λες για τον γράφο των εξαρτήσεων ακούγεται λογικό - δηλ., αν κατάλαβα καλά, λες ότι ο παραλληλισμός δεδομένων είναι υποκατηγορία του παραλληλισμού ελέγχου (και άρα η διαφορά τους είναι μόνον στο στυλ γραφής ; ) Στο data parallelism έχεις 1 συνάρτηση που την εφαρμόζεις σε n δεδομένα. Στο task parallelism έχεις n συναρτήσεις για n δεδομένα. Ποιο είναι πιο γενικό; Ναι, αν το πρόβλημά σου είναι στατικό και μπορείς να σπάσεις τα δεδομένα σου σε όμοια blocks, τότε το data parallelism ίσως (ανάλογα με την υλοποίηση) να σου δώσει ένα μικρό προβάδισμα. Αλλά δεδομένου ότι αυτά τα προγράμματα είναι σπάνια, το task parallelism νικάει. Το πόσο αποδοτικά εκμεταλεύεσαι ένα σύστημα εξαρτάται από 1) το πόσο overhead έχει το abstraction σου και 2) πόσο adaptive είναι στις runtime συνθήκες. Τα data parallel runtimes χάνουν κατά κράτος στο 2 και τα task parallel runtimes γίνονται όλο και πιο έξυπνα στο 1. Δεν είναι τυχαίο πως όλα τα τελευταία runtimes και γλώσσες (X10, Fortress, Chapel, Charm++, Cilk++ και άλλα πολλά) υποστηρίζουν task parallelism. Κάπου έχεις μπλέξει το συλλογισμό σου - το ότι έχεις task parallelism δε σημαίνει ότι είναι coarse-grain απαραίτητα - αυτό το έκαναν το '80 με το BSP (Bulk Synchronous Parallelism). Το αντίθετο μάλιστα, προτιμάμε το fine-grain για να κάνουμε efficient load-balancing. Το πόσο fine-grain είναι θέμα πολλών PhD. Διάβασε και για το Cilk, θα σου λύσει αρκετές απορίες.
dop Δημοσ. 26 Οκτωβρίου 2010 Δημοσ. 26 Οκτωβρίου 2010 Διαφωνώ τελείως. Το MPI "είναι η assembly των παράλληλων συστημάτων". Το έχουν πει ειδικοί επί του θέματος. Η μεγάλη δυσκολία του έγκειται στα : 1) Απαιτεί την πλήρη αποδόμηση του προγράμματος και των δεδομένων του για οτιδήποτε σχεδόν κάνεις. Ακόμα και για μια απλή πρόσθεση πινάκων π.χ. 2) Απαιτεί σχεδόν αδιακρίτως καθολικό παραλληλισμό. Παραλληλίζεις ή τα πάντα ή τίποτε. Και το πρόγραμμα δεν μπορεί γενικά να τρέξει - άρα και να ελεχθεί - αν δεν γραφεί ολόκληρο. Εξάλλου υπάρχουν μέρη του προγράμματος που μπορεί να μην συμφέρει να παραλληλιστούν για διάφορους λόγους (π.χ. εισαγωγή δεδομένων) ενώ είναι μεγάλος μπελάς να τα κάνεις παράλληλα. 3) Λόγω του 2) η αποσφαλμάτωση και η τροποποίηση της δομής του καθώς γράφεται είναι πολύ πιο δύσκολες. Επιπλέον, debuggers για MPI πρόγραμμα δεν είναι ευρέως διαθέσιμοι. 4) Ένας σειριακός αλγόριθμος και η εκδοχή του σε MPI είναι συνήθως εντελώς άσχετοι. Αυτό συνεπάγεται ότι αν κάποιος έχει ήδη την σειριακή έκδοση έκδοση ενός προγράμματος ή αλγόριθμου, του είναι σχεδόν άχρηστη σε ότι αφορά την μετατροπή της σε MPI. Ένα ήδη γραμμενο πρόγραμμα, για να μεταγραφεί σε MPI πρέπει να γραφεί από την αρχή και με τελείως διαφορετικό τρόπο. Eπιπλέον, η συντήρηση και περαιτέρω ανάπτυξή του είναι πολύ πιο δύσκολες. Τα παραπάνω ισχύουν για οποιοδήποτε runtime ή βιβλιοθήκη που υπόσχεται παραλληλισμό - το να βάλεις ένα #pragma omp parallel σε ένα loop δεν έκανε τον αλγόριθμό σου παράλληλο ή τον προγραμματιστή parallel guru. Μια τρύπα στο νερό είναι - ειδάλλως δε θα είχα δουλειά. Χρειάζεται πολύ περισσότερη προσπάθεια. Όντως το MPI είναι η assembly των distributed memory συστημάτων, αλλά και το OpenMP δεν πάει πίσω - υπενθυμίζω ότι δεν υπόσχεται thread-safe δομές και δεν έχει έτοιμους αλγορίθμους. Αυτά τα δύο είναι που σε κάνουν high-level. Υπάρχουν ευρέως διαθέσιμοι debuggers, όπως το totalview (http://www.totalviewtech.com/home/) και το Allinea DDT (http://www.allinea.com/). Το Microsoft HPC Server έχει τον δικό του επίσης που κουμπώνει στο Visual Studio. Όχι, τουλάχιστον στην πράξη (εκτός αν δεν κατάλαβα καλά τι εννοείς). Κατά παράδοση και πρακτικά το MPI είναι αυτό που κλιμακώνει καλύτερα. ... Συνήθως όλοι ξεκινούν με το openMP και βλέπουν ότι δεν κλιμακώνει γραμμικά και απογοητεύονται. Αλλά στις περισσότερες περιπτώσεις φταίει κύρια ο τρόπος γραφής του προγράμματος. Δεν αρκεί να μπουν μόνον οι directives, τα είπαμε. Το ίδιο λέμε - αυτό που λέω παραπάνω είναι πως αν γράψεις ΣΩΣΤΑ το πρόγραμμα σε OpenMP με ελαχιστοποίηση των accesses σε shared μεταβλητές θα έχεις καλύτερη απόδοση από το MPI, επειδή το MPI θέλει μνήμη (πολύ μνήμη) για να λειτουργήσει. Άμα διαβάσεις σχετικά paper ο κύριος λόγος πίσω από OpenMP + MPI hybrid δεν είναι επειδή το πρώτο είναι πιο γρήγορο από μόνο του. Είναι πως σε 1.000.000 επεξεργαστές, το MPI ΔΕΝ κάνει scale (http://www.springerlink.com/content/v054l8q47wp74165/). Και σε έναν κόσμο που το ένα CPU socket θα έχει 100+ cores, θα ξοδέψεις όλη τη μνήμη απλά με το να κάνεις initialize το MPI. Ξανά, άμα έκανε scale, πάλι δε θα είχα δουλειά. Μακάρι να ήταν έτσι αλλά δεν είναι. H πράξη διαφέρει σε ότι απαρίθμησα πριν. Και σε καθημερινή δουλειά στην οποία δεν πρόκειται για tutorials των 50 γραμμών που απλώς πολλαπλασιάζουν πίνακες, τα 1) - 4) είναι πολύ σημαντικά. Μα έτσι είναι - το MPI απλά θέλει explicit object transfers. Δεν έχεις shared memory και άρα πρέπει να μεταφέρεις μνήμη και να κάνεις και το λογιστή, επιβάλλοντας coherency protocol. Μπορείς να το κρύψεις εντέχνως και να γίνει πολύ απλό (βλ Boost.MPI) αλλά στο τέλος πάντα ζητάει από τον προγραμματιστή να κάνει όλη τη δουλειά. Αυτό είναι η δυσκολία του - και δεν είναι μικρή - όχι ότι είναι περίπλοκο σαν βιβλιοθήκη. Εγώ ξέρω καλά το παρακάτω : Οι αλγόριθμοι παραλληλισμού δεδομένων είναι πιο κλιμακώσιμοι από τους αλγόριθμους παραλληλισμού ελέγχου. Ο λόγος : το επίπεδο παραλληλισμού ελέγχου είναι μια σταθερά, ανεξάρτητη από το μέγεθος του προβλήματος ενώ το επίπεδο παραλληλισμού δεδομένων είναι μια αύξουσα συνάρτηση του μεγέθους του προβλήματος. Αυτό σημαίνει ότι όταν κάτι γράφεται σε στυλ παραλληλισμού ελέγχου η επιτάχυνση έχει άνω όριο ανεξάρτητα από το πλήθος των χρησιμοποιούμενων cpus, ενώ o παραλληλισμός δεδομένων όχι. (Μπορώ και να παραθέσω παράδειγμα αλλά είναι μεγάλο και ας μην γράφω τώρα.,..) Αυτό που λες για τον γράφο των εξαρτήσεων ακούγεται λογικό - δηλ., αν κατάλαβα καλά, λες ότι ο παραλληλισμός δεδομένων είναι υποκατηγορία του παραλληλισμού ελέγχου (και άρα η διαφορά τους είναι μόνον στο στυλ γραφής ; ) Στο data parallelism έχεις 1 συνάρτηση που την εφαρμόζεις σε n δεδομένα. Στο task parallelism έχεις n συναρτήσεις για n δεδομένα. Ποιο είναι πιο γενικό; Ναι, αν το πρόβλημά σου είναι στατικό και μπορείς να σπάσεις τα δεδομένα σου σε όμοια blocks, τότε το data parallelism ίσως (ανάλογα με την υλοποίηση) να σου δώσει ένα μικρό προβάδισμα. Αλλά δεδομένου ότι αυτά τα προγράμματα είναι σπάνια, το task parallelism νικάει. Το πόσο αποδοτικά εκμεταλεύεσαι ένα σύστημα εξαρτάται από 1) το πόσο overhead έχει το abstraction σου και 2) πόσο adaptive είναι στις runtime συνθήκες. Τα data parallel runtimes χάνουν κατά κράτος στο 2 και τα task parallel runtimes γίνονται όλο και πιο έξυπνα στο 1. Δεν είναι τυχαίο πως όλα τα τελευταία runtimes και γλώσσες (X10, Fortress, Chapel, Charm++, Cilk++ και άλλα πολλά) υποστηρίζουν task parallelism. Κάπου έχεις μπλέξει το συλλογισμό σου - το ότι έχεις task parallelism δε σημαίνει ότι είναι coarse-grain απαραίτητα - αυτό το έκαναν το '80 με το BSP (Bulk Synchronous Parallelism). Το αντίθετο μάλιστα, προτιμάμε το fine-grain για να κάνουμε efficient load-balancing. Το πόσο fine-grain είναι θέμα πολλών PhD. Διάβασε και για το Cilk, θα σου λύσει αρκετές απορίες.
V.I.Smirnov Δημοσ. 26 Οκτωβρίου 2010 Δημοσ. 26 Οκτωβρίου 2010 O debugger της Allinea είναι πράγματι καλός, τον έχω δει αλλά δεν μπόρεσα να τον βρω κλεψιμέικο, δυστυχώς ! Το totalview δεν το ξέρω. Ο cluster debugger που έχει το visual studio μου έκανε ζημιά όταν τον εγκατέστησα κάποτε : στην fortran όταν ήθελα να κάνω debug δεν έβλεπε το πάτημα του F5. Toν έβγαλα. Για τα υπόλοιπα που λες, γενικά συμφωνώ. Αλλά η εντύπωση που υπάρχει διάχυτη παντού είναι ότι γενικά το MPI είναι αυτό που κλιμακώνει καλύτερα. Το openMP αγωνίζεται να πείσει ότι είναι συναγωνίσιμο. Εσύ υποστηρίζεις το ανάποδο, δεν επιμένω αν το έχεις ψάξει, μακάρι να έχεις δίκιο : με κάνεις χαρούμενο, δεν είμαι καθόλου fun του ΜPI - το αντίθετο μάλιστα ! Τα μειονεκτήματα που απαρίθμησα ΔΕΝ ισχύουν όπως λες για οποιαδήποτε runtime βιβλιοθήκη διότι έχεις την ευχέρεια να ανταλλάξεις κατά βούληση την απόδοση με την ευκολία. Το ΜPI είναι άκαμπτο και μονολιθικό και δεν σου επιτρέπει να προσαρμόσεις τον τρόπο γραφής στη στάθμη σου. Αντίθετα, εξαναγκάζει εξαρχής σε κάποια πράγματα. Αυτή είναι η τεράστια διαφορά από το openMP. Τα μειονεκτήματά του είναι τόσο ανασταλτικά ώστε στις περισσότερες πρακτικές περιπτώσεις το καθιστούν ακατάλληλο. Για κάτι πραγματικά περίπλοκο δεν γίνεται λόγος. Για το τελευταίο, δεν αμφιβητώ αυτό που λες. Είπα ότι μου φαίνεται και λογικό ο παραλληλισμός ελέγχου να είναι γενικότερος. Ωστόσο, αυτό που έγραψα ως συμπέρασμα είναι αποδεδειγμένο - τουλάχιστον θεωρητικά - ακόμα και σε "απλά" προβλήματα. Το κόσκινο του Ερατοσθένη είναι ένα κλασικό παράδειγμα που θυμάμαι. Εν πάση περιπτώση, ούτε εδώ επιμένω πολύ διότι δεν είμαι ειδικός. Και δεν έχω μπλέξει το συλλογισμό μου - ξέρω ότι coarse grain και task parallelism δεν είναι ταυτόσημα. Το BSP μοιάζει πολύ με το MPI και μια φορά είχα πάρει από εκεί μια ιδέα που μου χρειάστηκε. Τέλος, μην ξεχνάς ότι μιλάμε κυρίως για εφαρμογές που τρέχουν σε κοινά μηχανήματα και γράφονται με συνήθη εργαλεία, όχι εξωτικές γλώσσες και μεγάλα clusters. Η άποψή μου ξεκινά και από αυτό. Αν κάποιος έχει τον deepBlue και πρέπει να φτιάξει πρόγραμμα που κάνει παγκόσμια πρόβλεψη καιρού ανά δυο μέρες, προφανώς θα έχει άλλα κριτήρια. -
V.I.Smirnov Δημοσ. 26 Οκτωβρίου 2010 Δημοσ. 26 Οκτωβρίου 2010 O debugger της Allinea είναι πράγματι καλός, τον έχω δει αλλά δεν μπόρεσα να τον βρω κλεψιμέικο, δυστυχώς ! Το totalview δεν το ξέρω. Ο cluster debugger που έχει το visual studio μου έκανε ζημιά όταν τον εγκατέστησα κάποτε : στην fortran όταν ήθελα να κάνω debug δεν έβλεπε το πάτημα του F5. Toν έβγαλα. Για τα υπόλοιπα που λες, γενικά συμφωνώ. Αλλά η εντύπωση που υπάρχει διάχυτη παντού είναι ότι γενικά το MPI είναι αυτό που κλιμακώνει καλύτερα. Το openMP αγωνίζεται να πείσει ότι είναι συναγωνίσιμο. Εσύ υποστηρίζεις το ανάποδο, δεν επιμένω αν το έχεις ψάξει, μακάρι να έχεις δίκιο : με κάνεις χαρούμενο, δεν είμαι καθόλου fun του ΜPI - το αντίθετο μάλιστα ! Τα μειονεκτήματα που απαρίθμησα ΔΕΝ ισχύουν όπως λες για οποιαδήποτε runtime βιβλιοθήκη διότι έχεις την ευχέρεια να ανταλλάξεις κατά βούληση την απόδοση με την ευκολία. Το ΜPI είναι άκαμπτο και μονολιθικό και δεν σου επιτρέπει να προσαρμόσεις τον τρόπο γραφής στη στάθμη σου. Αντίθετα, εξαναγκάζει εξαρχής σε κάποια πράγματα. Αυτή είναι η τεράστια διαφορά από το openMP. Τα μειονεκτήματά του είναι τόσο ανασταλτικά ώστε στις περισσότερες πρακτικές περιπτώσεις το καθιστούν ακατάλληλο. Για κάτι πραγματικά περίπλοκο δεν γίνεται λόγος. Για το τελευταίο, δεν αμφιβητώ αυτό που λες. Είπα ότι μου φαίνεται και λογικό ο παραλληλισμός ελέγχου να είναι γενικότερος. Ωστόσο, αυτό που έγραψα ως συμπέρασμα είναι αποδεδειγμένο - τουλάχιστον θεωρητικά - ακόμα και σε "απλά" προβλήματα. Το κόσκινο του Ερατοσθένη είναι ένα κλασικό παράδειγμα που θυμάμαι. Εν πάση περιπτώση, ούτε εδώ επιμένω πολύ διότι δεν είμαι ειδικός. Και δεν έχω μπλέξει το συλλογισμό μου - ξέρω ότι coarse grain και task parallelism δεν είναι ταυτόσημα. Το BSP μοιάζει πολύ με το MPI και μια φορά είχα πάρει από εκεί μια ιδέα που μου χρειάστηκε. Τέλος, μην ξεχνάς ότι μιλάμε κυρίως για εφαρμογές που τρέχουν σε κοινά μηχανήματα και γράφονται με συνήθη εργαλεία, όχι εξωτικές γλώσσες και μεγάλα clusters. Η άποψή μου ξεκινά και από αυτό. Αν κάποιος έχει τον deepBlue και πρέπει να φτιάξει πρόγραμμα που κάνει παγκόσμια πρόβλεψη καιρού ανά δυο μέρες, προφανώς θα έχει άλλα κριτήρια. -
dop Δημοσ. 26 Οκτωβρίου 2010 Δημοσ. 26 Οκτωβρίου 2010 Το OpenMP δημιουργήθηκε για απλό παραλληλισμό σε shared-memory συστήματα - που είναι. Το MPI σαν αντικαταστάτης των διαφόρων message passing βιβλιοθηκών για distributed memory συστήματα. Το μεγαλύτερο σύστημα shared memory που υπάρχει αυτή τη στιγμή είναι το Blacklight ( http://www.datacenterknowledge.com/archives/2010/10/12/blacklight-supercomputer-powers-up-in-pittsburgh/) με 4096 cores. Το μεγαλύτερο distributed memory είναι 224162 cores (http://www.top500.org/system/performance/10184). Από όσο καταλαβαίνεις στοχεύουν σε διαφορετικά μεγέθη. To OpenMP δεν πρόκειται ποτέ να κάνει scale σε τόσο μεγάλα συστήματα, πολύ απλά γιατί δε μπορούμε να κάνουμε coherent μηχάνημα με τόσα cores. Και η χρήση MPI για multicores είναι λίγο overkill. Είναι σαν να φέρνεις αεριωθούμενο σε αγώνα αυτοκινήτων - θα νικήσει, αλλά θέλει διάδρομο για να απογειωθεί. Ξαναλέω, το MPI εμφανίζεται πιο γρήγορο επειδή 1) κάνεις ένα fork πριν την αρχή και ένα join μετά το τέλος του προγράμματος και 2) εκμεταλεύεσαι το γεγονός ότι κάνεις copy τα αντικείμενα και όχι (true/false) share. Αν τα έχεις αυτά υπόψην σου, το MPI δε σου προσφέρει τίποτα παραπάνω. Παρόλα αυτά, και το OpenMP και το MPI είναι ανεπαρκή - δεν είναι αρκετά εκφραστικά και δεν παρέχουν στοιχειώδεις ευκολίες όπως προτυποποιημένες δομές δεδομένων και αλγορίθμους. Είναι η C των παράλληλων - αλλά χρειαζόμαστε πλέον μια STL. Όσο για την επίδοση task parallelism vs data parallelism, δεν υπάρχει θεωρητική απόδειξη από όσο ξέρω - αν γνωρίζεις σχετική δημοσίευση με ενδιαφέρει, αλλά μέχρι σήμερα δεν έχει τύχει να πέσει στα χέρια μου. Μπορεί να σου φανεί περίεργο, αλλά όταν πρόκειται για parallel programming, δεν είμαστε απλά speed freaks - θέλουμε τα προγράμματα να είναι scalable, επεκτάσιμα και κατανοητά. Αυτό μόνον το task parallelism μπορεί να μας το προσφέρει - περιγράφεις τον αλγόριθμο σαν tasks που έχουν εξαρτήσεις producer-consumer μεταξύ τους και ενίοτε data dependencies, το υλοποιείς αντίστοιχα και το runtime αναλαμβάνει να κάνει ότι καλύτερο για το καινούριο μηχάνημα. Το να χάσεις ένα 10% στην πορεία δεν είναι και τόσο τραγικό. Το data parallelism δε μπορεί να σου προσφέρει τίποτα από αυτά - είναι bounded από το μέγεθος του προβλήματός σου και data dependencies δεν μπορούν να εκφραστούν, μόνον να λυθούν εκ των προτέρων από τον προγραμματιστή - ή να χρησιμοποιήσεις κάποιο είδος mutual exclusion, υπογράφοντας παράλληλα τη διαθήκη σου. Δεν είναι τυχαίο που ΟΛΑ τα σύγχρονα συστήματα μας δίνουν task parallelism. Το ξέρω ότι το data parallelism είναι απλό και εύκολο για τον καθένα, αλλά δεν είναι η καλύτερη λύση, συγγνώμη. Προσωπικά δουλεύω πάνω σε task parallelism μόνον καθώς τα μειονεκτήματα του data parallelism είναι ήδη εμφανή. Η άποψή μου είναι λίγο biased, καθώς ο στόχος μου είναι τα 200Κ+ cores, όχι τα 4 και τα 8. Αλλά τα 8 cores σήμερα θα είναι ccNUMA συστήματα με 200+ cores αύριο, που στο μυαλό μου δε διαφέρουν και τόσο από ένα distributed memory σύστημα. Οπότε κοιτάμε λύσεις που θα δουλεύουν σήμερα και αύριο - όχι λύσεις που δούλευαν χθες και όχι αυτές που ίσως χρειαστούν σε 10 χρόνια.
dop Δημοσ. 26 Οκτωβρίου 2010 Δημοσ. 26 Οκτωβρίου 2010 Το OpenMP δημιουργήθηκε για απλό παραλληλισμό σε shared-memory συστήματα - που είναι. Το MPI σαν αντικαταστάτης των διαφόρων message passing βιβλιοθηκών για distributed memory συστήματα. Το μεγαλύτερο σύστημα shared memory που υπάρχει αυτή τη στιγμή είναι το Blacklight ( http://www.datacenterknowledge.com/archives/2010/10/12/blacklight-supercomputer-powers-up-in-pittsburgh/) με 4096 cores. Το μεγαλύτερο distributed memory είναι 224162 cores (http://www.top500.org/system/performance/10184). Από όσο καταλαβαίνεις στοχεύουν σε διαφορετικά μεγέθη. To OpenMP δεν πρόκειται ποτέ να κάνει scale σε τόσο μεγάλα συστήματα, πολύ απλά γιατί δε μπορούμε να κάνουμε coherent μηχάνημα με τόσα cores. Και η χρήση MPI για multicores είναι λίγο overkill. Είναι σαν να φέρνεις αεριωθούμενο σε αγώνα αυτοκινήτων - θα νικήσει, αλλά θέλει διάδρομο για να απογειωθεί. Ξαναλέω, το MPI εμφανίζεται πιο γρήγορο επειδή 1) κάνεις ένα fork πριν την αρχή και ένα join μετά το τέλος του προγράμματος και 2) εκμεταλεύεσαι το γεγονός ότι κάνεις copy τα αντικείμενα και όχι (true/false) share. Αν τα έχεις αυτά υπόψην σου, το MPI δε σου προσφέρει τίποτα παραπάνω. Παρόλα αυτά, και το OpenMP και το MPI είναι ανεπαρκή - δεν είναι αρκετά εκφραστικά και δεν παρέχουν στοιχειώδεις ευκολίες όπως προτυποποιημένες δομές δεδομένων και αλγορίθμους. Είναι η C των παράλληλων - αλλά χρειαζόμαστε πλέον μια STL. Όσο για την επίδοση task parallelism vs data parallelism, δεν υπάρχει θεωρητική απόδειξη από όσο ξέρω - αν γνωρίζεις σχετική δημοσίευση με ενδιαφέρει, αλλά μέχρι σήμερα δεν έχει τύχει να πέσει στα χέρια μου. Μπορεί να σου φανεί περίεργο, αλλά όταν πρόκειται για parallel programming, δεν είμαστε απλά speed freaks - θέλουμε τα προγράμματα να είναι scalable, επεκτάσιμα και κατανοητά. Αυτό μόνον το task parallelism μπορεί να μας το προσφέρει - περιγράφεις τον αλγόριθμο σαν tasks που έχουν εξαρτήσεις producer-consumer μεταξύ τους και ενίοτε data dependencies, το υλοποιείς αντίστοιχα και το runtime αναλαμβάνει να κάνει ότι καλύτερο για το καινούριο μηχάνημα. Το να χάσεις ένα 10% στην πορεία δεν είναι και τόσο τραγικό. Το data parallelism δε μπορεί να σου προσφέρει τίποτα από αυτά - είναι bounded από το μέγεθος του προβλήματός σου και data dependencies δεν μπορούν να εκφραστούν, μόνον να λυθούν εκ των προτέρων από τον προγραμματιστή - ή να χρησιμοποιήσεις κάποιο είδος mutual exclusion, υπογράφοντας παράλληλα τη διαθήκη σου. Δεν είναι τυχαίο που ΟΛΑ τα σύγχρονα συστήματα μας δίνουν task parallelism. Το ξέρω ότι το data parallelism είναι απλό και εύκολο για τον καθένα, αλλά δεν είναι η καλύτερη λύση, συγγνώμη. Προσωπικά δουλεύω πάνω σε task parallelism μόνον καθώς τα μειονεκτήματα του data parallelism είναι ήδη εμφανή. Η άποψή μου είναι λίγο biased, καθώς ο στόχος μου είναι τα 200Κ+ cores, όχι τα 4 και τα 8. Αλλά τα 8 cores σήμερα θα είναι ccNUMA συστήματα με 200+ cores αύριο, που στο μυαλό μου δε διαφέρουν και τόσο από ένα distributed memory σύστημα. Οπότε κοιτάμε λύσεις που θα δουλεύουν σήμερα και αύριο - όχι λύσεις που δούλευαν χθες και όχι αυτές που ίσως χρειαστούν σε 10 χρόνια.
Προτεινόμενες αναρτήσεις
Αρχειοθετημένο
Αυτό το θέμα έχει αρχειοθετηθεί και είναι κλειστό για περαιτέρω απαντήσεις.