Multi-threading Κορομηνάς Κωνσταντίνος – Μ437 Χατζηανδρέου Ελένη - Μ400 Χήνου Διονυσία – Μ364 Οι αρχιτεκτονικές στις οποίες έχουμε μέχρι στιγμής αναφερθεί, έχουν ένα αυτόνομο sequencer ο οποίος φέρνει (fetches) και εκτελεί εντολές από ένα μοναδικό instruction stream. Όσο περισσότερο οι πόροι transistor γίνονται διαθέσιμοι, οι αρχιτεκτονικές εξελίχθηκαν ώστε να έχουν πολλαπλούς sequencers και να είναι σε θέση να εκτελούν πολλαπλά instruction streams. Δύο περιπτώσεις: Simultaneous Multithreaded (SMT) επεξεργαστής: Άμεση επέκταση σε ένα μοντέρνο superscalar επεξεργαστή Μια αρχιτεκτονική στην οποία πολλαπλοί sequencers προσθέτονται στο front-end της αρχιτεκτονικής (instruction fetching, decoding, renaming), με το back end της μηχανής να παραμένει ως επί το πλείστον χωρίς αλλαγές. Κάθε instruction stream έχει το δικό του σύνολο από front end πόρους. Οι back end πόροι μοιράζονται από όλα τα instruction streams. Chip Multiprocessor (CMT): Υλοποιεί ένα πιο παραδοσιακό πολυεπεξεργαστή σε ένα και μόνο chip Μια αρχιτεκτονική η οποία είναι συλλογή από processing engines, μια για κάθε instruction stream. Εδώ η μονάδα (unit) των replication αυξάνει από μια λειτουργική μονάδα (functional unit) ικανή για την εκτέλεση μιας εντολής σε μια processing unit ικανή για την εκτέλεση μιας σειράς από εντολές. Άλλες περιπτώσεις έχουν να κάνουν με διαμοιρασμό hardware πόρων. Μια προσέγγιση στη χρησιμοποίηση των πολλαπλών εικονικών επεξεργαστών στοχεύει στα πολλαπλά, τρέχοντας ανεξάρτητα προγράμματα ή threads. Το κίνητρο εδώ είναι ότι συχνά οι επεξεργαστές χρησιμοποιούνται στα περιβάλλοντα πολυπρογραμματισμού όπου πολλαπλά threads μοιράζονται το χρόνο στο σύστημα. Παραδείγματος χάριν, οι μικροεπεξεργαστές χρησιμοποιούνται συνήθως ως κόμβοι επεξεργασίας σε έναν πολυεπεξεργαστικό server.

Εισαγωγή Multithreading Simultaneous Multithreading (SM) Simultaneous Subordinate Microthreading (SSMT) Speculative Data-Driven Multithreading

Multiscalar Processor (1)

Multiscalar Processor (2) Ένα απλό πρόγραμμα διαιρείται σε ένα σύνολο στοιχειωδών εργασιών. Οι στοιχειώδεις αυτές εργασίες κατανέμονται σε διάφορες μονάδες παράλληλης επεξεργασίας που βρίσκονται μέσα σε ένα σύνθετο επεξεργαστή.

Multiscalar Processor (3) Ένας multiscalar επεξεργαστής είναι μια συλλογή από μονάδες επεξεργασίας με έναν ακολουθητή (sequencer) που αναθέτει τις στοιχειώδεις εργασίες στις μονάδες επεξεργασίας.

Multiscalar Processor (4)

Multiscalar Processor (5) Μία εναλλακτική μικροαρχιτεκτονική θα μπορούσε να μοιραστεί τις λειτουργικές μονάδες (όπως οι μονάδες κινητής υποδιαστολής) μεταξύ των διαφορετικών μονάδων επεξεργασίας. Μία άλλη πιθανή μικροαρχιτεκτονική είναι αυτή όπου ο ARB και οι μνήμες δεδομένων κινούνται κατά μήκος της διασύνδεσης στην ίδια πλευρά με τις μονάδες επεξεργασίας.

Multiscalar Processor (6) Ένας multiscalar επεξεργαστής δεν πρέπει να συγχέεται με έναν πολυνηματικό (multithreaded) επεξεργαστή.

Multithreaded Synchronization Unit (SU) Execution Unit (EU) Ένα thread χαρακτηρίζεται από την state, register file, program counter, execution stack Μια multithreaded μηχανή έχει την ικανότητα να εκτελεί εντολές από αρκετά και διαφορετικά threads χωρίς να εκτελεί content switches. Ο επεξεργαστής διατηρεί μια λίστα από active threads και δυναμικά αποφασίζει ποιες εντολές thread να εκδοθούν στη μηχανή. Η συνύπαρξη των πολλαπλών ενεργών threads επιτρέπει ένας multithreading επεξεργαστής να βελτιώσει την απόδοση εκμεταλλευόμενος το Thread Level Parallelism (TLP). Εντολές από διαφορετικά threads είναι ανεξάρτητες η μια από την άλλη και κατά συνέπεια μπορούν να εκτελεστούν παράλληλα, οδηγώντας σε μεγαλύτερη χρησιμοποίηση λειτουργικών μονάδων και μεγαλύτερη ανοχή των execution latencies. Τα instruction cache misses μπορούν να είναι περισσότερο ανεκτικά. Αν ένα thread αποτύχει, ο επεξεργαστής μπορεί να εξακολουθεί να φέρνει εντολές από τα υπάρχοντα threads. Ο χειρισμός (handling) των βρόχων (brances) εποφελείται παρόμοια από τα υπάρχοντα πολλαπλά ενεργά threads. Κάθε thread περιμένει για τους βρόχους του να λυθούν πριν προχωρήσει, ή αν χρησιμοποιούνται branche prediction, μόνο το λάθος προβλεπόμενο thread χρειάζεται να γίνει flushed και να ανακευθυνθεί. Το multithreading έχει αποδειχθεί ότι βελτιώνει τη συνολική απόδοση του επεξεργαστή. Εντούτις, είναι σηματικό να σημειώσουμε ότι η απόδοση κάθε ανεξάρτητου thread δε βελτιώνεται από το multithreading. Επιπλέον, είναι πιθανό ότι η απόδοση κάθε thread μειώνεται, καθώς οι πόροι πρέπει να μοιράζονται μεταξύ όλων των ενεργών threads. Το multithreading μπορεί να έχει νόημα όταν τρέχει ένα multiprogrammed ή multithreaded έργα, αλλά δεν παρέχει κανένα πλεονέκτημα όταν ασχολείται με μια single-thread εφαρμογή. Οι πόροι που απαιτούνται για να διατηρούνται τα διάφορα ενεργά contexts δημιουργούν επιπλεόν επιπλοκές. Ένας διαφοροποιημένος fetch μηχανισμός είναι απαραίτητος, συμπεριλαμβανομένου πολλαπλών fetch points, πολλαπλών prediction structures, και πιθανά την ικανότητα να παέχει περισσότερα από ένα threads ανά κύκλο. Κάθε thread απαιτεί το δικό του register renaming table. Ο αριθμός των physical registers μπορεί επίσης να χρειάζεται να αυξηθεί, ώστε να διατηρήσει την ίδια renaming ικανότητα. Διαθέσιμη cache memory πρέπει να προστίθεται και να μοιράζεται από τα ενεργά threads. Το multithreading φέρνει και εκτελεί εντολές σε-σειρά (in-order) από πολλαπλά threads. Το simultaneous multithreading πρώτα αποφασίζει (meant) τη λήψη (fetching) εντολών από περισσότερα από ένα ενεργά threads σε ένα κύκλο και τα εκτελεί εκτός-σειράς (out-of-order) χρησιμοποιώντας το ίδιο core. Η multithreaded αρχιτεκτονική κόμβων (MTA) αποτελείται από μια μονάδα συγχρονισμού (Synchronization Unit - SU) και μια μονάδα εκτέλεσης (Execution Unit - EU) όπου οι buffers χωρίζουν τις μονάδες έτσι ώστε κάθε μονάδα να μπορεί να έχει τα σχετικά ανεξάρτητα ποσοστά ρυθμοαπόδοσης. Και το SU και το EU προσπελαύνουν την τοπική μνήμη του κόμβου επεξεργαστών, εντούτοις, το σύνολο των τοπικών μνημών κάθε κόμβου αντιπροσωπεύει ένα global memory address space. (Επομένως, μια διεύθυνση μνήμης θα αποτελούταν από ένα id κόμβων και την πραγματική διεύθυνση μέσα στην τοπική μνήμη αυτού του κόμβου.) Το SU είναι αρμόδιο για τα σήματα συγχρονισμού επεξεργασίας που εκπέμπονται από τα μηνύματα EU και επικοινωνίας από το interconnection δίκτυο. Είναι η ευθύνη του interconnection δικτύου να παραδοθούν κατάλληλα τα μηνύματα στους προορισμένους κόμβους επεξεργαστών.

Synchronization Unit (SU) Είναι αρμόδιο για την έκδοση των σημάτων ενεργοποίησης (fire signals) στην EU Fire signal : <fp,ip> Ready thread poll Fire signal : <fp,ip> frame pointer fp Διεύθυνση της πρώτης εντολής ip του thread που θα εκτελεστεί Fire signal τοποθετείται σε ένα ready thread poll από SU. Το ready thread poll είναι μια κοινή περιοχή στην τοπική μνήμη που μοιράζεται από το SU και EU-και είναι η ευθύνη της ΕU να προσκομίσει ένα fire signal από την pool. Το SU καθορίζει ποια threads είναι έτοιμα να εκτελεσθούν με την επεξεργασία των εισερχόμενων σημάτων συγχρονισμού που εκδίδονται από την EU και τα μηνύματα επικοινωνίας από το interconnection δίκτυο.

Synchronization Signals <‘spawn’, fp, ip> <‘sync’, fp, ss_off> <‘spawn’, fp, ip> <‘sync’, fp, ss_off> Τα spawn και sync σήματα μπορούν μόνο να εκδοθούν από την τοπική EU. Όταν το SU αντιμετωπίζει ένα spawn σήμα, βάζει αμέσως το fire σήμα <fp, ip> στο έτοιμο thread pool. Όσο για το σήμα sync, (fp+ss_off) δείχνει στο synchronization slot για να χρησιμοποιηθούν επάνω. Κατά τη διάρκεια της επεξεργασίας του σήματος sync, η αρίθμηση συγχρονισμού μειώνεται, εάν φθάνει στο μηδέν, η αρίθμηση τίθεται στον reset counter και ένα fire signal που αποτελείται από το fp και το δείκτη thread στην synchronization slot τίθεται στην έτοιμη thread pool.

Μηνύματα SU Data Retrieval Synchronization Thread migration <‘get’, addr_val, fp, ip> <‘data’, addr_val, value, fp, ip> Synchronization <‘backto’, fp, fut_off, ss_off, value> Thread migration <‘thread’, f_size, frame_contents, ip> Το SU είναι επίσης αρμόδιο για τα μηνύματα επικοινωνίας επεξεργασίας από το interconnection δίκτυο. Υπάρχουν τρεις τύποι μηνυμάτων επικοινωνίας: Data Retrieval – Ανάκτηση Δεδομένων <‘get’, addr_val, fp, ip> <‘data’, addr_val, value, fp, ip> Το get μήνυμα στέλνεται από ένα EU ενός επεξεργαστή σε έναν άλλο επεξεργαστή που είναι η κύρια αίτηση των δεδομένων. get: Το SU επεξεργάζεται αυτόν τον τύπο μηνύματος φέρνοντας τα δεδομένα από τη διεύθυνση μνήμης addr val, κατασκευάζοντας ένα μήνυμα δεδομένων με τις κατάλληλες τιμές πεδίων από το get μήνυμα, και εισάγοντας το δημιουργημένο μήνυμα δεδομένων στο interconnection δίκτυο. Το id του επεξεργαστή προορισμού μπορεί να εξαχθεί από το fp και να prepended στη μορφή (format ) μηνυμάτων δεδομένων. Το δίκτυο αλληλοσύνδεσης θα αφαιρούσε το id επεξεργαστών πριν παρεμβάλλει το μήνυμα στον buffer εισόδου του SU επεξεργαστή προορισμού. data: Όταν ένα SU αντιμετωπίζει ένα τέτοιο μήνυμα δεδομένων, η value τίθεται στο global­cache στη διεύθυνση addr val, και ένα fire signal <fp, ip> τίθεται στην έτοιμη thread pool. Synchronization - Συγχρονισμού <‘backto’, fp, fut_off, ss_off, value> Αυτός ο τύπος μηνύματος αντιστοιχεί στην εντολή backto στο μοντέλο DSPMD όταν η η μελλοντική κλήση (future call) μεταναστεύσει (migrate) σε έναν άλλο κόμβο επεξεργαστών. Όταν το SU επεξεργάζεται ένα μήνυμα συγχρονισμού, η value καταχωρείται στη μνήμη η διεύθυνση (fp + fut_off) και το synchronization slot στο (fp + ss_off) χρησιμοποιούνται παρόμοια σαν ένα σήμα sync που υποβλήθηκε σε επεξεργασία. Δηλαδή η αρίθμηση συγχρονισμού μειώνεται, ελεγχεται για μηδέν, κ.λπ. Το σήμα sync που περιγράφεται ανωτέρω αντιστοιχεί στο μέρος μιας εντολής backto εάν η μελλοντική κλήση υποβάλλεται σε επεξεργασία τοπικά. Thread migration <‘thread’, f_size, frame_contents, ip> Για να επεξεργαστεί αυτό το μήνυμα, το SU καλεί frame allocator για να πάρει ένα ελεύθερο frame μεγέθους f_size από την τοπική μνήμη, αντιγράφει το frame_contents στο νέο frame που προσδιορίζεται από το fp και τοποθετεί το fire signal <fp, ip> στην έτοιμη thread pool.

Execution Unit (EU) Η EU αποτελείται από: τα πολλαπλά register sets (αποκαλούμενα contents) για να κρατήσει τα contexts ενός αριθμού από ενεργά threads, μια σωλήνωσης εκτέλεσης (execution pipeline), μια local­cache για την καταχώρηση των τοπικών δεδομένων στον κόμβο επεξεργαστών, και μια global­cache Η EU έχει μερικούς μηχανισμούς για να αλλάζει μεταξύ των ενεργών threads που ενσωματώνονται στα πολλαπλά register sets. Ο μηχανισμός μετατροπής threads είναι δομημένος έτσι ώστε να συνεχίσει να εκδίδει τις εντολές από ένα ενεργό thread μέχρι τον αποκωδικοποιητή (decoder) εντολής μέσα στην εκτέλεση pipe δείχνει ότι η τρέχουσα εντολή είναι μια μη single­cycle εντολή. Σε εκείνο το σημείο, ο μηχανισμός μετατροπής αλλάζει στο επόμενο ενεργό thread και αρχίζει τις εντολές από εκείνο το thread. Αυτό θα επέτρεπε την εκτέλεση σωλήνωσης για να επικαλύψει την εκτέλεση των εντολών multi­cycle όπως οι διαδικασίες floating­point, loads, κ.λπ. με άλλες εκτελέσιμες εντολές έτσι ώστε οι καθυστερήσεις σωλήνωσης που οφείλονται στις εξαρτήσεις δεδομένων μπορούν να κρατηθούν σε ένα ελάχιστο. Κάθε register set περιέχει τους προσωρινούς registers που χρησιμοποιούνται από ένα thread για την καταχώρηση των προσωρινών values και των ειδικών registers όπως ένας μετρητής προγράμματος (ο register προσδιορίζεται ως ‘ir’) για να προσδιορίσουν την τρέχουσα εκτελέσιμη εντολή του thread, ένα register για την κράτηση του αντίστοιχου δείκτη frame (όνομα καταχωρητή ‘fr’) του thread, και ένα status register για την κράτηση των διάφορων status bits (ονόματος καταχωρητή ‘sr’). Κάθε ενεργό thread που εισάγει την EU, προσδιορίζεται ένα ελεύθερο register set, και επάνω στην έξοδο (exit), σταματά το register set του. Όταν ένα thread είναι έτοιμο να βγει από την EU, ένα jump-εντολής -που παρεμβάλλεται στο τέλος του thread από το μεταγλωττιστής – θα καλέσει τον management code όπου μια ακολουθία εντολών θα προσπαθήσει να αρχικοποιήσει ένα άλλο thread στο ακριβώς ελευθερωμένο context. Ουσιαστικά, το ενεργό thread που κατέλαβε μια φορά το context έχει σταματήσει το ανατεθειμένο context του και καταλαμβάνεται τώρα από ένα management thread. Αυτό το management thread καλείται fetch management thread ή fetch thread. Το fetch thread πρέπει να τρέξει σε ένα frame ενεργοποίησης μοναδικό στο management code, κατά συνέπεια ο frame pointer register πρέπει να τεθεί σωστά πριν από το jump στο management code. Το execution pipeline εκτελεί τον standard τύπο RISC εντολών – register to register operations, loads and stores κ.λπ.- συν άλλες εντολές όπως οι εντολές spawn και backto. Το execution pipe εκτελεί επίσης στέλνει την εντολή send για την αποστολή των μηνυμάτων στο δίκτυο. Η εντολή ‘spawn ip’ εκδίδει απλά ένα σήμα spawn που αποτελείται από το δείκτη frame στο τρέχον εκτελούμενο thread και το δείκτη εντολής ip όπως προσδιορίζεται στην spawn εντολή. Για την ‘backto fut_off ss_off’ εντολή, τα περιεχόμενα του register r0 καταχωρείται στο (fp + fut_off) όπου το fp είναι ο δείκτης frame του εκτελούμενου thread. Κατόπιν ένα σήμα sync στέλνεται στο SU που αποτελείται από το fp και το ss_off. Για τις κανονικές οδηγίες load και store, η εκτέλεση κάνει pipe τα interfaces με την τοπική μνήμη μέσω του local­cache. Το local­cache καταχωρεί μόνο τα τοπικά δεδομένα στον κόμβο επεξεργαστών και διαμοιράζεται μεταξύ της EU και του SU.

Simultaneous Multithreading Μια τεχνική που επιτρέπει σε διάφορα ανεξάρτητα threads να παρέχουν εντολές σε πολλαπλές λειτουργικές μονάδες σε κάθε κύκλο Στόχος είναι να αυξηθεί ουσιαστικά η χρησιμοποίηση επεξεργαστών

Simultaneous Multithreading Machine Models Fine-Grain Multithreading SM:Full Simultaneous Issue SM:Single Issue,SM:Dual Issue, SM:Four Issue SM:Limited Connection Υπάρχουν διαφορετικά μοντέλα.Τα μοντέλα διαφέρουν στο πως τα threads μπορούν να χρησιμοποιήσουν τα issue slots και τις λειτουργικές μονάδες σε κάθε κύκλο. Σε όλες τις περιπτώσεις η βασική μηχανή είναι μια superscalar με 10 λειτουργικές μονάδες ικανές για παροχή 8 εντολών ανά τον κύκλο: Fine-Grain Multithreading: Μόνο ένα thread παρέχει εντολές σε κάθε κύκλο, αλλά μπορεί να χρησιμοποιήσει το ολόκληρο εύρος παροχής (issue width) του επεξεργαστή. Είναι το μόνο μοντέλο που δεν παρουσιάζει simultaneous multithreading. Μεταξύ των υπαρχόντων ή προτεινόμενων αρχιτεκτονικών, αυτό μοιάζει περισσότερο με τον επεξεργαστή Tera, ο οποίος παρέχει μια εντολή 3­operation LIW ανά ταυτόχρονο κύκλο SM:Full Simultaneous Issue: Αυτό είναι ένας εντελώς εύκαμπτος simultaneous multithreaded superscalar: και τα οκτώ threads ανταγωνίζονται για κάθε ένα από τα issue slots σε κάθε κύκλο. Αυτό είναι το λιγότερο ρεαλιστικό μοντέλο από την άποψη της πολυπλοκότητας hardware, αλλά παρέχει τη διορατικότητα στη δυνατότητα για simultaneous multithreading. Τα ακόλουθα μοντέλα κάθε ένα αντιπροσωπεύουν τους περιορισμούς σε αυτό το σχέδιο που μειώνουν την πολυπλοκότητα υλικού. SM:Single Issue,SM:Dual Issue, SM:Four Issue: Αυτά τα τρία μοντέλα περιορίζουν τον αριθμό εντολών που κάθε thread μπορεί να παρέχει, ή να έχει ενεργό στο παράθυρο σχεδιασμού (scheduling window), σε κάθε κύκλο. Παραδείγματος χάριν, σε ένα SM:Single Issue κάθε thread μπορεί να παρέχει ένα μέγιστο 2 εντολών ανά τον κύκλο, επομένως, ένα ελάχιστο 4 threads θα απαιτούταν για να γεμίσει τα 8 issue slots σε ένα κύκλο. SM:Limited Connection: Κάθε hardware context συνδέεται άμεσα με ακριβώς έναν από κάθε τύπο λειτουργικής μονάδας. Για παράδειγμα, εάν το hardware υποστηρίζει 8 threads και υπάρχουν 4 μονάδες ακέραιων αριθμών, κάθε μονάδα ακέραιων αριθμών θα μπορούσε να λάβει τις οδηγίες από ακριβώς 2 threads. Ο χωρισμός των λειτουργικών μονάδων μεταξύ των threads είναι έτσι λιγότερο δυναμικός από ότι στα άλλα μοντέλα, αλλά κάθε λειτουργική μονάδα εξακολουθεί να μοιράζεται (ο κρίσιμος παράγοντας στην επίτευξη της υψηλής χρησιμοποίησης). Δεδομένου ότι η επιλογή των λειτουργικών μονάδων διαθέσιμων σε ένα μόνο thread είναι διαφορετική από την αρχική μηχανή στόχων μας, κάνουμε recompile για ένα 4­issue (ένας από κάθε τύπο λειτουργικής μονάδας) επεξεργαστή για αυτό το μοντέλο.

Machine Models Διαφορές Hardware Στον πίνακα συγκρίνεται ο αριθμός των ports που χρειάζεται για κάθε register file Το dependence checking για ένα single thread να παρέχει πολλαπλές εντολές Το ποσό του forwarding logic Τη δυσκολία του προγραμματισμού παροχής εντολών (scheduling issued instructions) σε λειτουργικές μονάδες το μοντέλο fine­grain μπορεί να μην αντιπροσωπεύσει απαραιτήτως τη φτηνότερη εφαρμογή. Πολλά από αυτά τα θέματα πολυπλοκότητας κληρονομούνται από το superscalar παρά από multithreading, αυτό καθ' εαυτό. Ακόμα και στο SM:full simultaneous issue μοντέλο, η εξάρτηση inter­instruction που ελέγχουν, οι ports per register file, και η forwarding logical scale με το εύρος ζώνης παροχής και ο αριθμός λειτουργικών μονάδων, παρά τον αριθμό threads. Η επιλογή 10 λειτουργικών μονάδων μας φαίνεται λογική για έναν επεξεργαστή 8­issue. Οι επεξεργαστές 4­issue έχουν μεταξύ 4 και 9 λειτουργικών μονάδων. Ο αριθμός ports per register file και η λογική για να επιλέξουν τις εντολές για παροχή στο 4­issue και τα περιορισμένη σύνδεση είναι συγκρίσιμοι με τους 4­issue superscalars. Οι single­issue και dual­issue είναι λιγότεροι.

Απόδοση των διάφορων μοντέλων ως λειτουργία του αριθμού threads. Το (a) Η πολύπλοκη αρχιτεκτονική fine­grain παρέχει έναν μέγιστο speedup (αύξηση στη ρυθμοαπόδοση εντολής) μόνο 2,1 πέρα από την εκτέλεση single­thread (από 1,5 IPC σε 3,2). Η γραφική παράσταση δείχνει ότι υπάρχει μικρό πλεονέκτημα στην προσθήκη περισσότερων από τεσσάρων threads σε αυτό το μοντέλο. Τα ( b,c,d) εμφανίζουν το πλεονέκτημα των simultaneous multithreading μοντέλων, που επιτυγχάνουν τα μέγιστα speedups πέρα από την superscalar εκτέλεση single­thread που κυμαίνεται από 3,2 έως 4,2, με ένα ποσοστό παροχής τόσο υψηλό όπως 6,3 IPC. Τα speedups υπολογίζονται χρησιμοποιώντας την πλήρη ταυτόχρονη παροχή, αποτέλεσμα 1­thread για να αντιπροσωπεύσει το single­thread superscalar. Με SM, δεν είναι απαραίτητο για οποιοδήποτε ενιαίο thread να είναι σε θέση να χρησιμοποιήσει ολόκληρους τους πόρους του επεξεργαστή προκειμένου να αποκτηθεί η μέγιστη ή κοντά στη μέγιστη απόδοση. Το μοντέλο four­issue φτάνει σχεδόν την απόδοση του μοντέλου full simultaneous issue, και ακόμα και το μοντέλο dual­issue είναι αρκετά ανταγωνιστικό, φθάνοντας σε 94% του full simultaneous issue σε 8 threads. Κάθε ένα από αυτά τα μοντέλα γίνεται όλο και περισσότερο ανταγωνιστικό με το full simultaneous issue καθώς η αναλογία των threads στα issue slots αυξάνεται. Με τα αποτελέσματα που εμφανίζονται στο (d), βλέπουμε τη δυνατότητα τον αριθμό hardware context ενάντια στο hardware complexity σε άλλες περιοχές. Παραδείγματος χάριν, εάν επιθυμούμε να εκτελέσουμε γύρω 4 εντολές ανά κύκλο, μπορούμε να χτίσουμε ένα four­issue ή μια full simultaneous machine με 3 έως 4 hardware contexts, μια μηχανή dual­issue με 4 πλαίσια (contexts), μια limited connection machine με 5 contexts, ή μια μηχανή single-issue με 6 contexts. Οι αυξήσεις στη χρησιμοποίηση επεξεργαστών είναι ένα άμεσο αποτέλεσμα των threads που δυναμικά διαμοιραζονται πόρους επεξεργαστών που ειδάλλως θα παραμέναν αδρανεις στο μεγαλύτερο μέρος του χρόνου, εντούτοις, ο διαμοιρασμός έχει επίσης τα αρνητικά αποτελέσματα. Βλέπουμε (c) την επίδραση του ανταγωνισμού για τα issue slots και τις λειτουργικές μονάδες στο μοντέλο full simultaneous issue, όπου το χαμηλότερης προτεραιότητας thread (σε 8 threads) τρέχει κατά 55% της ταχύτητας του υψηλότερης προτεραιότητας thread. Μπορούμε επίσης να παρατηρήσουμε τον αντίκτυπο του διαμοιρασμού άλλων πόρων του συστήματος (caches, TLBs, branch prediction table). Με το full simultaneous issue, το υψηλότερης προτεραιότητας thread, που είναι αρκετά απρόσβλητο στον ανταγωνισμό για τα issue slots και τις λειτουργικές μονάδες, υποβιβάζει σημαντικά καθώς τα περισσότερα threads προστίθενται (μια επιβράδυνση 35% σε 8 threads). Ο ανταγωνισμός για τους non­execution πόρους, έπειτα, διαδραματίζει σχεδόν έναν τόσο σημαντικό ρόλο σε αυτήν την περιοχή απόδοσης όπως ανταγωνισμός για τους πόρους εκτέλεσης. Δεν είναι απαραίτητο να υπάρξουν οι εξαιρετικά μεγάλες caches για να επιτύχει τα speedups που εμφανίζονται σε αυτό το τμήμα. Τα πειράματά μας με τις σημαντικά μικρότερες caches (που δεν εμφανίζονται εδώ) αποκαλύπτουν ότι το μέγεθος των caches έχει επιπτώσεις στα αποτελέσματα 1­thread και 8­thread εξίσου, που καθιστούν τα συνολικά speedups σχετικά σταθερά πέρα από μια ευρεία σειρά των μεγεθών caches. Δηλαδή ενώ η εκτέλεση 8­thread οδηγεί στα χαμηλότερα ποσοστά hit από την 1­thread εκτέλεση, η σχετική επίδραση της αλλαγής του μεγέθους cache είναι το ίδιο πράγμα για κάθε ένα. Εν περιλήψει, τα αποτελέσματά μας εμφανίζουν ότι simultaneous multithreading υπερβαίνει τα όρια στην εφικτή απόδοση, μέσω είτε single­thread εκτέλεσης είτε fine­grain multithreading, όταν τρέχει σε έναν superscalar. Επίσης έχουμε δει ότι οι απλουστευμένες υλοποιήσεις SM με τις περιορισμένες per­thread δυνατότητες μπορούν ακόμα να επιτύχουν την υψηλή ρυθμοαπόδοση εντολής.

Cache Design [total I cache size in KB] [private or shared].[D cache size] [private or shared] Η cache προσδιορίζεται ως: [total I cache size in KB][private or shared].[D cache size][private or shared] I cache = Instruction cache Παράδειγμα Έστω 64p.64s, έχει 8 private των 8 KB Ι caches και μια shared 64 KB data cache. Δε θα χρησιμοποιηθούν όλες οι private caches όταν τρέχουν λιγότερα από οκτώ threads. Βλέπουμε ότι οι shared caches βελτιστοποιούν για έναν μικρό αριθμό threads (όπου τα λίγα threads μπορούν να χρησιμοποιήσουν όλη τη διαθέσιμη cache), ενώ οι private caches αποδίδουν καλύτερα με έναν μεγάλο αριθμό threads. Οι 64s.64s cache πρώτα ταξινομεί μεταξύ όλων των μοντέλων σε 1 thread έως 8 threads, ενώ η cache 64p.64p δίνει σχεδόν αντίθετο αποτέλεσμα. Εντούτοις, οι ανταλλαγές δεν είναι το ίδιο πράγμα και για τις εντολές και τα δεδομένα. Μια shared data cache ξεπερνά ένα private data cache ανεξάρτητα από όλους τους αριθμούς threads (π.χ., συγκρίνετε 64p.64s με 64p.64p), ενώ οι instruction caches ωφελούν από τις private caches σε 8 threads. Ο ένας λόγος για αυτό είναι τα διαφορετικά πρότυπα πρόσβασης (access patterns) μεταξύ των εντολών και των δεδομένων. Οι private instruction caches αποβάλλουν τις συγκρούσεις μεταξύ των διαφορετικών threads στην instruction cache. Υπάρχουν δύο configurations που εμφανίζονται να είναι καλές επιλογές. Επειδή υπάρχει λίγη διαφορά απόδοσης σε 8 threads, το κόστος από τη βελτιστοποίηση για έναν μικρό αριθμό threads είναι μικρό, κάνοντας 64s.64s μια ελκυστική προαιρετική δυνατότητα. Εντούτοις, εάν αναμένουμε να λειτουργήσουμε χαρακτηριστικά με όλο ή το περισσότερο σύνολο thread slots, το 64p.64s δίνει την καλύτερη απόδοση σε εκείνη την περιοχή και δεν είναι ποτέ χειρότερο από τη δεύτερη καλύτερη εκτελεστή με λιγότερα threads.

SM vs. Single-Chip MP MP = Multiprocessing FU = Functional Unit Issue bw = Issue bandwidth Reg sets = Register sets Issue procs = εντολές ανά κύκλο που παρέχονται Στο οργανωτικό επίπεδο, οι δύο προσεγγίσεις είναι εξαιρετικά παρόμοιες: και οι δύο έχουν τα multiple register sets multiple functional units high issue bandwidth on a single chip. Η βασική διαφορά συμφωνεί με τον τρόπο που εκείνοι οι πόροι χωρίζονται και σχεδιάζονται: ο πολυεπεξεργαστής χωρίζει statically τους πόρους, αφιερώνοντας έναν σταθερό αριθμό λειτουργικών μονάδων σε κάθε thread, ο επεξεργαστής SM επιτρέπει το χωρισμό (partitioning) για να αλλάξει κάθε κύκλο. Σαφώς, ο σχεδιασμός είναι πιο σύνθετος για SM επεξεργαστή εντούτοις, θα εμφανίσουμε ότι σε άλλες περιοχές το μοντέλο SM απαιτεί τα λιγότερους πόρους, σχετικά με την πολυεπεξεργασία, στην κατάταξη για να επιτύχει ένα επιθυμητό επίπεδο απόδοσης. Για αυτά τα πειράματα, προσπαθήσαμε να επιλέξουμε SM και MP configurations που είναι ισοδύναμα, αν και σε διάφορες περιπτώσεις προκαταλάβαμε υπέρ MP. Για τις περισσότερες από τις συγκρίσεις κρατάμε όλα ή τα περισσότερα από τα ακόλουθα ίσα: ο αριθμός συνόλων threads (δηλ., ο αριθμός threads για SM και ο αριθμός processors για MP), το συνολικό εύρος παροχής (issue bandwidth), και η συγκεκριμένη functional unit configuration. Όλα τα πειράματα χρησιμοποιούν τις 8 KB private instructions και data caches (ανά thread για SM, ανά επεξεργαστή για MP), 256 KB 4­way μια set­associative shared second­level cache, και 2 ΜΒ third­level cache. Θέλουμε να κρατήσουμε τις caches σταθερές στις συγκρίσεις μας, και αυτό (private cache I και D) είναι η φυσικότερη configuration για τον πολυεπεξεργαστή. Αξιολογούμε MPs με 1,2, και 4 issues ανά τον κύκλο σε κάθε επεξεργαστή. Αξιολογούμε τους επεξεργαστές SM με 4 και 8 issues ανά κύκλο εντούτοις χρησιμοποιούμε το μοντέλο SM:Four Issue για τις όλες μετρήσεις SM μας (δηλ., κάθε thread είναι περιορισμένο σε τέσσερα issues ανά κύκλο). Η χρησιμοποίηση αυτού του μοντέλου ελαχιστοποιεί μερικές από τις έμφυτες διαφορές πολυπλοκότητας μεταξύ των SM και MP αρχιτεκτονικές. Σε κάθε πείραμα τρέχουμε την ίδια έκδοση από τις συγκριτικές μετρήσεις επιδόσεων και για τις δύο configurations (που μεταγλωττίζονται για ένα 4­issue, 4 functional unit επεξεργαστή, ο οποίος περισσότερο ταιριάζει με MP configuration) και τα μοντέλα MP και SM. Αυτό ευνοεί χαρακτηριστικά MP. Παράδειγμα πειράματος: Test C, 4 threads, 8­issue SM και ένα 4­processor, 2­issue­per­processor MP και τα δύο έχουν 4 register sets και φτάνουν μέχρι 8 εντολές ανά κύκλο. Συμπέρασμα: Αυτές οι συγκρίσεις εμφανίζουν ότι SM ξεπερνά την single­chip MP σε διάφορα configurations λόγω του δυναμικού χωρισμού των λειτουργικών μονάδων. Σημαντικότερο, το SM απαιτεί πολύ λιγότερους πόρους (λειτουργικές μονάδες και instruction issue slots) για να επιτύχει ένα δεδομένο επίπεδο απόδοσης. Παραδείγματος χάριν, ένας μόνο 8­thread, 8­issue SM επεξεργαστής με 10 λειτουργικές μονάδες είναι 24% γρηγορότερες από το 8­processor, single­issue MP (Test D), η οποία έχει το ίδιο issue bandwidth αλλά απαιτεί 32 λειτουργικές μονάδες για να είναι ίσος με τη ρυθμοαπόδοση εκείνου του 8­thread 8­issue SM, ένα MP σύστημα απαιτεί 8 επεξεργαστές 4­issue (Test E), οι οποίοι καταναλώνουν 32 λειτουργικές μονάδες και 32 issue slots ζητημάτων ανά κύκλο.

Πλεονεκτήματα SM έναντι MP Απόδοση με λίγα threads Granularity και ευελιξία σχεδιασμού Performance with few threads: αυτά τα αποτελέσματα εμφανίζουν μόνο την απόδοση στη μέγιστη χρησιμοποίηση. Το πλεονέκτημα SM (σε σχέση με το MP) είναι μεγαλύτερο καθώς μερικά από τα contexts (επεξεργαστές) γίνονται αχρησιμοποίητα (αδρανή). Ένας αδρανής επεξεργαστής παρέχει 1/p αδρανούς (idle) MP, καθώς με SM, τα άλλα threads μπορούν να επεκτείνουν για να χρησιμοποιήσουν τους διαθέσιμους πόρους. Αυτό είναι σημαντικό όταν (1) τρέχουμε τον παράλληλο κώδικα όπου ο βαθμός παραλληλισμού ποικίλλει κατά τη διάρκεια του χρόνου, (2) η απόδοση ενός μικρού αριθμού threads είναι σημαντική στο περιβάλλον, ή (3) ο φόρτος εργασίας (wordload) είναι φτιαγμένος για το ακριβές μέγεθος της μηχανής (π.χ., 8 threads). Granularity και ευελιξία σχεδιασμού: οι προαιρετικές δυνατότητες διαμόρφωσής (configuration) μας είναι πολύ πλουσιότερες με SM, επειδή οι μονάδες σχεδιασμού έχουν τη λεπτότερη granularity. Δηλαδή με έναν πολυεπεξεργαστή, θα προσθέταμε τυπικά τον υπολογισμό στις μονάδες των ολόκληρων επεξεργαστών. Με SM, μπορούμε να ωφεληθούμε από την προσθήκη ενός μόνο πόρου, όπως μια λειτουργική μονάδα, ένα register content, ή μια instruction issue slot. Επιπλέον όλα τα threads θα ήταν σε θέση να διαμοιραστούν τη χρησιμοποίηση αυτού του πόρου. Οι συγκρίσεις μας δεν εκμεταλλεύθηκαν αυτήν την ευελιξία.

Πλεονεκτήματα SM Καλύτερη ρυθμαπόδοση (throughput) Καλύτερη από fine­grain multithreaded Καλύτερη στην απόδοση από πολυεπεξεργαστή multiple­issue Λαμβάνοντας υπόψη το μοντέλο μας, μια SM αρχιτεκτονική, που διαμορφώνεται κατάλληλα, μπορεί να επιτύχει 4 φορές τη ρυθμοαπόδοση εντολής ενός single-threaded superscalar με το ίδιο issue width (8 εντολές ανά τον κύκλο, στα πειράματά μας). Η SM αρχιτεκτονική ξεπερνά την fine­grain multithreaded. Αυτό είναι οφειλόμενο στην ανικανότητα του fine­grain multithreaded να χρησιμοποιήσει τα issue slots που χάνονται εξαιτίας του horizontal waste. Μια SM αρχιτεκτονική είναι ανώτερη στην απόδοση από έναν πολυεπεξεργαστή multiple­issue, δίνοντας τον ίδιο συνολικό αριθμό από register sets και λειτουργικές μονάδες. Επιπλέον, η επίτευξη μιας συγκεκριμένης απόδοσης απαιτεί λιγότερες εκτελέσεις hardware πόρων.

Μέρος Β΄ Ή Με στόχο την αύξηση της ταχύτητας εκτέλεσης ενός προγράμματος, με άξονα την Threaded-tech.

Εντοπίζοντας το πρόβλημα… Αύξηση της αποδοτικότητας μιας multiprocessing αρχιτεκτονικής μέσω Threads – Multithreaded αρχιτεκτονική (γιατί;). Συνέπειες ως προς το χρόνο ολοκλήρωσης εκτέλεσης ενός προγράμματος μεμονωμένα; Micro-αρχιτεκτονικές micro-επεξεργαστών μέλλοντος -> πολλούς sequencers : virtual multiprocessors. Απορρόφηση/εκμετάλλευση αυξημένου δυναμικού των virtual multiprocessors via Threads : πολλά ταυτόχρονα, ανεξάρτητα εκτελούμενα προγράμματα. System-time-sharing : different program / v. processor assignment: RESULT RESULT: +αυξημένη «παραγωγικότητα» επεξεργαστή (γενικά) - χρόνος εκτέλεσης προγράμματος αυξάνεται (ειδικά) (due to resource sharing)

Εντοπίζοντας το πρόβλημα(2)... ΖΗΤΕΙΤΑΙ : επιτάχυνση της εκτέλεσης των Threads μεμονωμένα. Υπάρχει «χώρος» γι αυτό; To ζητούμενο λοιπόν: Επιτάχυνση της εκτέλεσης κάθε Thread ξεχωριστά. Πώς: εντο- και αντιμετω-πίζοντας παράγοντες καθυστέρησης (bandwidth under-utilization): -cache misses -partial issue cycles -branch mispredictions (see also Multiple Path mechanisms) -insufficient ILP Στην εικόνα: σύγκριση ταχύτητας εκτέλεσης μιας μηχανής με πραγματικό branch predictions και caching με μια θεωρητική με τέλεια αντίστοιχα. Δώσε λοιπόν στον επεξεργαστή να δουλέψει για να καλύψει το κενό!

Simultaneous Subordinate Microthreading (SSMT) Δηλαδή η παραγωγή επιπρόσθετων microthreads για τη βελτίωση του χρόνου εκτέλεσης ενός – του κυρίως – Thread του προγράμματος. Τα micro- γεννώνται και εκτελούνται εκ παραλλήλου με το κυρίως Thread. Branch prediction accuracy – cache hit rate – prefetch effectiveness Γενικότερα μια multithreaded αρχιτεκτονική έχει νόημα όταν αυτή τρέχει multiprogrammed ή multithreaded δουλειές, όχι όταν χρησιμοποιείται από single-threaded εφαρμογές.

ΕΠΕΞΗΓΗΣΗ ΕΙΚΟΝΑΣ Οι microthread ρουτίνες είναι κώδικας που αποτελείται από εντολές κατανοητές απευθείας από τον επεξεργαστή μπορεί να αποθηκευτεί στη micro-RAM συγκεκριμένα γεγονότα (events) προκαλούν την «γεννοβόλη» ενός microthread του οποίου οι εντολές εισάγονται στη Code/Renaming φάση. ξεχωριστό renaming των εντολών αυτών από αυτές του primary thread – χρήση ξεχωριστών Register Alias Tables (RAS) Η issue logic επιλέγει εντολές και από τα δύο Threads προς τα reservation stations Τώρα οι εντολές μπορούν να εκτελεστούν ταυτόχρονα ανάλογα και με ποιο execution scheme (out of order, superscalar κλπ) χρησιμοποιείται.

Micro-thread spawning Spawn instruction ως μέρος της ISA (Instruction Set Architecture) Event spawning : ένα προκαθορισμένο γεγονός κατά την εκτέλεση του κυρίως thread προκαλεί τη γέννηση του microthread. Decoding μια spawn instruction ορίζει μια microthread ρουτίνα. Καθε τύπος event προκαλεί τη γέννηση και διαφορετικού microthread. Possible events: cache misses, branch mispredictions, timer expirations

Πλεονεκτήματα της SSMT SSMT vs Hardware based μηχανισμοί Hardware πολυπλοκότητα; - αδιαφορία Ευελιξία Microthreads vs απλά Threads Fetch – issue – ISA Νέος επεξεργαστής; SSMT έναντι Hardware-based μηχανισμούς : -εξελιγμένοι αλγόριθμοι σε micro-code αδιαφορώντας για hardware πολυπλοκότητα micro-code instructions εκτελούνται στην υπάρχουσα datapath -κούρδισε τις ρουτίνες ώς προς συγκεκριμένες εφαρμογές και επεξεργαστές ή απενεργοποίησέ τις αν δεν χρειάζονται. Εναλλακτική: αντί για microthreads -> conventional Threads But -Μικρές και εξειδικευμένες Ρουτίνες βελτιστοποίησης στην micro-RAM -> μη αλληλεπιδρώντα fetches. -microthreads not in instruction cache (no cache misses) => microthread instructions always available for issue. -microthreads είναι γραμμένα με βάση το instruction set του επεξεργαστή => όχι διόρθωση/τροποποίηση (μόνο προσθήκη) στο υπάρχων ISA. MEIONEKTHMA: new processor implementations => rewrite microthread!

Τα απαραίτητα υλικά ISA υποστήριξη (εντολές για τη micro-RAM, spawn εντολή, microcontext) Compiler και OS υποστήριξη Hardware υποστήριξη (Micro-RAM,decode/rename, microcontext support, register sets) ISA: προσθήκες. instructions για load (νέο microthread) και unload της micro-RAM. explicit spawn of microthreads (spawn instruction) microthread # = η συγκεκριμένη microthread ρουτίνα στη micro-RAM που θα φορτωθεί στη μηχανή parameter =τιμή που περνάται στη ρουτίνα μέσω ειδικού register(MSPR) Για ανεξαρτησία microthread από Thread -> maintain architectural state, i.e. separate set of registers -> microcontext Microthread General/Special Purpose Registers (MGPR/MSPR) MGPR -> used by microthreads MSPR -> info about state of primary thread at the time of invocation of microthread COMPILER & OS support SSMT compiler : αποφάσεις αν χρειάζεται microthreading και που κλπ. microRAM management, microthread memory allocation/data initialization klp. HARDWARE SUPPORT Α. micro-RAM : access by - microthread number (spawn instruction) - microthread instruction number(branches within the microthread routines) Μερικοί επεξεργαστές ενσωματόνουν micro-engines κατάλληλες γι αυτό το σκοπό(ΡΑΜ). Β. Fetch μηχανισμός ώς έχει αφού ρουτίνες on chip όμως decode/rename πρέπει να υποστηρίζει issuing of instructions και από τα δύο (ταυτόχρονα μαλιστα!) Γ. Υποστήριξη τουλάχιστον ενός microcontext. (more => more routines exec.conc.) queing if none available at the moment Δ. Register sets για κάθε microcontext.

Βελτιστοποιημένη εκτέλεση BP : compiler synthesis of dynamic branch prediction taken over by microthreads Prefetching : prefetch explicitly (via spawn instruction + routine ) or implicitly (spawn on events + routine ) Cache management : e.g. adaptive replacement policy BP : compiler analyzes program semantics -> insert instructions in program, I.e. communicate with the processor’s BP hardware (example: exit from loops) Microthread synthesis routines stored on chip, invoked by spawn instruction Also autonomous BP by microthreads (not a compiler synthesis enhancement) Pre-fetching: normally done via special FETCH instruction (loads a single cache line to L1) Here: SPAWN instr. to invoke routine that fetches several disjoint cache lines at once, prefetch an array (via loop), or pointer-like structures (via traversal in the microthread) Also conditional prefetching (prefetching based on information gathered at run- time) Also use event spawns to implement existing hardware prefetching algos. Then spawn microthreads on events such as detecting a usefull/useless/late prefetch and use info to alter prefetching algorithm. Cache management: adaptive replacement policy => usually general policy embeded on cache structures microthread spawned at cache miss -> maintains miss info about every cache line touched by primary thread -> provide feedback to guide replacement policy of the cache. RESULT : more intelligent caching without additional hardware

Παράδειγμα : BP Hybrid scheme : processor hardware predictor + microthread based predictor (SSMT) SPAWN => παραπάνω δουλειά. Τι πρέπει να προσέχει κανείς; MBP είναι μεγάλη και πολύπλοκη ιστορία και καθώς οι hardware predictors είναι υψηλής ακρίβειας η εκτέλεση των MBP έχει νόημα για branches που δύσκολα προβλέπονται σωστά. που δύσκολα προβλέπονται σωστά <= αυτά ανιχνεύονται με profiling = identify places in the program that take the most time to execute. ΠΕΡΙΓΡΑΦΗ - SPAWN instruction – microthread generates prediction for next time of branch fetch [– prediction for current instance of branch exists from last microthread invocation] -microthread stores prediction in prediction Cache + branch fetch address - at branch fetch access both hardware + prediction cache. Fetches that hit in the cache use the stored prediction and invalidate it. Otherwise use hardware prediction ΠΡΟΣΟΧΗ : ο χρόνος που εξοικονομείται από τα mispredictions πρέπει να είναι μεγαλύτερος από το χρόνο που χρειάζεται το microthread. => προσοχή σε ποιά branches θα γίνεται microthread spawning.

Πειράματα BP hardware predictor – 16KB gshare Microthread routine – PAg implementation Ποιές branches αναλαμβάνονται από microthreads; Compiler Selection Heuristic Δεν/Επιδεικνύουν Per-Address correlation PAg Per Address Branch History Register Global Pattern History Table Αλληλοσυμπληρώνονται στατικά branches: ο compiler συγκρίνει την ακρίβεια των δύο μεθόδων. Αν υπερτερεί ο PAg : υπολογίζει # cycles saved = πολ/ζει # mispredicts – μέσο resolution time of branch # cycles lost to executing microcode = dynamic execution count of branch * # cycles to issue one invocation of the microthread routine. Insert SPAWN instruction to that routine if NET cycle savings

FIGURE 6 The microthread routine steals issue and execution bandwidth from primary thread – No The microthread routine introduces additional memory instructions, which compete for memory bandwidth and cache space – No Prediction cache – prediction missing – Yes – microroutine not enough time to compute it Make use of such cases to redirect Fetch if hardware prediction different from microthread (is more accurate according to compiler). If not different => wasted time

Speculative Data-Driven Multithreading Microthread > Data-driven thread Primary thread > Control-driven thread SPAWN > FORK Critical instructions (branches, loads) Prediction cache > integration GOAL: prioritize critical instructions Encounter CI – fork DDT – run in parallel with main thread DDT runs faster – executes only critical computation => consumes the latency A DDMT component INTEGRATION incorporates results computed in DDTs directly into the main thread, sparing it from repeating the work Register INTEGRATION technique makes use of the fact that both the main + DDT place results in a shared physical register file

DDT consists of choice of 5 instructions (I10(trigger) I10 I2 I3 I5) Main thread and DDT run in parallel starting from the trigger… 4-wide machine: MT 1st for cycle 3 2nd for cycle 6 DDT 1st and 2nd for in one cycle - cycle 2 + 3 to execute+finish DDTs represented in processor via DDTraceCache (5) [DDT’s as ordered lists of instructions] Triggered : new context for DDT + copy of the main Thread’s post-trigger rename-map(6) DDT can: access results of MT allocate storage for own results communicate results among own instructions SPECULATIVELY – results into the physical register file <- indexed by IT(7) [read table] Main Thread comes to rename critical instructions : identify – use

Extracting Threads from a Program Trace (algo) Work backwards: Misbehaving instance of a critical instruction is a DDT candidate (1) add more a) such instances or b) their memory dependences(3) I3->I2 Trigger: last added instr. When to stop: When DDT is good enough (metrics FCDH – add+evaluate)

Life cycle of a Data-Driven Thread At which stage fork a DDT? When TRIGGER instruction: Early -> Fetch -> incr. Probability of mis-speculation of trigger instruction -> but if OK, good advantage over control driven Thread Empirically -> not good rename -> reduces false forks at 50% trigger commit -> no false forks SMT architecture DESCRIBE LIFE CYCLE: - FORK – (2) renaming –> appears CONTEXTcopy (map etc 4 integration) - (3)thread controller schedules new DDT for fetch - (4) fetch DDT from cache trace, place in IFQ - (5) upon exit from IFQ, renamed + create entries in Integration Table (IT) - (6) go to Out of Order execution engine – get an RS slot. [No ROB no memory orderding buffers (LDQ, STQ)] - (7) issue from RS as conventional instructions PREG=Physical Registers - (8) speculative memory cloaking variation address/value pairs buffer + cache - (9) remap output if matching instruction found - (10) post-rename handling of integrated instruction ROB… no RS…

Register Integration Μηχανισμός που επιτρέπει την απο κοινού επαναχρησιμοποίηση ήδη υπολογισμένων αποτελεσμάτων μεταξύ διαφορετικών execution contexts ενός προγράμματος Thread <- DDT DDT <- other DDT DDT <- Thread

Performance Evaluation 8-wide SMT DDTC, cloaking table Targeting Cache misses : latencies in L1 CACHE Latencies of Load misses in L1: [GOOD:Induction unrolling] Performance limitations: DDT overhead A.Reduced load latency => reduce time 4 branch resolution => Fetch contention B.Instruction integraded : after commpleted instructions after issued but before completed instructions before issued: useless 2 factors: a) fork at renaming stage (bad when trigger lies on mis-speculated path) b) speculation about instances of critical instructions (is dynamic)

Performance Evaluation (contnd.) Targeting Branch Mispredictions BRANCH Completed DDT -> instant correct branch resolution Non-completed ->DDT depends on how much computation is done.