Π Τ Υ Χ Ι Α Κ Η Ε Ρ ΓΑ Σ Ι Α

Transcript

1 Α Ρ Ι Σ Τ Ο Τ Ε Λ Ε Ι Ο Π Α Ν Ε Π Ι Σ Τ Η Μ Ι Ο Θ Ε Σ Σ Α Λ Ο Ν Ι Κ Η Σ ΣΧΟΛΗ ΘΕΤΙΚΩΝ ΕΠΙΣΤΗΜΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ Π Τ Υ Χ Ι Α Κ Η Ε Ρ ΓΑ Σ Ι Α «ΠΡΟΣΑΡΜΟΣΙΜΗ ΕΠΕΞΕΡΓΑΣΙΑ ΡΟΩΝ ΔΕΔΟΜΕΝΩΝ ΜΕ ΧΡΗΣΗ ΚΑΡΤΑΣ ΓΡΑΦΙΚΩΝ» ΚΟΥΤΣΟΥΜΠΑΚΗΣ ΓΕΩΡΓΙΟΣ ΚΟΥΤΣΟΥΜΠΑΚΗΣ ΙΑΚΩΒΟΣ ΕΠΙΒΛΕΠΩΝ ΚΑΘΗΓΗΤΗΣ: ΑΝΑΣΤΑΣΙΟΣ ΓΟΥΝΑΡΗΣ, ΛΕΚΤΟΡΑΣ ΘΕΣΣΑΛΟΝΙΚΗ 2012

2 2

3 Περιεχό μενα Λίστα Σχημάτων... 5 Εισαγωγή... 6 Κεφάλαιο 1 - Περιγραφή του προβλήματος Εισαγωγή Περιγραφή... 7 Κεφάλαιο 2 - Περιγραφή του υλικού Γενικά Η αρχιτεκτονική Fermi Ταυτόχρονη εκτέλεση πυρήνα Ιεραρχία μνήμης Υλικό που χρησιμοποιήθηκε Κεφάλαιο 3 - Σχετική Έρευνα To FLUX Εισαγωγή Load-Balancing σε παράλληλα συστήματα Επεξεργασία δεδομένων στην κάρτα γραφικών Το FLUX Μακροπρόθεσμη εξισορρόπηση Κεφαλαιο 4 - Περιγραφή του προγράμματος Εισαγωγή Ενέργειες της CPU Ενέργειες της GPU Kεφάλαιο 5 - Πρόκληση ανισορροπίας Εισαγωγή Ανισορροπία σε επίπεδο thread Κεφάλαιο 6 - Εξισορρόπηση Φόρτου Εξισορρόπηση σε επίπεδο thread Ανίχνευση ανισοκατανομής Προσπάθεια εξισορρόπησης Τυχαία μετακίνηση του πρώτου Μετακίνηση της πιο συχνής ομάδας Μετακίνηση μιας συχνής ομάδας πιθανοκρατικά Μετακίνηση της βέλτιστης ομάδας Σύγκριση με το FLUX

4 Κεφάλαιο 7 - Αποτελέσματα Πειραμάτων Κόστος εξισορρόπησης Σύγκριση με CPU Επίλογος Βιβλιογραφία Ακρωνύμια Γλωσσάριο Αγγλικά Ελληνικά Κώδικας

5 Λι στα Σχημα των Εικόνα 1 - Τα μέρη που αποτελούν μια τυπική κάρτα γραφικών που υποστηρίζει CUDA... 9 Εικόνα 2 - Η ροή ενός τυπικού προγράμματος σε CUDA Εικόνα 3 - Σειριακή και Παράλληλη εκτέλεση διαφορετικών πυρήνων Εικόνα 4 - Η ιεραρχία μνήμης σε FERMI Εικόνα 5 - Πειραματικά αποτελέσματα του Flux Εικόνα 6 - Ο πίνακας με τις νέες πλειάδες χωρισμένες με βάση το thread που θα τις αναλάβει, καθώς και ο πίνακας δεικτοδότησης Εικόνα 7 - Οι πίνακες που βρίσκονται στην κύρια μνήμη της κάρτας Εικόνα 8 - Παράδειγμα ανισοκατανομής φόρτου σε 5 threads Εικόνα 9 - Χρόνος εκτέλεσης χωρίς εξισορρόπηση φόρτου σε ομοιόμορφη και zipf κατανομή Εικόνα 10 - Σύγκριση χρόνου σε zipf κατανομή Εικόνα 11 - Σύγκριση χρόνου σε zipf κατανομή με χρονοβόρα πράξη Εικόνα 12 - Χρόνος εκτέλεσης συναρτήσει της παραμέτρου στην probcheck Εικόνα 13 - Κλιμάκωση του χρόνου εκτέλεσης του με εξισορρόπηση Εικόνα 14 - Καθυστέρηση που προσθέτει το Load-Balancing Εικόνα 15 - Σύγκριση χρόνου εκτέλεσης μεταξύ CPU-GPU

6 Εισαγωγη Η ραγδαία αύξηση της ποσότητας των δεδομένων που παρατηρείται καθιστά την επεξεργασία τους δύσκολη. Τα παραδοσιακά συστήματα σειριακής επεξεργασίας προσεγγίζουν τα όρια της επεξεργαστικής τους ισχύος, με αποτέλεσμα να μην μπορούν να επιτύχουν αποδοτικά και σε μικρό χρονικό διάστημα τη διεκπεραίωση ενεργειών πάνω στο σύνολο των δεδομένων. Σημειώνεται, επομένως, μια γενικευμένη απομάκρυνση από συμβατικές μεθόδους σειριακής επεξεργασίας και εκμετάλλευση των δυνατοτήτων της παράλληλης επεξεργασίας, με σκοπό την αύξηση της διεκπεραιωτικής ικανότητας και την επίτευξη καλύτερης κλιμάκωσης των μεθόδων. Πολλές επιλογές που εκμεταλλεύονται παράλληλη και κατανεμημένη επεξεργασία είναι πλέον διαθέσιμες, με σημαντικές διαφοροποιήσεις σχετικά με το απαιτούμενο υλικό και λογισμικό. Ανάμεσα σε αυτές ξεχωρίζει η τεχνολογία CUDA (Compute Unified Device Architecture) της εταιρίας NVidia, μια αρχιτεκτονική η οποία επιτρέπει την εκτέλεση κώδικα στους επεξεργαστές της κάρτας γραφικών, καθιστώντας τον παραλληλισμό προσιτό σε κάθε ενδιαφερόμενο. Προσφέρει λύσεις για μια κλίμακα από μικρά έως πολύ μεγάλα προβλήματα, αξιοποιώντας την τεράστια επεξεργαστική ισχύ των καρτών γραφικών. Πολλές είναι οι εφαρμογές του παραλληλισμού της CUDA στον τομέα των βάσεων δεδομένων, με σημαντική έρευνα να έχει πραγματοποιηθεί τα τελευταία χρόνια προκειμένου να γίνει αποδοτική χρήση των καρτών γραφικών για διαχείριση του μεγάλου όγκου των δεδομένων. Μια σημαντική εφαρμογή είναι και η αξιοποίηση του παραλληλισμού για εκτέλεση συναθροιστικών ερωτημάτων σε μεγάλο πλήθος δεδομένων. Σκοπός της εργασίας είναι να αναδείξει τις επεξεργαστικές δυνατότητες των καρτών γραφικών σε συναθροιστικά ερωτήματα βάσεων δεδομένων και να αποτιμήσει τα οφέλη του παραλληλισμού. Τέλος, στοχεύει στο να αντιμετωπίσει το πρόβλημα της ανισορροπίας φόρτου που μπορεί να παρουσιαστεί λόγω κακού παραλληλισμού. 6

7 Κεφα λαιό 1 - Περιγραφη τόυ πρόβλη ματός 1.1 Εισαγωγή Σημαντικό ενδιαφέρον για τον κλάδο των βάσεων δεδομένων παρουσιάζουν τα ερωτήματα σε συνεχή ροή δεδομένων. Σε αυτά, οι πλειάδες των δεδομένων δεν είναι από την αρχή όλες μαζί διαθέσιμες για επεξεργασία, αλλά έρχονται συνεχώς νέες, αποτελούν δηλαδή μια συνεχή ροή (stream) δεδομένων, για παράδειγμα τα δεδομένα που επιστρέφει ένας μετρητής θερμοκρασίας σε σταθερά χρονικά διαστήματα. Αυτά τα δεδομένα υφίστανται κάποιας μορφής επεξεργασίας, όπως ομαδοποίηση με τελεστή group-by. Σε αυτή τη περίπτωση, όλες οι πλειάδες κατηγοριοποιούνται με βάση ένα χαρακτηριστικό τους σε κάποια ομάδα και εφαρμόζεται κάποια πράξη, όπως άθροισμα, σε κάθε ομάδα ξεχωριστά. Καθώς έχουμε ροή δεδομένων, δεν είναι εφικτό το να διατηρούμε το σύνολό των δεδομένων στη μνήμη, καθώς έχει περιορισμένο μέγεθος, αλλά αντίθετα κρατάμε μόνο ένα μέρος τους, μέσα σε ένα παράθυρο. Υπάρχουν δυο διαφορετικά είδη παραθύρων, αυτά του σταθερού μήκους και αυτά με το σταθερό χρόνο. Ένα παράθυρο σταθερού μήκους μπορεί να κρατήσει ένα συγκεκριμένο αριθμό τιμών για κάθε ομάδα. Έτσι, όταν το παράθυρο γεμίσει, για κάθε νέα πλειάδα που πρέπει να προστεθεί θα απομακρυνθεί η παλαιότερη. Αντίθετα, το χρονικό παράθυρο δεν έχει συγκεκριμένο μέγεθος. Εκεί, κάθε νέα πλειάδα αποθηκεύεται στο σύστημα για ένα συγκεκριμένο χρονικό διάστημα. Όταν ο χρόνος αυτός εκπνεύσει, η πλειάδα διαγράφεται. 1.2 Περιγραφή Στα πλαίσια της διπλωματικής εργασίας υλοποιήθηκε πρόγραμμα που εκτελεί ένα group by ερώτημα με παράθυρο σταθερού μήκους σε μια ροή δεδομένων, εκμεταλλευόμενο τον παραλληλισμό και την επεξεργαστική ισχύ των καρτών γραφικών, στα πλαίσια του gpgpu (General-Purpose computing on Graphics Processing Unit προγραμματισμός γενικής χρήσης στην κάρτα γραφικών), που αποτελεί την τάση για την εκτέλεση κώδικα στην κάρτα γραφικών, με σκοπό την μείωση του φόρτου του επεξεργαστή. 7

8 Οι πλειάδες έχουν σταθερή δομή και αποτελούνται από δύο ιδιότητες, το group, το οποίο το κατηγοριοποιεί σε μιά ομάδα και μια τιμή value. Σκοπός είναι να γίνει διαχωρισμός των πλειάδων με βάση την ομάδα, ώστε να εκτελεστεί κάποια πράξη στις πλειάδες των ίδιων ομάδων. Η πράξη αυτή, η οποία μπορεί να είναι οποιαδήποτε πράξη πάνω σε ένα σύνολο δεδομένων, όπως για παράδειγμα πρόσθεση, μέσος όρος, εύρεση μέγιστης ή ελάχιστης τιμής κλπ, πραγματοποιείται όταν προστίθεται μια νέα πλειάδα. Η εκμετάλλευση του παραλληλισμού συντελεί στο να αναλάβει το κάθε thread ένα συγκεκριμένο σύνολο από ομάδα, ενώ πολλά threads θα αναλάβουν να επεξεργαστούν το σύνολο των δεδομένων παράλληλα. Τα πλεονεκτήματα που έχουμε από μια τέτοια ανάθεση εργασιών είναι πολλά, καθώς, όχι μόνο επιτυγχάνουμε παράλληλη άρα και ταχύτερη επεξεργασία των πλειάδων της εισόδου, αλλά και εκτελούμε τις υπολογιστικά ακριβές πράξεις στην κάρτα γραφικών, μειώνοντας το φόρτο του επεξεργαστή, επιτρέποντας του να εκτελέσει άλλες ενέργειες. Έτσι, ευνοείται το σύστημα στο σύνολο και μειώνοντας το χρόνο που απαιτείται για να ολοκληρωθεί η διαδικασία. Επιπλέον, με τη μεταφορά της επεξεργασίας στην κάρτα γραφικών επιτυγχάνεται καλύτερη κλιμάκωση όταν μεγαλώσει το πρόβλημα. Σημαντικό πρόβλημα δημιουργείται ωστόσο, καθώς πρέπει να υπάρχει κάποιος μηχανισμός που να διασφαλίζει ότι ο διαμοιρασμός του φόρτου στα διάφορα threads θα γίνεται ομοιόμορφα, καθώς, λόγω της συνεχούς ροής δεδομένων, η κατανομή τους μπορεί να αλλάζει με την πάροδο του χρόνου. Μας ενδιαφέρει, επομένως, να ανιχνεύουμε και να αντιμετωπίζουμε περιπτώσεις ανισορροπίας φόρτου, καταστάσεις, δηλαδή, όπου κάποια threads επιβαρύνονται με μεγάλο ποσοστό της συνολικής επεξεργασίας, ενώ άλλα αδρανούν. Τέτοιες περιπτώσεις προκαλούν αύξηση του χρόνου ολοκλήρωσης της επεξεργασίας, ενώ σε ακραίες περιπτώσεις μπορούν να οδηγήσουν σε συνθήκες σειριακής εκτέλεσης σε ένα thread, με τεράστιες επιπτώσεις στο απαιτούμενο χρόνο. Στα επόμενα κεφάλαια, και συγκεκριμένα στα κεφάλαια 2 και 3 γίνεται μια αναλυτική περιγραφή του υλικού και των τεχνολογιών που χρησιμοποιήθηκαν για την υλοποίηση της πτυχιακής, καθώς και μια περιγραφή του εργαλείου FLUX στο οποίο στηρίχθηκε η αντιμετώπιση της ανισοκατανομής φόρτου. Έπειτα, στο κεφάλαιο 4 περιγράφεται ο τρόπος με τον οποίο αναπτύχθηκε ο κώδικας της εργασίας και οι δομές που χρησιμοποιήθηκαν, ενώ ακόμα αναλύεται ο τρόπος με τον οποίο αξιοποιήθηκε στο βέλτιστο το υλικό, προκειμένου να αποφευχθούν οι αδυναμίες και τα bottlenecks που θέτει. Στα κεφάλαια 5 και 6 αναλύεται και επιλύεται το πρόβλημα της ανισοκατανομής φόρτου που εμφανίζεται, ενώ τέλος, στο κεφάλαιο 7 αποτιμώνται οι εφαρμογές της εξισορρόπησης φόρτου μεταξύ threads στην πράξη, με εξαγωγή μετρήσεων του χρόνου εκτέλεσης. 8

9 Κεφα λαιό 2 - Περιγραφη τόυ υλικόυ 2.1 Γενικά Η Compute Unified Device Architecture (CUDA) είναι μια αρχιτεκτονική παράλληλης επεξεργασίας που αναπτύχθηκε από την NVidia και αξιοποιεί την επεξεργαστική ισχύ και τη δυνατότητα παραλληλισμού των σύγχρονων καρτών γραφικών. Για την υλοποίηση προγραμμάτων που βασίζονται σε CUDA, xρησιμοποιούνται βιβλιοθήκες που επεκτείνουν τις δυνατότητες των διαφόρων γνωστών γλωσσών προγραμματισμού, όπως για παράδειγμα, C, Java, Fortran κ.α, προσθέτοντας εντολές για τον έλεγχο της κάρτας γραφικών. Τα μέρη της κάρτας γραφικών που είναι σχετικά με το GPGPU προγραμματισμό φαίνονται στην Εικόνα 1. H GPU αποτελείται από ένα σύνολο SIMD (Single instruction stream, multiple data streams) πολυπεξεργαστών (Streaming Multiprocessors). Σε κάθε χτύπο του ρολογιού, κάθε επεξεργαστής από έναν SM εκτελεί την ίδια εντολή, αλλά την εφαρμόζει πάνω σε διαφορετικά δεδομένα. Μια κάρτα γραφικών επιτρέπει την ταυτόχρονη εκτέλεση εκατοντάδων thread. Σημαντική παρατήρηση είναι το γεγονός ότι, σε αντίθεση με τα threads μιας κλασικής κεντρικής μονάδας επεξεργασίας, τα threads αυτά έχουν πολύ μικρό χρόνο δημιουργίας και η καθυστέρηση που προκύπτει για την εναλλαγή μεταξύ τους είναι μικρή. Εικόνα 1 - Τα μέρη που αποτελούν μια τυπική κάρτα γραφικών που υποστηρίζει CUDA Πηγή: Relational Query Co-Processing on Graphics Processors [4] Τα threads που εκτελούνται σε έναν πολυεπεξεργαστή είναι οργανωμένα σε ομάδες (blocks), με τα threads που ανήκουν στην ίδια ομάδα να μοιράζονται τους επεξεργαστικούς και άλλους πόρους, όπως είναι οι καταχωρητές σε έναν SM. Μια τέτοια ομάδα χωρίζεται σε πολλαπλά στημόνια (warps), τα οποία δυναμικά 9

10 ανατίθενται στους πολυεπεξεργαστές για να εκτελεστούν. Λόγω των περιορισμών της εκτέλεσης SIMD, αν απαιτηθεί τα νήματα στο ίδιο στημόνιο να εκτελέσουν διαφορετικές ενέργειες, όπως για παράδειγμα να ακολουθήσουν διαφορετικούς κλάδους εκτέλεσης, τότε αυτές οι ενέργειες θα εκτελεστούν σειριακά και όχι παράλληλα. Επιπλέον, αν ένα νήμα έχει σταματήσει αναμένοντας για δεδομένα από την καθολική μνήμη, θα σταματήσουν και τα υπόλοιπα της ίδιας ομάδας, μέχρι να ολοκληρωθεί η ανάγνωση. Η μνήμη της κάρτας γραφικών έχει συνήθως μέγεθος εκατοντάδων megabyte. Έχει πολύ μεγάλο εύρος ζώνης, αλλά και μεγάλη καθυστέρηση για αιτήσεις ανάγνωσης ή εγγραφής. Για παράδειγμα, μια GPU απαιτεί για προσπέλαση μνήμης περίπου 200 κύκλους ρολογιού, ενώ η ταχύτητα μεταφοράς είναι περίπου 86 GB/sec. Λόγω της ιδιότητας SIMD, η GPU μπορεί να συγχωνεύσει αιτήσεις για πρόσβαση στη μνήμη, προκειμένου να αξιοποιήσει τη χωρική τοπικότητα ανάμεσα στα threads: όταν μια ομάδα από threads προσπελάσουν συνεχόμενες θέσεις μνήμης, αυτές οι προσπελάσεις ομαδοποιούνται σε μία. Ακόμα, κάθε SM περιέχει και μια γρήγορη, ενσωματωμένη τοπική μνήμη (on-chip local memory), η οποία μοιράζεται μεταξύ όλων των επεξεργαστών του SM. Η μνήμη αυτή έχει μικρό μέγεθος, αλλά είναι κατά πολύ ταχύτερη από την κεντρική. Για να αναπτύξει κάποιος ένα πρόγραμμα που εκτελείται στην κάρτα γραφικών χρειάζεται δύο πράγματα: τον κύριο κώδικα (host) και τον πυρήνα (kernel). Ο κώδικας host εκτελείται στον επεξεργαστή και ελέγχει τη μεταφορά δεδομένων μεταξύ της RAM και της κεντρικής μνήμη της GPU, ενώ επίσης αναλαμβάνει να εκκινήσει τον πυρήνα. Από την άλλη, ο πυρήνας ειναι ο κώδικας που εκτελείται παράλληλα στα threads της κάρτας γραφικών. Όπως φαίνεται στην Εικόνα 2, ένα γενικό πρόβλημα απαιτεί τρία βήματα. Πρώτα, ο επεξεργαστής δεσμεύει μνήμη στην κεντρική μνήμη της GPU για τα δεδομένα ειδόδου και εξόδου, και στη συνέχεια αντιγράφει τα δεδομένα εισόδου από την κύρια μνήμη (RAM) στη μνήμη της GPU. Έπειτα, γίνεται κλήση ώστε να ξεκινήσει η εκτέλεση του πυρήνα στην κάρτα γραφικών, ο οποίος εφαρμόζει τις επιθυμητές ενέργειες πάνω στα δεδομένα εισόδου. Τέλος, όταν η εκτέλεση τελειώσει, ο επεξεργαστής αντιγράφει τα δεδομένα εξόδου στην κύρια μνήμη. Έτσι, ο χρόνος που απαιτείται για την εκτέλεση μιας ενέργειας στην κάρτα γραφικών T GPU ισούται με το που απαιτείται για τη μεταφορά δεδομένων μεταξύ της RAM και της μνήμης της κάρτας T Mem και το χρόνο της ίδιας της επεξεργασίας T computation : T GPU = T Mem + T computation 10

11 Εικόνα 2 - Η ροή ενός τυπικού προγράμματος σε CUDA Πηγή: Wikipedia 2.2 Η αρχιτεκτονική Fermi Η αρχιτεκτονική Fermi [6] έφερε σημαντικές αλλαγές στις επιδόσεις των καρτών γραφικών. Αρχικά, τετραπλασιάστηκε ο αριθμός των CUDA cores σε σχέση με την προηγούμενη αρχιτεκτονική (GF80), με τις νέες κάρτες γραφικών να αποτελούνται απο 512 πυρήνες. Παράλληλα, κάθε SM αποτελείται πλέον από δύο χρονοπρογραμματιστές στημονίων, επιτρέποντας σε 2 στημόνια να εκτελεστούν παράλληλα στους επεξεργαστές του SM, ενώ ακόμα αυξήθηκε σημαντικά η απόδοση σε εκτέλεση πράξεων διπλής ακρίβειας, η οποία σε ορισμένες περιπτώσεις εκτελείται εώς και 8 φορές ταχύτερα. Τέλος, το Fermi εισήγαγε τη δυνατότητα της ταυτόχρονης εκτέλεσης πυρήνων, καθώς και καινούρια επίπεδα στην ιεραρχία μνήμης. 11

12 2.2.1 Ταυτόχρονη εκτέλεση πυρήνα Η Fermi αρχιτεκτονική επιτρέπει την παράλληλη εκτέλεση πυρήνων, όπως φαίνεται και στην Εικόνα 3, όπου διαφορετικοί πυρήνες της ίδιας εφαρμογής μπορούν να εκτελεστούν ταυτόχρονα στην κάρτα γραφικών. Έτσι, δίνεται η δυνατότητα στα προγράμματα να εκτελέσουν πολλούς μικρούς πυρήνες, αντί για έναν, Εικόνα 3 - Σειριακή και Παράλληλη εκτέλεση διαφορετικών πυρήνων Πηγή: NVidia s Fermi whitepaper [6] επιτυγχάνοντας έτσι καλύτερη αξιοποίηση ολόκληρης της κάρτας. Για παράδειγμα, σε ένα πρόγραμμα που απλά προσθέτει τα περιεχόμενα δυο πινάκων σε έναν τρίτο, μπορούμε να εκτελέσουμε περισσότερους πυρήνες, ώστε κάθε ένας να αναλάβει την προσθήκη ενός συγκεκριμένου τμήματος. Παρ όλα αυτά, μπορούμε πάντα να εκτελέσουμε τους πυρήνες σειριακά, για τις εφαρμογές που το απαιτούν, με πολύ καλές επιδόσεις χάρη στη γρήγορη εναλλαγή περιεχομένου(context switching) Ιεραρχία μνήμης Η μνήμη της κάρτας γραφικών με αρχιτεκτονική Fermi αποτελείται από διάφορα επίπεδα. Ξεκινώντας από τις μνήμες με μικρή χωρητικότητα, μια κάρτα γραφικών έχει: τοπική μνήμη για τα threads, κοινή μνήμη-l1 cache, L2 cache, κύρια μνήμη (DRAM). Η τοπική μνήμη είναι η μνήμη που χρησιμοποιείται για να αποθηκεύσει τις τοπικές μεταβλητές των thread. Αποτελείται κατά κύριο λόγο από καταχωρητές. 12

13 Η L1 cache, η οποία είναι ξεχωριστή ανά SM, είναι παραμετροποιήσιμη προκειμένου να υποστηρίζει ταυτόχρονα και κοινή μνήμη(shared memory), προσπελάσιμη από όλα τα threads του συγκεκριμένου block, και για να διατηρεί αντίγραφα της τοπικής και της καθολικής μνήμης. Η 64 KB αυτή μνήμη μπορεί να μοιραστεί είτε ως 48 ΚΒ κοινής μνήμης και 16 KB L1 cache, είτε το αντίθετο, δηλαδή 16 ΚΒ κοινής μνήμης και 48 KB L1 cache. Έτσι είναι στην ευχέρεια του προγραμματιστή να επιλέξει κατάλληλα για το πρόγραμμα, με τις εφαρμογές που κάνουν χρήση της κοινής μνήμης να εκτελούνται εώς και τρεις φορές ταχύτερα, ενώ οι εφαρμογές που κάνουν τυχαίες προσπελάσεις μνήμης να επωφελούνται από τη μεγάλη cache. Τονίζεται όμως ότι σε αντίθεση με την αρχιτεκτονική της CPU, οι L1 cache της κάρτας γραφικών δεν είναι coherent. Αυτό σημαίνει ότι αν δυο SMs διαβάζουν και γράφουν στις ίδιες θέσεις μνήμης, δεν υπάρχει εγγύηση ότι ο ένας SM θα δει τις αλλαγές του άλλου. Αυτού του είδους τα προβλήματα είναι πολύ δύσκολο να αναγνωριστούν, γι αυτό και χρειάζεται ιδιαίτερη προσοχή όταν Εικόνα 4 - Η ιεραρχία μνήμης σε FERMI απαιτείται threads από διαφορετικά blocks χειρίζονται τις ίδιες θέσεις μνήμης. Η L2 cache είναι κοινή για όλους τους πολυεπεξεργαστές και χρησιμοποιείται για να επιταχυνθεί η πρόσβαση στην κύρια μνήμη. Κάθε αίτηση πρόσβασης στη κύρια μνήμη της γραφικών περνάει από την L2 cache ώστε να γίνει πιο γρήγορη πρόσβαση αν χρειαστεί να αναγνωστεί ξανά. Αυτό γίνεται ακόμα και όταν γίνει ανάγνωση ή αντιγραφή της μνήμης από τη CPU. Τέλος, υπάρχει και η καθολική μνήμη, η οποία είναι η μεγαλύτερη σε μέγεθος, αλλά έχει και μεγάλο κόστος προσπέλασης ( κύκλους επεξεργασίας). Είναι προσβάσιμη από όλα τα threads αλλά και από τη CPU με χρήση κατάλληλων συναρτήσεων. Ωστόσο, σε αντίθεση με τα άλλα επίπεδα μνημών, η καθολική μνήμη έχει διάρκεια εφαρμογής, οπότε τα δεδομένα διαγράφονται μόνο όταν έχει τελειώσει η εκτέλεση του προγράμματος. 13

14 2.3 Υλικό που χρησιμοποιήθηκε Η κάρτα γραφικών που χρησιμοποιήθηκε για τις ανάγκες αυτής της πτυχιακής είναι η NVidia GeForce GTX 550 Ti. Ανήκει στην αρχιτεκτονική Fermi με CUDA compute capability 2.1. Για την υλοποίηση του προγράμματος χρησιμοποιήθηκε το CUDA SDK 4.1 Πίνακας 1 - Προδιαγραφές της κάρτας που χρησιμοποιήθηκε Cuda Cores 192 Processor Clock 1820MHz Multiprocessors 4 Cores per SM 48 Warp Size 32 threads Threads per Block 1024 L1 cache 16KB ή 48KB L2 cache 384KB 14

15 Κεφα λαιό 3 - Σχετικη Έρευνα To FLUX 3.1 Εισαγωγή Σε αυτό το κεφάλαιο γίνεται μια σύντομη αναφορά σε διάφορες έρευνες που έχουν δημοσιευτεί γύρω από την εκτέλεση ερωτημάτων στην κάρτα γραφικών, αλλά και σε εφαρμογές εξισορρόπησης φόρτου πάνω σε παράλληλα συστήματα. Κατόπιν, γίνεται μια αναλυτική περιγραφή του εργαλείου FLUX. 3.2 Load-Balancing σε παράλληλα συστήματα Στα παράλληλα συστήματα έχουμε παραγωγούς (producers), που παράγουν τα δεδομένα εισόδου και καταναλωτές (consumers), οι οποίοι αναλαμβάνουν να τα επεξεργαστούν. Καθώς τα δεδομένα ανατίθενται στους καταναλωτές για την επεξεργασία τους, επιδιώκουμε να εξασφαλίζουμε ότι κανένας consumer δε θα δημιουργήσει bottleneck, κατάσταση στην οποία ένας consumer μένει πίσω στην επεξεργασία, καθυστερώντας έτσι και τους υπόλοιπους. Έτσι, γίνεται προσπάθεια ώστε όλοι οι consumers να εργάζονται για τον ίδιο συνολικό χρόνο, καθώς έτσι εξασφαλίζεται ότι ο χρόνος εκτέλεσης θα είναι ο μικρότερος δυνατός. Η ιδανική περίπτωση δηλαδή είναι το να έχουμε για παράδειγμα κυκλική κατανομή των πλειάδων στους καταναλωτές. Αυτό, ωστόσο, δεν είναι δυνατό στα περισσότερα προβλήματα, όπου η ανάθεση πλειάδων δεν γίνεται ομοιόμορφα ή οι consumers δεν έχουν όλοι την ίδια ρυθμαπόδοση. Υπάρχει αρκετή βιβλιογραφία σχετική με αυτό το πρόβλημα. Χαρακτηριστικό παράδειγμα αποτελεί η δημοσίευση Continuously adaptive continuous Queries over Stream [2]. Ωστόσο, η σημαντική διαφοροποίηση έγκειται στο γεγονός ότι εκείνο εξετάζει την περίπτωση όπου, καθώς τα δεδομένα αλλάζουν με την πάροδο του χρόνου, θα χρειαστεί να γίνουν τροποποιήσεις στον τρόπο με τον οποίο εκτελείται το ίδιο το ερώτημα, ανακατευθύνοντας για παράδειγμα τις νέες πλειάδες πρώτα στους operators, όπως σε τελεστή επιλογής, που απορρίπτουν τις περισσότερες. Ακόμα, στο On Dynamic Load Balancing on Graphics Processor [3] ανατίθεται σε κάθε επεξεργαστή μία σειρά ενεργειών που πρέπει να πραγματοποιηθούν, οι οποίες αποθηκεύονται σε μια ουρά, που ανήκει στον συγκεκριμένο επεξεργαστή. Όταν τελειώσει κάποια ενέργεια, ο επεξεργαστής αφαιρεί την επόμενη από την κεφαλή της ουράς του και συνεχίζει στην εκτέλεσή της. Στην περίπτωση, όμως, που 15

16 κάποιος επεξεργαστής τελειώσει όλες του τις απαιτούμενες ενέργειες, επιχειρεί να «κλέψει» ενέργειες από το τέλος της ουράς (για να μην απαιτηθεί μηχανισμός κλειδώματος) του επόμενου επεξεργαστή, συνεχίζοντας στον αμέσως επόμενο, αν δεν τα καταφέρει, κ.ο.κ. 3.3 Επεξεργασία δεδομένων στην κάρτα γραφικών Χαρακτηριστικά παραδείγματα σχετικής βιβλιογραφίας για την επεξεργασία δεδομένων στην κάρτα γραφικών αποτελούν τα Relational Query Co-Processing on Graphics Processors [4] και Accelerating SQL Database Operations on a GPU with CUDA [5]. Το πρώτο αναλύει ένα σύστημα εκτέλεσης ερωτημάτων στο οποίο η κάρτα γραφικών εκτελεί αποκλειστικά όλα τα ερωτήματα βάσεων δεδομένων (Join, Groupby, order κλπ) ή εναλλακτικά λειτουργεί σε συνεργασία με τον επεξεργαστή για την εκτέλεση ερωτημάτων. Η βάση δεδομένων δε βρίσκεται στην μνήμη της κάρτας γραφικών, αλλά στο δίσκο, όπως δηλαδή γίνεται με τις κανονικές βάσεις δεδομένων. Στην περίπτωση που η κάρτα γραφικών λειτουργεί συμπληρωματικά, εφαρμόζονται τεχνικές που λαμβάνουν υπόψιν το κόστος της μεταφοράς των δεδομένων στην GPU και κρίνεται αν θα επωφεληθεί το σύστημα από το να εκτελεστεί το ερώτημα στην GPU. Το δεύτερο αναφέρεται μόνο στην εκτέλεση συγκεκριμένων ερωτημάτων Select, τα οποία εκτελούνται αποκλειστικά στην GPU. 3.4 Το FLUX Το εργαλείο Flux, όπως παρουσιάζεται στη δημοσίευση Flux: An Adaptive Partitioning Operator for Continuous Query Systems [1] επιδιώκει να αντιμετωπίσει τα προβλήματα βραχυπρόθεσμης αλλά και μακροπρόθεσμης ανισορροπίας φόρτου, με τη μεταφορά δεδομένων εκτέλεσης ανάμεσα στους υπολογιστές-καταναλωτές (consumers), στα πλαίσια επανακαθορισμού της ανάθεσης των πλειάδων. Θεωρεί ότι οι καταναλωτές ενδέχεται να προκαλέσουν είτε βραχυπρόθεσμο, είτε μακροπρόθεσμο bottleneck στη ροή των πλειάδων για επεξεργασία. Έτσι, το Flux παρέχει δυο μηχανισμούς εξισορρόπησης: Μηχανισμό αντιμετώπισης βραχυπρόθεσμης ανισορροπίας: Έναν buffer για κάθε καταναλωτή που εξασφαλίζει πως δε θα αναγκαστούν κάποιοι producers να αναμένουν αδρανείς μέχρι να ολοκληρώσει ο επιβαρυμένος consumer 16

17 Μηχανισμό αντιμετώπισης μακροπρόθεσμης ανισορροπίας: προσαρμογή και μεταφορά δεδομένων μεταξύ των καταναλωτών Παρακάτω επεξηγείται μόνο η διαδικασία της μακροπρόθεσμης εξισορρόπησης, καθώς εκείνη βρίσκεται πιο κοντά στα ερευνητικά πλαίσια αυτής της διπλωματικής εργασίας Μακροπρόθεσμη εξισορρόπηση Αρχικά, το σύστημα συνεχόμενων ερωτημάτων (CQ) διαχειρίζεται φόρτο που έχει απρόβλεπτες απαιτήσεις σε πόρους του συστήματος. Καθώς έρχονται νέες πλειάδες για το ερώτημα, ενδέχεται να δημιουργηθεί αυξημένος φόρτος και απαίτηση μνήμης μέσα στο σύνολο των υπολογιστών. Ακόμα, καθώς εξ ορισμού τα ερωτήματα εκτελούνται επ αόριστον, θα παρουσιαστούν μεταβολές στο φόρτο εργασίας κατά τη διάρκεια εκτέλεσης των ερωτημάτων. Προκειμένου αυτά τα ερωτήματα να εκτελούνται αποδοτικά, η ροή πλειάδων πρέπει να προσαρμόζεται δυναμικά με βάση την κατάσταση του συστήματος, με βάση, για παράδειγμα, τη χρήση μνήμης ή CPU. Προκειμένου να είναι εφικτό αυτό, χωρίζουμε τα δεδομένα εισόδου σε partitions, τα οποία τα αντιστοιχίζουμε στους consumers. Ο αριθμός των partitions δεν ισούται με τον αριθμό των καταναλωτών, αλλά αντίθετα τα partitions είναι πολύ περισσότερα. Έτσι, εάν ανιχνευτεί ανισοκατανομή, ένα ή περισσότερα από αυτά θα μετακινηθούν και οι νέες πλειάδες τους θα δρομολογούνται στη νέα θέση. Προκειμένου να γίνει η νέα ανάθεση των partitions, ο καταναλωτής έχει υλοποιημένες τις μεθόδους για ανάκτηση της κατάστασης των partitions (getpartitionstate()) και για την αποθήκευσή της στο νέο καταναλωτή Εικόνα 5 - Πειραματικά αποτελέσματα του Flux Πηγή: Flux: An Adaptive Partitioning Operator for Continuous Query Systems [6] 17

18 (installpartitionstate()). Με αυτές, τα δεδομένα σειριοποιούνται ώστε να γίνει μεταφορά τους μέσω του δικτύου και αποθηκεύονται στις δομές του αποδέκτη. Για παράδειγμα, σε ερωτήματα group-by με παράθυρο, κατά τη μετακίνηση ενός partition πρέπει να μεταφερθεί και το παράθυρο με τις πλειάδες που του ανήκουν. Καθώς η μεταφορά κατάστασης έχει υψηλό κόστος, και προκειμένου να βελτιστοποιηθεί το όφελος από την εξισορρόπηση, επιδιώκουμε τη μείωση του αριθμού των partitions που θα μεταφερθούν, δηλαδή την αποφυγή άσκοπων μετακινήσεων. Για αυτό το λόγο, διατηρούνται δυο στατιστικά στοιχεία: O αριθμός πλειάδων που επεξεργάζεται κάθε partition Ο χρόνος κατά τον οποίο έμεινε ανενεργός κάποιος καταναλωτής Από την ανάλυση αυτών των στοιχείων γίνεται η εκτίμηση εάν η εξισορρόπηση θα είναι ωφέλιμη. Η Εικόνα 5 παρουσιάζει τις επιπτώσεις που έχει η εμφάνιση bottleneck σε κάποιους καταναλωτές και την απόδοση του Flux στην αντιμετώπισή του. 18

19 Κεφαλαιό 4 - Περιγραφη τόυ πρόγρα μματός 4.1 Εισαγωγή Οι πλειάδες της ροής των δεδομένων ανατίθενται σε blocks και σε threads, με βάση την ομάδα στην οποία ανήκουν. Για τη διευκόλυνση του προγράμματος και για να αναφερόμαστε με ενιαίο τρόπο σε όλα τα threads, αποδίδουμε σε κάθε ένα κάποιο μοναδικό χαρακτηριστικό αριθμό. Έτσι, αν έχουμε 4 blocks των 256 threads το καθένα, δίνουμε στα threads του πρώτου block τα χαρακτηριστικά(id) 0-255, ανάλογα με το χαρακτηριστικό του thread (threadid), στου δεύτερου block κ.ο.κ. Στη μνήμη RAM υπάρχουν ορισμένοι πίνακες που κάνουν αυτή την αντιστοίχιση. Για παράδειγμα, ο πίνακας group2threadmapping αντιστοιχίζει την κάθε ομάδα στο thread που θα την αναλάβει. Έτσι, μπορεί πολύ γρήγορα να κατευθύνει τη νέα πλειάδα στο κατάλληλο thread. Στην κάρτα γραφικών βρίσκονται αποθηκευμένοι μεταξύ άλλων δύο πίνακες: ένας δισδιάστατος, που περιέχει όλες τις τιμές του παραθύρου για κάθε ομάδα (windows), και ένας που αντιστοιχίζει κάθε όνομα ομάδας με την αντίστοιχη γραμμή στον πίνακα των παραθύρων. Το παράθυρο έχει σταθερό μέγεθος, το οποίο ορίζεται από το ερώτημα, και διατηρεί τις τελευταίες τιμές που έχουν εμφανιστεί για κάθε ομάδα(π.χ. τις τελευταίες 100). Η τιμή της νέας πλειάδας αντιγράφεται στην κατάλληλη θέση του πίνακα windows με βάση το όνομα της ομάδας της, αντικαθιστώντας την παλαιότερη τιμή του παραθύρου της ομάδας, υλοποιώντας έτσι τη sliding εκδοχή των παραθύρων. 4.1 Ενέργειες της CPU Στην περίπτωση μας όλες οι πλειάδες βρίσκονται στη μνήμη RAM, αλλά στη γενική περίπτωση θα μπορούσαν να διαβάζονται από αρχείο ή να λαμβάνονται μέσω του δικτύου κ.λ.π. Ακόμα, στη RAM βρίσκεται ένας πίνακας host_record, ο οποίος αποθηκεύει τις πλειάδες που θα αποσταλούν στην κάρτα γραφικών για επεξεργασία. Καθώς σαρώνουμε τις πλειάδες, τις αντιγράφουμε στον πίνακα host_record. Όταν αυτός ο πίνακας γεμίσει (για παράδειγμα όταν έχουν συγκεντρωθεί πλειάδες για αποστολή στην γραφικών), τότε τον 19

20 αντιγράφουμε στην καθολική μνήμη της κάρτας γραφικών στον αντίστοιχο πίνακα dev_record και στη συνέχεια κάνουμε κλήση του πυρήνα. Thread 0 Thread 1 Thread 2 Thread 3 Group:5 Value:3 Group:6 Value:2 Group:1 Value:2 Group:7 Value:1 Group:1 Value:3 Group:4 Value:7 Group:8 Value:5 Group:8 Value:10 Εικόνα 6 - Ο πίνακας με τις νέες πλειάδες χωρισμένες με βάση το thread που θα τις αναλάβει, καθώς και ο πίνακας δεικτοδότησης Για να επιτύχουμε ωστόσο καλές επιδόσεις αυτό δεν αρκεί, καθώς δεν υπάρχει πληροφορία στην GPU για τις θέσεις των πλειάδων που θα αναλάβει κάθε thread. Θα απαιτούνταν επομένως κάθε thread να διαβάσει όλα τα δεδομένα, προκειμένου να κρατήσει όσα προορίζονται για αυτό. Μία τέτοια ενέργεια όμως θα είχε τεράστιο κόστος λόγω του μεγάλου χρόνου προσπέλασης της κύριας μνήμης (της GPU). Προκειμένου να αντιμετωπισθεί αυτό το πρόβλημα, απαιτείται να γίνει μια προεπεξεργασία στα δεδομένα πριν αποσταλούν, ώστε κάθε thread να γνωρίζει εκ των προτέρων ποιες θέσεις να διαβάσει. Για να επιτευχθεί κάτι τέτοιο, κατά τη διάρκεια γεμίσματος του host_record υπολογίζουμε πόσες πλειάδες αντιστοιχούν σε κάθε thread. Αφού γεμίσει ο πίνακας, αντιγράφουμε τα δεδομένα του πίνακα host_record σε ένα νέο πίνακα (host_records_proccessed), συγκεντρώνοντας όλες τις πλειάδες που αντιστοιχούν σε κάποιο thread, και δημιουργώντας έναν πίνακα που αντιστοιχίζει το κάθε thread με την απόσταση από την αρχή του πίνακα (threaddatapos), όπως φαίνεται και στην Εικόνα 6. Στη συνέχεια, αντιγράφονται στην κεντρική μνήμη της κάρτας γραφικών τόσο ο πίνακας με τις πλειάδες host_records_proccessed, όσο και ο πίνακας με τις θέσεις (threaddatapos). Επισημαίνεται ότι η αντιγραφή αυτή γίνεται ασύγχρονα, προκειμένου η ροή του προγράμματος να μη διακόπτεται μέχρι να τελειώσει η μεταφορά δεδομένων. Στη συνέχεια, καλείται ο πυρήνας, ο οποίος και αυτός εκτελείται ασύγχρονα. Τέλος, η CPU αναλαμβάνει να αντιγράψει τα αποτελέσματα από την κάρτα γραφικών. 20

21 4.3 Ενέργειες της GPU Στην κάρτα γραφικών βρίσκονται αποθηκευμένοι ένας πίνακας που κρατάει το παράθυρο για κάθε ομάδα (windows), ένας πίνακας που κρατάει τα ονόματα των ομάδων που υπάρχουν στην κεντρική μνήμη (groups) και ένας πίνακας που κρατάει την επόμενη θέση μνήμης του κάθε παραθύρου για αντικατάσταση (nextpos). Groups Windows nextpos Εικόνα 7 - Οι πίνακες που βρίσκονται στην κύρια μνήμη της κάρτας Όπως έχουμε ήδη αναφέρει, όταν γίνει κλήση ενός πυρήνα, έχουν ήδη αντιγραφεί στην κεντρική μνήμη της κάρτας γραφικών οι νέες πλειάδες (στον πίνακα dev_record) καθώς και ο πίνακας dev_threaddatapos, που ενημερώνει το κάθε thread για τις θέσεις μνήμης που περιέχουν τις νέες πλειάδες. Το κάθε thread υπολογίζει αρχικά το πλήθος των πλειάδων που καλείται να επεξεργαστεί, ενώ στη συνέχεια σαρώνει τις πλειάδες και, για κάθε νέα πλειάδα, βρίσκει τη θέση που πρέπει να αντικατασταθεί από το παράθυρο για τη συγκεκριμένη ομάδα, και αντιγράφει την τιμή διαγράφοντας την παλαιότερη τιμή του παραθύρου. Έπειτα, εφαρμόζει μια πράξη πάνω σε όλα τα δεδομένα του παραθύρου, για παράδειγμα υπολογίζει το άθροισμα (sum) για τις τιμές του συγκεκριμένου παραθύρου. Σημειώνουμε ότι, ενώ προηγουμένως αναφέραμε πως γίνεται ασύγχρονη κλήση του πυρήνα, ώστε να μην καθυστερεί το πρόγραμμα, όταν επιχειρούμε να εκτελέσουμε κάποια άλλη ενέργεια στην GPU (για παράδειγμα αντιγραφή δεδομένων από τη RAM), το πρόγραμμα αυτόματα γίνεται ανενεργό μέχρι να ολοκληρωθεί η προηγούμενη ενέργεια. Έτσι εξασφαλίζεται το ότι δε θα αντικατασταθούν τα δεδομένα που βρίσκονται υπό επεξεργασία στην GPU με την αποστολή νέων από τη CPU και το ότι δε θα επιβαρύνεται η GPU με δεδομένα που δεν προλαβαίνει να επεξεργαστεί. 21

22 Ποσοστό πλειάδων Kεφα λαιό 5 - Πρό κληση ανισόρρόπι ας 5.1 Εισαγωγή Όπως έχουμε περιγράψει, σε κάθε thread ανατίθεται ένας αριθμός από ομάδες. Στην ιδανική περίπτωση, οι ομάδες μοιράζονται ομοιόμορφα στα threads, και με δεδομένο πως αυτά εκτελούνται παράλληλα και με την ίδια ταχύτητα, θα ολοκληρώσουν το έργο τους σχεδόν ταυτόχρονα. Ωστόσο, συνήθως τα πράγματα δεν είναι τόσο ιδανικά στην πράξη, κι έτσι προκαλούνται ανισορροπίες φόρτου, καθώς λίγα threads αναλαμβάνουν να επεξεργαστούν το μεγαλύτερο μέρος των δεδομένων ενώ τα περισσότερα threads παραμένουν ανενεργά. Η ανισορροπία αυτή μπορεί να επιβαρύνει σημαντικά το χρόνο διεκπεραίωσης του συναθροιστικού ερωτήματος, καθώς τα threads που έχουν ολοκληρώσει το έργο τους θα παραμείνουν ανενεργά μέχρι να ολοκληρωθούν τα υπόλοιπα threads. 5.2 Ανισορροπία σε επίπεδο thread Εδώ οι πλειάδες επιμερίζονται ανομοιόμορφα μεταξύ των thread. Συνεπώς, τα επιβαρυμένα threads θα απασχοληθούν για περισσότερο χρόνο και το σύστημα δε θα μπορέσει να αναλάβει τον επόμενο αριθμό πλειάδων προς επεξεργασία. Ανισοκατανομή φόρτου σε 5 threads 80% 70% 60% 50% 40% 30% 20% 10% 0% thread 0 thread 1 thread 2 thread 3 thread 4 thread ID Εικόνα 8 - Παράδειγμα ανισοκατανομής φόρτου σε 5 threads 22

23 Όπως φαίνεται σε αυτό το παράδειγμα, το 70% των πλειάδων το έχει αναλάβει ένα μόνο thread, ενώ τα υπόλοιπα είτε αναλαμβάνουν ένα μικρό ποσοστό, είτε απλά αδρανούν. Σε ένα σύστημα που ο αριθμός των thread είναι μεγάλος, το πρόβλημα αυτό μπορεί να πάρει επικίνδυνες διαστάσεις. Παρακάτω, στην Εικόνα 9 φαίνεται η ραγδαία αύξηση του χρόνου εκτέλεσης όταν αναθέτουμε μεγάλο ποσοστό των πλειάδων σε λίγες ομάδες (συνεπώς σε λίγα threads), χρησιμοποιώντας Zipf κατανομή για τα δεδομένα. Χρόνος εκτέλεσης χωρίς εξισορρόπηση φόρτου σε ομοιόμορφη και zipf κατανομή ZIPF κατανομή 19032,73 Ομοιόμορφη κατανομή 3465,27 0, , , , ,00 milliseconds Εικόνα 9 - Χρόνος εκτέλεσης χωρίς εξισορρόπηση φόρτου σε ομοιόμορφη και zipf κατανομή 23

24 Κεφα λαιό 6 - Εξισόρρό πηση Φό ρτόυ Στόχος μας είναι το πρόγραμμα να αντιληφθεί όσο το δυνατόν πιο άμεσα την ανισοκατανομή και να προχωρήσει σε αποτελεσματική αντιμετώπιση της, προκειμένου τα επόμενα streams δεδομένων να κατανέμονται καλύτερα και ο χρόνος εκτέλεσης να πλησιάζει αυτόν της ομοιόμορφης κατανομής των πλειάδων στα threads. 6.1 Εξισορρόπηση σε επίπεδο thread Ανίχνευση ανισοκατανομής Κάθε φορά που ετοιμάζεται να αποσταλεί ένα stream πλειάδων στην κάρτα γραφικών, υπολογίζουμε το πόσες πλειάδες αναλογούν σε κάθε thread. Έτσι, κατασκευάζοντας κάθε φορά με αυτά τα δεδομένα δυο ουρές προτεραιότητας, μια ελαχίστου και μια μεγίστου, μπορούμε εύκολα να αναγνωρίσουμε εάν κάποια threads έχουν υπερφορτωθεί και να προβούμε σε κινήσεις εξισορρόπησης. Θεωρούμε ότι για να ερμηνευτεί ως ύπαρξη ανισοκατανομής μεταξύ δυο thread, η διαφορά του αριθμού των πλειάδων τους πρέπει να ξεπερνά μία τιμή κατωφλίου (threadloadthreshold) Προσπάθεια εξισορρόπησης Σε κάθε περίπτωση, εξετάζουμε πόσα και ποια threads θα πρέπει να εξισορροπηθούν. Ανατρέχουμε δηλαδή παράλληλα στις ουρές προτεραιότητας, και για όσο ισχύει ότι το i-οστό πιο φορτωμένο thread είναι περισσότερο φορτωμένο από το i-οστό λιγότερο επιβαρυμένο thread κατά μια ποσότητα πλειάδων που ξεπερνάει το threshold, τότε επεμβαίνουμε για να εξισορροπήσουμε με κάποιον από τους εξής τρόπους: Α) Τυχαία μετακίνηση ομάδας από το φορτωμένο thread σε ένα πιο άδειο (getfirst) Β) Μετακίνηση της πιο συχνής ομάδας σε άλλο thread (checkall) Γ) Μετακίνηση της πιο συχνής ομάδας, με κάποια πιθανότητα, σε άλλο thread (probcheck) Δ) Μετακίνηση της ομάδας που θα επιφέρει τη μέγιστη εξισορρόπηση (bestbalance) 24

25 Τυχαία μετακίνηση του πρώτου Σε αυτή τη μέθοδο εξισορρόπησης, επιλέγεται τυχαία η πρώτη ομάδα από το πιο φορτωμένο thread και μετακινείται σε αυτό που έχει το λιγότερο φόρτο. Ενημερώνουμε επομένως τους καταλόγους που αντιστοιχίζουν τις ομάδες με τα threads που έχουν αναλάβει την επεξεργασία τους. Αυτή η μέθοδος είναι εύκολη στην υλοποίηση και γρήγορη, καθώς δεν απαιτεί να ξαναδιαβαστούν τα δεδομένα. Ωστόσο, καθώς επιλέγει τυχαία ομάδες, είναι πιθανό να απαιτήσει αρκετούς κύκλους μέχρι να επιτύχει καλή εξισορρόπηση Μετακίνηση της πιο συχνής ομάδας Σε αυτόν τον τρόπο εξισορρόπησης επιλέγεται για μετακίνηση η ομάδα, η οποία έχει τις περισσότερες εμφανίσεις. Για να επιτευχθεί η εύρεση του, σαρώνονται όλες οι πλειάδες που αποστέλλονται στην κάρτα γραφικών με σκοπό να τις αναλάβει αυτό το thread, και επιλέγεται αυτή που έχει το μεγαλύτερο αριθμό εμφανίσεων. Η μέθοδος αυτή παρουσιάζει αυξημένο κόστος σε σχέση με την προηγούμενη, καθώς απαιτεί να σαρωθούν όλες οι πλειάδες. Εγγυάται όμως πιο γρήγορη ισοκατανομή του φόρτου Μετακίνηση μιας συχνής ομάδας πιθανοκρατικά Αυτή η μέθοδος υλοποίησης είναι παρόμοια με την προηγούμενη. Η μόνη διαφορά έγκειται στο ότι δεν απαιτείται σάρωση όλων των δεδομένων που θα αποσταλούν, προκειμένου να εντοπιστεί η πιο συχνή ομάδα, αλλά μόνο ενός μέρους τους. Αυτό βασίζεται στο ότι αν μια ομάδα εμφανίζεται πολλές φορές, τότε θα καλύψει γρήγορα ένα ποσοστό θέσεων από τις πλειάδες του συγκεκριμένου thread. Για παράδειγμα, εάν έχουμε 10 ομάδες σε ένα thread, στο οποίο θα αποσταλούν 100 πλειάδες που ανήκουν σε αυτές τις ομάδες, τότε σε μια ομοιόμορφη κατανομή αναμένουμε ότι αντιστοιχούν 10 πλειάδες σε κάθε ομάδα. Θεωρούμε, λοιπόν, ως συχνή ομάδα, αυτή που θα καλύψει πρώτη ένα ποσοστό αυτών των θέσεων, για παράδειγμα το 50% αυτών των 10 πλειάδων. Το ποσοστό αυτό ορίζεται με την παράμετρο probcheckpercentage Μετακίνηση της βέλτιστης ομάδας Σε αυτή τη μέθοδο επιλέγεται να μεταφερθεί εκείνη η ομάδα, η οποία θα ελαχιστοποιήσει τη διαφορά ανάμεσα στο περισσότερο και στο λιγότερο επιβαρυμένο thread. Αποτελεί, με λίγα λόγια, μέθοδο παραπλήσια της checkall με εγγύηση ωστόσο καλύτερης εξισορρόπησης. 25

26 6.2 Σύγκριση με το FLUX Η παρούσα υλοποίηση διαφοροποιείται αρκετά από την υλοποίηση του FLUX. Αυτό οφείλεται κυρίως στο ότι στο FLUX το σύστημα αποτελούνταν από πολλά μηχανήματα χωρίς καθόλου κοινή μνήμη. Αντίθετα, η κάρτα γραφικών αποτελείται από πολλούς επεξεργαστές, οι οποίοι, όμως, μοιράζονται κοινή μνήμη. Έτσι, για τη μεταφορά μιας ομάδας από ένα thread σε ένα άλλο, δεν χρειάζεται να γίνει καθόλου μεταφορά δεδομένων, καθώς όλοι οι επεξεργαστές έχουν πρόσβαση σε όλα τα δεδομένα. Έτσι, κατά την «μετακίνηση» μιας ομάδας, το μόνο που απαιτείται είναι η CPU να ενημερώσει τη δομή που κατευθύνει τις νέες πλειάδες (mapping μεταξύ groups και threads). Συνεπώς, καθώς το κόστος της μετακίνησης δεδομένων στο FLUX ήταν μεγάλο, έπρεπε το σύστημα να είναι σίγουρο ότι μια προσπάθεια εξισορρόπησης αξίζει το κόστος. Αντίθετα, στη κάρτα γραφικών το πρόβλημα αυτό απουσιάζει και έτσι υπάρχει μια ανοχή στο να γίνει μετακίνηση που δεν επιλύει το πρόβλημα της ανισοκατανομής. Ακόμα, σημαντική διαφορά εμφανίζεται στον τρόπο με τον οποίο γίνεται ανίχνευση ανισοκατανομής. Σύμφωνα με το FLUX, διατηρούνται ως στατιστικά το πλήθος των πλειάδων που διαχειρίζεται κάθε καταναλωτής και ο χρόνος κατά τον οποίο παραμένει ανενεργός. Στην περίπωση μας, η μέτρηση του χρόνου αναμονής δεν είναι εφικτή, καθώς, παρότι η μέτρηση χρόνου εκτέλεσης ενός πυρήνα είναι εφικτή, λόγω της ασύγχρονης εκτέλεσης, θα εμφάνιζε λάθος αποτελέσματα. Γι αυτό, χρησιμοποιείται μόνο το πλήθος των πλειάδων (σε επίπεδο thread). Τέλος, στην περίπτωσή μας οι consumers, δηλαδή τα threads της κάρτας γραφικών, έχουν το ίδιο throughput μεταξύ τους. 26

27 millisec Κεφα λαιό 7 - Απότελε σματα Πειραμα των Για την αποτίμηση των αποτελεσμάτων χρησιμοποιήθηκαν 100 εκατομύρια πλειάδες, οι οποίες αποστέλονται στην κάρτα γραφικών σε ριπές των Αυτές οι πλειάδες είτε ανήκουν κυκλικά στις ομάδες, είτε ακολουθούν κατανομή zipf. Για την επεξεργασία αυτών των ομάδων επιλέχθηκε, ύστερα από αρκετές δοκιμές, να δημιουργηθούν 4 blocks των 256 threads το καθένα. Έτσι, συνολικά έχουμε 1024 threads και αρχικά οι ομάδες ισοκατανέμονται σε αυτά, ενώ για κάθε ομάδα κρατάμε ένα παράθυρο σταθερού μεγέθους, 100 τιμών. Παρακάτω συγκρίνονται τα αποτελέσματα των τεσσάρων μεθόδων που αναλύθηκαν, για διάφορες τιμές των παραμέτρων. Είναι εμφανές από την Εικόνα 9 του 5 ου κεφαλαίου ότι η ύπαρξη ανισοκατανομής πολλαπλασιάζει το χρόνο περάτωσης της ενέργειας. Έτσι είναι φυσικό να θέλουμε να κάνουμε κάποιες κινήσεις εξισορρόπησης. Γι αυτό, στο προηγούμενο κεφάλαιο προτάθηκαν 4 μέθοδοι και πιο συγκεκριμένα, οι μέθοδοι getfirst (τυχαία επιλογή της πρώτης ομάδας που ανήκει στο thread), η checkall (επιλογή της ομάδας που έχει τις περισσότερες εμφανίσεις), η μέθοδος probcheck (επιλογή μιας ομάδας με μεγάλο πλήθος εμφανίσεων) και η μέθοδος της βέλτιστης επιλογής(bestbalance) , , , , , , , , , ,00 0,00 Σύγκριση χρόνου σε zipf κατανομή, για τις διάφορες μεθόδους εξισορρόπησης 19032, , , , , ,8 Εικόνα 10 - Σύγκριση χρόνου σε zipf κατανομή 27

28 millisecods Όπως φαίνεται στην Εικόνα 10, όταν τα δεδομένα μας ακολουθούν zipf κατανομή, ο χρόνος βελτιώνεται κατά πολύ από την εξισορρόπηση, ενώ το κέρδος αυξάνεται όταν εισάγουμε και μια ενέργεια πάνω στα δεδομένα, για παράδειγμα όταν έχουμε σάρωση του παραθύρου με την εισαγωγή κάθε νέας τιμής. Στην Εικόνα 11 παρουσιάζονται οι χρόνοι όταν σε κάθε εισαγωγή τιμής διαβάζουμε 20 φορές το ολόκληρο το παράθυρο (προσομοιώνοντας έτσι μια χρονοβόρα διαδικασία). Σύγκριση χρόνου σε zipf κατανομή, για τις διάφορες μεθόδους εξισορρόπησης no loadbalancing getfirst checkall probcheck 0,1 bestbalance Εικόνα 11 - Σύγκριση χρόνου σε zipf κατανομή με χρονοβόρα πράξη Είναι φανερό πως η μέθοδος probcheck έχει καλύτερα αποτελέσματα για μικρές τιμές της παραμέτρου probcheckpercentage. Αυτό οφείλεται στο γεγονός ότι θα σταματήσει νωρίτερα η σάρωση των πλειάδων για εύρεση μιας συχνής ομάδας. Ακόμα, είναι αναμενόμενο για οποιαδήποτε επιλογή της παραμέτρου να είναι ταχύτερη από την μέθοδο checkall, καθώς εκείνη σαρώνει όλα τα δεδομένα που θα αποσταλούν. Ακόμα, η μέθοδος bestbalance εγγυάται καλύτερα αποτελέσματα από την checkall καθώς σίγουρα θα κάνει καλύτερη εξισορρόπηση. Παραμένει ωστόσο πιο αργή από τις άλλες μεθόδους καθώς έχει μεγάλο κόστος για τον υπολογισμό της βέλτιστης επιλογής. Στην Εικόνα 12 φαίνεται τι επίδραση έχει η παράμετρος probcheckpercentage στο χρόνο εκτέλεση. Όπως είναι λογικό, για μεγάλη επιλογή παραμέτρου η καθυστέρηση αυξάνεται,καθώς θα πρέπει να σαρωθούν οι περισσότερες πλειάδες του επιβαρυμένου thread, οδηγώντας έτσι σε επιδόσεις checkall. Αντίθετα, για πολύ μικρές τιμές έχει πολύ μεγάλη πιθανότητα να επιλέξει εσφαλμένα. Έτσι, καλύτερα αποτελέσματα εμφανίζονται για μεσαίες τιμές τις παραμέτρου. 28

29 Χρόνος εκτέλεσης 6290,0 6280,0 6270,0 6260,0 6250,0 6240,0 6230,0 6220,0 6210,0 Κλιμάκωση χρόνου εκτέλεσης για διάφορες τιμές της παραμέτρου probcheckpercentage 0,1 0,3 0,5 0,7 0,9 Τιμή παραμέτρου probcheckpercentage Εικόνα 12 - Χρόνος εκτέλεσης συναρτήσει της παραμέτρου στην probcheck Η getfirst μπορεί να δείχνει ότι έχει καλύτερα αποτελέσματα από τις άλλες δύο μεθόδους, υπάρχουν ωστόσο περιπτώσεις όπου η probcheck αναμένεται να έχει καλύτερα αποτελέσματα από την getfirst, η οποία επιλέγει τυχαία την πρώτη ομάδα που ανήκει στο thread χωρίς να έχει την παραμικρή πληροφορία για το αν αυτή η μετακίνηση θα επιφέρει βελτίωση του χρόνου. Έτσι, θα μπορούσε να επιλέγει ομάδες οι οποίες, στην ακραία περίπτωση, δε θα έχουν καθόλου πλειάδες στις πλειάδες του stream που θα αποσταλεί στην κάρτα γραφικών. Μια τέτοια περίπτωση είναι και αυτή στην οποία ένα thread διαχειρίζεται για παράδειγμα χίλιες διαφορετικές ομάδες, οι οποίες ως επί το πλείστον δεν έχουν καθόλου πλειάδες, ενώ οι τελευταίες ομάδες έχουν επιβαρυνθεί πολύ. Η μέθοδος getfirst θα αρχίζει να αφαιρεί ομάδες από την αρχή της λίστας του thread, επομένως για να φτάσει να επιλέξει μια επιβαρυμένη ομάδα θα απαιτηθούν πάρα πολλές προσπάθειες εξισορρόπησης, χωρίς να υπάρχει βελτίωση στο χρόνο. Αντίθετα, η probcheck με αρκετά μεγάλη πιθανότητα από την πρώτη κιόλας προσπάθεια θα επέλεγε τη σωστή. Αντίθετα, μπορεί η probcheck (αντίστοιχα και η checkall) να μεταφέρει μια ομάδα, η οποία μονοπωλεί σχεδόν το σύνολο αυτής της ριπής σε σχέση με τα άλλα και έτσι, όπου και να μεταφερθεί θα αντιστοιχηθεί να το επιβραδύνει αντίστοιχα, δηλαδή δε θα έχουμε κέρδος. Σε αυτή τη περίπτωση η τυχαία επιλογή της getfirst θα μπορούσε να έχει καλύτερο αποτέλεσμα, αν τύχαινε να μεταφέρει αρκετές από τις ομάδες με τις λίγες εμφανίσεις. Στην Εικόνα 13 φαίνεται πώς η παράμετρος threadloadthreshold επηρεάζει τα αποτελέσματα. Με επιλογή μικρής τιμής αναγκάζουμε το σύστημα να κάνει περισσότερες διορθωτικές κινήσεις, προσθέτοντας έτσι σημαντική επιβάρυνση. Αντίθετα, για μεγάλες τιμές της παραμέτρου δεν θα γίνεται σχεδόν ποτέ 29

30 milliseconds millisec εξισορρόπηση, γι αυτό και πέφτει η επίδοση του συστήματος όταν την ανεβάσουμε πάνω από ένα επίπεδο , , , ,00 Κλιμάκωση του χρόνου εκτέλεσης του με CheckALL load-balancing 8000, , , ,00 0,00 0,00 500, , , , , , , , , ,00 Παράμετρος threadloadthreshold Εικόνα 13 - Κλιμάκωση του χρόνου εκτέλεσης του με εξισορρόπηση 7.1 Κόστος εξισορρόπησης Παρακάτω φαίνεται η επιβάρυνση που προσθέτει ο έλεγχος ανισοκατανομής, όταν η επεξεργασία είναι ήδη ομοιόμορφα διαμοιρασμένη στα threads. Η αύξηση του χρόνου είναι συνέπεια του μηχανισμού που βρίσκει τα πιο φορτωμένα και τα λιγότερο φορτωμένα threads. Το κέρδος όμως που αποκομίζουμε όταν τα δεδομένα Καθυστέρηση που προσθέτει το Load- Balancing σε ομοιόμορφα κατανεμημένα δεδομένα no Load-Balancing Load-Balancing Εικόνα 14 - Καθυστέρηση που προσθέτει το Load-Balancing 30

31 seconds δεν ακολουθούν ομοιόμορφη κατανομή, καθώς στην πράξη σπάνια θα εμφανιστεί η ιδανική αυτή περίπτωση, καθιστά τη εξισορρόπηση αναγκαία. 7.2 Σύγκριση με CPU Υλοποιήθηκε ακόμα πρόγραμμα που εκτελεί το ίδιο τύπο ερωτήματος πάνω στην ίδια βάση δεδομένων, με την επεξεργασία να γίνεται αποκλειστικά στον επεξεργαστή. Καθώς για τη CPU υπάρχει μόνο ένα νήμα εκτέλεσης, δεν παρουσιάζεται πρόβλημα ανισοκατανομής. Έτσι, είτε τα δεδομένα ακολουθούν ομοιόμορφη κατανομή είτε zipf, ο χρόνος επεξεργασίας παραμένει ίδιος. 8,00 7,00 6,00 5,00 4,00 3,00 2,00 1,00 0,00 Σύγκριση χρόνου CPU με GPU για 10, 50 και 100 εκατομ. πλειάδες 0,900,6130,40 4,09 3,00 1,871 7,50 6, ,72 Εικόνα 15 - Σύγκριση χρόνου εκτέλεσης μεταξύ CPU-GPU CPU GPU ZIPF Όπως φαίνεται και στην Εικόνα 15 η κάρτα γραφικών υπερτερεί ακόμα και στην απαιτητική κατανομή zipf. Ακόμα μεγάλύτερο όμως όφελος από τη χρήση της κάρτας γραφικών θα αποκομίσουμε εάν εφαρμόσουμε απαιτητικές πράξεις πάνω στα δεδομένα, και ειδικά πράξεις διπλής ακρίβειας που χάρη στην FERMI αρχιτεκτονική έχουν επιταχυνθεί πολύ. GPU 31

32 Επι λόγός Στα πλαίσια αυτής της πτυχιακής προτάθηκαν ορισμένοι τρόποι για εξισορρόπηση φόρτου σε ένα σύστημα που εφαρμόζει group-by ερωτήματα πάνω σε ροή δεδομένων, με την επεξεργασία των δεδομένων να γίνεται στην GPU. Η βασική ιδέα για την υλοποίηση του συστήματος βασίστηκε σε μεθόδους που εξισορροπούν το φόρτο ανάμεσα σε threads-καταναλωτές, τα οποία έχουν μεταξύ τους την ίδια ρυθμαπόδοση, ενώ προκαλούν bottleneck όταν φορτωθούν ανομοιόμορφα. Παρουσιάστηκαν πειραματικά αποτελέσματα για το όφελος που έχουμε από την επεξεργασία των δεδομένων στην κάρτα γραφικών σε σχέση με τον επεξεργαστή, ενώ ακόμα έγινε και μια άμεση σύγκριση των μεθόδων εξισορρόπησης που προτάθηκαν. 32

33 Βιβλιόγραφι α [1] Mehul A. Shah, Joseph M. Hellerstein, Sirish Chandrasekaran and Michael J. Franklin, Flux: An Adaptive Partitioning Operator for Continuous Query Systems, 2002 [2] Samuel Madden, Mehul Shah, Joseph M. Hellerstein and Vijayshankar Raman, Continuously adaptive continuous Queries over Stream, 2002 [3] Daniel Cederman, Philippas Tsigas, On Dynamic Load Balancing on Graphics Processor, 2008 [4] Bingsheng He, Mian Lu, Ke Yang, Rui Fang, Naga K. Govindaraju, Qiong Luo, Pedro V. Sander, Relational Query Co-Processing on Graphics Processors, 2009 [5] Peter Bakkum, Kevin Skadron, Accelerating SQL Database Operations on a GPU with CUDA, 2008 [6] NVidia, NVIDIA s Next Generation CUDA TM Compute Architecture: Fermi,

34 Ακρωνυ μια Ακρωνύμιο CPU CQ CUDA GPU GPUGP SIMD SM Επεξήγηση Central Processing Unit Continuous Query Compute Unified Device Architecture Graphics Processing Unit General-Purpose computing on Graphics Processing Unit Simple Instruction stream, Multiple Data streams Streaming Multiprocessor 34

35 Γλωσσα ριό Αγγλικά Όρος Block Bottleneck CUDA Core Group-by Fermi Host Kernel Partition Stream Thread Warp Επεξήγηση Μια ομάδα από threads Φαινόμενο κατά το οποίο οι επιδόσεις του συστήματος περιορίζεται από τις επιδόσεις ενός συστατικού του Πυρήνας επεξεργασίας της κάρτας γραφικών Ερωτήματα ομαδοποίησης Αρχιτεκτονική κάρτας γραφικών Το τμήμα του υπολογιστή που αποτελείται απο CPU και RAM Ο πυρήνας, δηλαδή ο κώδικας που εκτελείται στην κάρτα Γραφικών Τμήμα των δεδομένων Ροή δεδομένων Νήμα εκτέλεσης Ένα τμήμα ενός block που δρομολογείται για εκτέλεση Ελληνικά Όρος Στημόνιο Παράθυρο Πυρήνας Επεξήγηση Ένα τμήμα ενός block που δρομολογείται για εκτέλεση Οι τιμές που εμφανίστηκαν πιο πρόσφατα σε μιά ομάδα Ο κώδικας που εκτελείται στην κάρτα γραφικών 35

36 Κωδικας #include <iostream> #include <time.h> #include "cuda.h" #include "cuda_runtime.h" #include "device_launch_parameters.h" #include <fstream> #include <vector> #include <queue> #include <hash_map> using namespace std; #define numofstreams 1 #define numofblocks 4 #define numofthreads 256 #define tuples #define numofgroups #define history 100 #define N numofgroups/numofstreams // The number of groups each thread has to process #define groupsperthread (numofgroups/numofstreams)/(numofthreads*numofblocks) #define eksisorropishthread 1 #define threadloadthreshold 500 //The threshold for considering a difference as imbalance // eksisorropishthread should be always used with one of the three balancing methods below #define getfirst 1 //Enables the getfist balancing method //#define checkall 1 //Enables the checkall balancing method //#define probcheck 1 //Enables the probcheck balancing method #define probcheckpercentage 0.1 //The percentage of tuples probcheck should reach //#define bestbalance 1 //Select the group that will have the best effect //#define zipf 1 //uses data created with Zipf distribution as inpur (a file of integers) //#define performslowoperation //enables the slow operation in the GPU process (e.g. 20x scanning of the window) #define senttuplesperstream //Number of groups sent per stream to the GPU typedef struct align (8){ int id, value; //ta tuples exoun id(int), timh(int) record; //GPU error handling methods static void HandleError( cudaerror_t err, const char *file, int line ) { if (err!= cudasuccess) { printf( "%s in %s at line %d\n", cudageterrorstring( err ), file, line ); exit( EXIT_FAILURE ); 36

37 #define HANDLE_ERROR( err ) (HandleError( err, FILE, LINE )) #define HANDLE_NULL( a ) {if (a == NULL) { \ printf( "Host memory failed in %s at line %d\n", \ FILE, LINE ); \ exit( EXIT_FAILURE ); //####################################### //For the priority queues typedef struct { int threadid,value; heapnode; class maxcomparison { public: bool operator() (const heapnode& lhs, const heapnode&rhs) const { return (lhs.value<rhs.value); ; class mincomparison { public: bool operator() (const heapnode& lhs, const heapnode&rhs) const { return (lhs.value>rhs.value); ; //####################################### record data[tuples]; //The matrix tha keeps the data in RAM int *nextpos; //the next value to be replaced in the window, for each group cudastream_t stream[numofstreams]; record * host_record[numofstreams]; //Values to be sent to the GPU record * host_records_proccessed[numofstreams]; //The same data as in host_record, but after being preprocessed record * dev_record[numofstreams]; //same as host_records_proccessed, but in GPU int * windows; //keeps the values of the windows in GPU, one for each group int * groups; //the group labels in GPU heapnode * threaddatacounter[numofstreams]; //Number o records assigned to each thread int * threaddatapos[numofstreams]; //Where each thread starts reading int * dev_threaddatapos[numofstreams]; //The same, but after copied to the GPU memory int tuples2send[numofstreams]; //poses pleiades exoume sthn oura gia apostolh int group2threadmapping[numofgroups]; //Maps group->thread int group2smmapping[numofgroups]; //Maps group->sm vector<int> thread2group[numofstreams][numofthreads*numofblocks]; //the reverse relation of the group to thread mapping float loadingtime=0; //For time measuring 37