Εφτιαξαν σούπερ υπολογιστή

[dop]

Αυτά και άλλα πολλά τα διαβάζω εδώ και καιρό, δεν έχουν καμία σημασία. Επίσης, θα μοιραστώ μαζί σου ότι στα τελευταία συνέδρεια πάνω σε High Performance Computing εμφανίζονται συνέχεια papers τα οποία ασχολούνται με το πως θα πρέπει να είναι ένα portable API για να προγραμματίσεις τον CellBE.

 

Σε αυτό το σημείο θα εξισώσω τον CellBE με τις GPU της nVidia και της AMD. Και τα δύο ακολουθούν παραπλήσιες αρχιτεκτονικές: ένας κύριος επεξεργαστής (ο εγκατεστημένος x86 για την nVidia και ένας PowerPC για την IBM), πολλά μικρά cores με ΔΙΑΦΟΡΕΤΙΚΟ instruction set από τον κύριο επεξεργαστή (cores στα chips της nVidia, SPEs για την IBM) και μνήμη διαθέσιμη μόνον για τα cores, η οποία υποστηρίζει DMA για την επικοινωνία κυρίως επεξεργαστή/cores (για την nVidia η μνήμη είναι shared, για την ΙΒΜ είναι distributed).

 

Παρόλες τις διαφορές που νομίζουμε ότι υπάρχουν είναι ένα και το αυτό: ένα μη ομοιογενές σύστημα που έχει απλά πολλούς επεξεργαστές. Και θέλει διαφορετικό compiler/optimizations/περιορισμούς στον κώδικα για κάθε τύπο. Σε ένα κόσμο που τα transistor είναι δωρεάν από άποψη κόστους αλλά πανάκριβα από άποψη ισχύος και όλα - μα όλα - τα συστήματα είναι memory και I/O bound, ο compiler είναι αυτός που κάνει την διαφορά (βλ. σύγκριση με gcc vs intel compiler http://www.luxrender.net/forum/viewtopic.php?f=21&t=603 παραπλήσια αποτελέσματα έχω και εγώ στον δικό μου κώδικα και επιπλέον θα μεταφέρω ότι ο compiler της IBM xl C, παράγει ταχύτερο κώδικα για PowerPC αρχιτεκτονικές). Να τονίσω ότι για τον ταχύτερο υπερυπολογιστή στον κόσμο αυτή τη στιγμή, τον Roadrunner, πρέπει να έχεις κώδικα και compilers για τρεις διαφορετικούς επεξεργαστές: έναν Opteron, έναν PowerPC και για τα SPEs. Είναι γρήγορο; Ναι. Είναι εύκολο να προγραμματιστεί; Δυστυχώς όχι, θέλεις μια στρατιά από ερευνητές με PhD στο high performance computing. Το δεύτερο μηχάνημα στη λίστα είναι το Cray Jaguar. Opterons συνδεδεμένοι με πολύ γρήγορο interconnect. Ένας compiler, ένας κώδικας.

 

Επιπλέον, και τα δύο, GPUs και Cell, έχουν ανάγκη από ένα μοντέλο explicit parallelism:

>
// ...
μετέφερε δεδομένα στον/στους συνεπεξεργαστές
τρέξε αυτόν τον κώδικα με τα δεδομένα
κάνε κάτι άλλο όσο περιμένεις να τελειώσει
πάρε δεδομένα από τον/τους συνεπεξεργαστές πίσω

Θα τονίσω τις μεταφορές από και προς στη μνήμη. Όποιος θα έχει ακούσει για το memory wall θα έπρεπε να τον ενοχλεί αυτό. Αυτός είναι ο λόγος που στο site του jacket λένε πως καλύτερα να χρησιμοποιείς μόνον συναρτήσεις με το πρόθεμα g ώστε να αποφεύγεις τις άσκοπες αντιγραφές μνήμης.

 

Θα αντιπαραβάλλει κανείς πως ΟΚ, θα τα μεταφέρω όλα στην τοπική μνήμη και θα είναι όλα εντάξει. Και αν το data size ξεπερνάει την μνήμη; Καλύτερη κάρτα με περισσότερη. Και αν είναι gigabytes δεδομένων; Αναγκαστικά θα πρέπει να έχεις κάποιο μοντέλο streaming δεδομένων ή data prefetching, άρα και πάλι δε γλυτώνεις τις επιπλέον αντιγραφές.

 

Από την άλλη shared memory με ίδιους επεξεργαστές όπως ένας Quad Core, δεν θέλει δύο διαφορετικούς compilers και δε θέλει αντιγραφές δεδομένων. Όταν θα βγει το Larrabee που θα έχει x86 cores, αντίστοιχα με τον απλό Pentium του 93, με τον compiler της Intel, θα ήθελα να δω που θα στέκεται απέναντι στον ίδιο αριθμό cores της nVidia. Αλλά και πάλι, αυτή είναι σύγκριση αρχιτεκτονικών, που λίγη σχέση έχουν με την πραγματικότητα.

 

Όσο το πρόγραμμα σου είναι: τρέξε "αυτό" παράλληλα, τότε όσο θα προσθέτεις πυρήνες θα αυξάνεται η ταχύτητα, μέχρι να φτάσεις στον ίδιο αριθμό με τον αριθμό των παράλληλων tasks σου (το task είναι το "αυτό"). Αυτό ίσως δε γίνει ποτέ, αλλά ας σκεφτούμε πρώτα πόσοι αλγόριθμοι έχουν τόσα tasks τα οποία είναι και ανεξάρτητα μεταξύ τους. Τι θα γίνει αν έχεις έναν περίπλοκο γράφο εξαρτήσεων (task dependency graph); Πώς προγραμματίζεται αυτό σε CUDA, σε CellBE, σε MPI; Φυσικά ο κοινός προγραμματιστής δεν έχει ιδέα από αυτά, όχι γιατί φταίει ή είναι ανίκανος, απλά επειδή το να γράφεις παράλληλους αλγορίθμους είναι μια μυστική τέχνη για τους λίγους εκλεκτούς (το σχόλιο είναι κυνικό για τα προγράμματα σπουδών σε σχολές πληροφορικής που αγνοούν οτιδήποτε παράλληλο μια και 1) οι καθηγητές δεν ξέρουν και 2) είναι δύσκολο να το διδάξεις αποδοτικά σε έναν προπτυχιακό).

 

Άρα επιστρέφω στην αρχική παρατήρησή μου και ένστασή μου: ναι, με το CUDA σήμερα θα έχεις ταχύτερη εκτέλεση επειδή και μόνον: 1) ο προγραμματιστής ανακάλυψε τι σημαίνει να τρέχεις κάτι παράλληλα και 2) έχει στη διάθεση του πολλούς πυρήνες. Όταν σε λιγότερο από χρόνο όμως θα τελειώσουν με τους απλούς αλγορίθμους και οι πυρήνες θα είναι τόσοι πολλοί που δε θα υπάρχουν αρκετά tasks για να τους γεμίσουν όλους, πάλι θα αναρωτιόμαστε τα ίδια, πως κάνουμε κάτι να τρέξει πιο γρήγορα. Η ημιμάθεια είναι χειρότερη της άγνοιας.

 

Ξέρει η nVidia να κάνει ταχύτερα cores κατά 50% CPUs από Intel/AMD; Γιατί μόνον τότε θα μπορεί να συναγωνιστεί, με ένα 20-30% δεν γίνεται τίποτα. Και θα το πάω ακόμα παραπέρα: ποιος θα είναι πιο ικανός, η Intel με τον δικό της compiler που προσφέρει automatic parallelization του κώδικα στην έκδοση 11, η AMD που επενδύει στον gcc ή η nVidia με το κλειστό σύστημα; Και που στέκεται η nVidia όταν θα έχουμε 128 Atom-like cores σε ένα chip;

 

Τώρα ξαναθέτω την ερώτηση: πόσο διατεθιμένος είναι ο καθένας να ξεκινήσει να μεταφέρει τον κώδικά του σε CUDA, κάνοντάς τον εξαιρετικά δύσκολα συντηρήσιμο και πιθανώς αδύνατον να τρέξει σε κάτι μη-nVidia; Η nVidia θέλει να πουλήσει το προϊόν της και πολύ καλά κάνει - δεν είναι άσχημο και αν το χρησιμοποιήσεις σωστά, έχεις την ταχύτητα. Αλλά άλλο αυτό και άλλο να προτρέπουμε τον καθένα "χρησιμοποίησε και εσύ CUDA, μπορείς".

 

To jacket είναι στην σωστή κατεύθυνση: αυτό είναι το απλό API μας και χρησιμοποίησέ το για να δεις ταχύτητα. Και αύριο που κάποιος άλλος θα βγει με κάτι άλλο, θα αλλάξουμε το runtime μας και θα το κάνουμε συμβατό με εκείνο και εσύ δε θα αλλάξεις κάτι.

 

Θα κλείσω ότι θα πρέπει να βλέπουμε τα CUDA, OpenMP, MPI, Cell API, OpenCL κλπ σαν την assembly του παράλληλου προγραμματισμού - δηλαδή είναι καλές για πρώτα βήματα, αλλά όχι η λύση.

[FarCry]

βεβαια μονο με την assembly μπορείς να κανεις παπάδες optimisations. με high level languages όχι και τόσο...

[dop]

βεβαια μονο με την assembly μπορείς να κανεις παπάδες optimisations. με high level languages όχι και τόσο...

 

Αν ξέρεις πόσο είναι το cache line size, να γράφεις τον κώδικα έτσι ώστε να μειώνεται το branch prediction failure, να ξέρεις το dependency μεταξύ των διαφορετικών υπομονάδων ώστε να εκμεταλεύεσαι πλήρως το Instruction Level Parallelism και να ξέρεις πότε να σταματήσεις το loop unrolling και πως να κάνεις instruction reordering, τότε ναι μπορείς να κάνεις παπάδες.

[dark_banishing]

Αν ξέρεις πόσο είναι το cache line size, να γράφεις τον κώδικα έτσι ώστε να μειώνεται το branch prediction failure, να ξέρεις το dependency μεταξύ των διαφορετικών υπομονάδων ώστε να εκμεταλεύεσαι πλήρως το Instruction Level Parallelism και να ξέρεις πότε να σταματήσεις το loop unrolling και πως να κάνεις instruction reordering, τότε ναι μπορείς να κάνεις παπάδες.

 

Αυτό το κάνω copy paste να το έχω, γιατί είναι απίστευτα εύστοχο και γιατί το να πετάς σχόλια "μόνο με assembly μπλα μπλα" έχει γίνει πολύ της μόδας.

[FarCry]

Αυτό το κάνω copy paste να το έχω, γιατί είναι απίστευτα εύστοχο και γιατί το να πετάς σχόλια "μόνο με assembly μπλα μπλα" έχει γίνει πολύ της μόδας.

 

μα εννοείται ότι χρησιμοποιείς assembly για optimisations μονο. αλλιώς δε σου χρειάζεται. οποτε πρέπει να γνωρίζεις και κάποια πράγματα ώστε να κανεις optimisation. σε μη παράλληλο επίπεδο είναι πιο εύκολο.

 

μερικά απλά παραδείγματα

 

http://www.mark.masmcode.com/

[grimpr]

Cuda/Stream/OpenCL κτλπ απλά σημαίνουν το τέλος της CPU ως αποκλειστικής πλατφόρμας και την άνοδο του οικιακού personal computer σε HPC επίπεδα. Το μέλλον ανήκει στις GPU σύμφωνα με την academia. Και θα είναι αρκετά ενδιαφέρον με το hardware που ετοιμάζεται από NV και ATI (500gb/s bandwidth/8GB RAM) σε συνδυασμό με την υιοθέτηση της Cuda και την εξέλιξη της (OpenCL). Cuda 3.0/Differential GDDR5 και άλλα πολλά...προσδεθείτε.

[dop]

Το συγκεκριμένο paper το είχα διαβάσει πριν 1 περίπου χρόνο, αλλά δε θυμάμαι να λέει πουθενά ότι το μέλλον ανήκει στις GPUs (σημ. ο όρος GPGPU είναι καθαρά όρος marketing, καθώς στην ουσία πρόκειται για ένα multicore chip με διαφορετική αρχιτεκτονική από x86). Μιλάει γενικά για heterogeneous cores σε ένα chip, κοινώς ένα manycore chip.

 

Μια καλή λύση που θυμήθηκα για "εύκολο" προγραμματισμό accelerators (μια GPU πλέον θεωρείται accelerator) είναι η http://www.caps-entreprise.com/hmpp.html που επιτρέπει OpenMP-like annotated code να μετατρέπεται σε CUDA, OpenCL, Cell κλπ

[grimpr]

Τα 2 ακόλουθα links πιστεύω είναι χρήσιμα.

 

http://portal.acm.org/citation.cfm?id=1400181.1400197

 

http://s08.idav.ucdavis.edu/

[cosmosfera]

Καλο ειναι να εμφανιζονται και εναλλακτικες αλλα δε βλεπω μελλον.

Καταρχην για οικιακη χρηση ειναι ακυρο γιατι το ρευμα που καιει ειναι απαραδεκτο.

Απο εκει και περα στο τομεα των υπερυπολογιστων απο αυτα που διαβασα παιδια εχει σοβαρα προβληματα συμβατοτητας και θελει πολυ εξειδικευμενο γραμμενο κωδικα για να αποδωσει.Αμφιβαλλω οτι θα κατσουν να γραψουν τετοιο κωδικα σε ικανοποιητικη κλιμακα για μια πλατφορμα της nvidia...

Επισης δεδομενης της λογικης της intel και της amd να δινουν τη καινοτομια με το σταγονομετρο αφου πρωτα βγαζουν κατι περιμενουν να το πουλησουν και μολις κορεστει η αγορα πετανε κατι καινουριο, αμα σφιξουν τα πραγματα θα βγαλουν κανα 16 πυρηνο επεξεργαστη και θα τελειωσει το παραμυθι.

Παντως για λυση σε εξειδικευμενες εφαρμογες ειναι καλη λυση...

Ακομα καλυτερο ειναι το οτι ισως πιεζει τις intel,amd

[dop]

Ποια προβλήματα συμβατότητας διάβασες ακριβώς; Όχι, φυσικά δεν θα έχει ο καθένας ένα Tesla Supercomputer στο γραφείο του. Αλλά σε 2-3 χρόνια θα είναι φυσιολογικό να βλέπουμε κάποιες από τις τεχνολογίες που χρησιμοποιούνται σε supercomputers στα PC μας. Σε μια δεκαετία δε θα θυμόμαστε καν ότι το μηχανάκι μας έχει τεχνολογίες που άξιζαν εκατομμύρια.

 

Α, ναι, επιπλέον δεν ξέρουν πως να φτιάξουν ακόμα φτηνό 16πύρηνο επεξεργαστή που να εκτελεί τις σημερινές εφαρμογές αποδοτικά, οπότε μην τους κατηγορείς άδικα.

[FarCry]

Ποια προβλήματα συμβατότητας διάβασες ακριβώς; Όχι, φυσικά δεν θα έχει ο καθένας ένα Tesla Supercomputer στο γραφείο του. Αλλά σε 2-3 χρόνια θα είναι φυσιολογικό να βλέπουμε κάποιες από τις τεχνολογίες που χρησιμοποιούνται σε supercomputers στα PC μας. Σε μια δεκαετία δε θα θυμόμαστε καν ότι το μηχανάκι μας έχει τεχνολογίες που άξιζαν εκατομμύρια.

 

Α, ναι, επιπλέον δεν ξέρουν πως να φτιάξουν ακόμα φτηνό 16πύρηνο επεξεργαστή που να εκτελεί τις σημερινές εφαρμογές αποδοτικά, οπότε μην τους κατηγορείς άδικα.

 

από ότι έχω διαβάσει οι περισσότερες εφαρμογές μέχρι 8 threads αντέχουν. λίγες είναι αυτές που πάνε σε 16 και ελάχιστες παραπάνω. πιο γρήγορα πάει το hardware παρα το software σε παραλληλοποιηση....

[dop]

Μόλις τελείωσα τα "tips" που έχει στο http://www.mark.masmcode.com/ : ένα συνοθύλευμα από χρήσιμες, άχρηστες και επιβλαβείς για την ταχύτητα συμβουλές. Δεν ξέρω ποιος είναι ο Mark Larson, αλλά θα ήμουν εξαιρετικά διστακτικός να χρησιμοποιήσω οτιδήποτε, πλην των tips για MMX - εκεί είναι γνωστό ότι οι compilers πάσχουν, με εξαίρεση της Intel που συνήθως βγάζει τον σωστό κώδικα για τους επεξεργαστές της. Δεν έχει πουθενά μια σύγκριση του εκτελέσιμού του με τα optimizations σε σχέση με αυτό που δίνουν οι compilers. Ίσως η μόνη αλήθεια είναι η πρώτη φράση "The most important thing to remember is to TIME your code."

 

Δεν είναι ότι αντέχουν τόσα threads - είναι ότι οι προγραμματιστές δεν ξέρουν να παραλληλίζουν σωστά ή έστω κάπως βασικά, οπότε κάνουν αλχημείες που να μεν δουλεύουν προσωρινά αλλά στο βάθος χρόνου έχουν πρόβλημα. Θα το πάω πιο μακριά: το 75% των εφαρμογών χρησιμοποιούν threads για να κρύβουν το latency, όχι για να αυξάνουν την ταχύτητα (δηλαδή κυρίως για I/O). Από την άλλη όλοι οι αλγόριθμοι που έχουν είναι κλασικοί σειριακοί.

[A_gamer]

εχει σοβαρα προβληματα συμβατοτητας και θελει πολυ εξειδικευμενο γραμμενο κωδικα για να αποδωσει

 

That's CUDA for you...

[FarCry]

A breakthrough for computational researchers, the Tesla™ Personal Supercomputer delivers computing performance up to 250 times faster than standard PCs and workstations. Based on the revolutionary NVIDIA CUDA™ parallel computing architecture, it has nearly 4 teraflops of computing muscle and is powered by up to 960 parallel processing cores to solve the most complex computational problems.

 

 

[grimpr]

Το είπαμε, οι cpus ποτέ δεν πρόκειται να φτάσουν την υπολογιστή ισχύ των GPU για συγκεκριμένα tasks, η academia προβλέπει wall στις cpu απο 16-32 πυρήνες, από κει και πέρα οι βελτιώσεις θα ειναι ελάχιστες. To μέλλον είναι ξεκάθαρα στο manycore (1000+) parallel computing με τις GPU απο NV και ATI και με την επίσημη κυκλοφορία του OpenCL 1.0 τα πράγματα αλλάζουν ριζικά. Η επόμενη μεγάλη κίνηση στις CPU είναι το Fusion της AMD, που εάν αποδειχτεί πραγματικότητα και όχι αέρας κοπανιστός, θα φέρει την οριστική σύγκλιση της CPU με την GPU. Αν ολοκληρωθεί μέσα στο 2011, θα καταδειχτεί για άλλη μια φορά ότι η AMD σχεδιάζει την επόμενη αρχιτεκτονική της Intel.