Advcomparch April 2014

advcomparch@lists.cslab.ece.ntua.gr

5 participants
10 discussions

Re: [Advcomparch] Απορία
by Konstantinos Nikas 04 Apr '14

04 Apr '14

Καλησπέρα, 1) Έχουμε αναλύσει πολλές φορές αυτό το θέμα (και κατά πάσα πιθανότητα υπάρχει ήδη κάποια απάντηση στα αρχεία της λίστας). Το flush γίνεται μέσα στο pipeline. Δεν υπάρχει η δυνατότητα να πει ο επεξεργαστής στη cache "σταμάτα μη μου το φέρεις τελικά αυτό που σου ζήτησα". Έχετε δει πλέον τα πρωτόκολλα συνάφειας, άρα μπορείτε να εκτιμήσετε την πολυπλοκότητα μιας τέτοιας κίνησης. Προφανώς αυτό δημιουργεί ένα θέμα όταν εκτελεστεί στο ΕΧ ένα store που βρίσκεται σε mispredicted path. Για αυτό το λόγο, όπως έχουμε πει στο μάθημα τα stores μπαίνουν σε ένα write buffer και μεταφέρονται στην cache όταν η εντολή store κάνει commit. Καταχρηστικά, για ευκολία στην άσκηση θεωρούμε ότι το store "εκτελείται" και αυτό στο στάδιο EX. Δεν μπορεί να είναι τυχαίο όμως ότι σε όλες τις ασκήσεις και τα θέματα δεν έχετε ποτέ συναντήσει store σε mispredicted path... 2) Είναι καθαρά θέμα υλοποίησης και αρχιτεκτονικής. Σε μια αρχιτεκτονική όπως ο MIPS που οι εντολές απέχουν πάντα 4 bytes, είναι "χαζό" (μη αποδοτικό) να χρησιμοποιείς τα 2 LSB, τα οποία είναι πάντα 0. Σε άλλες αρχιτεκτονικές όμως μπορεί να μην είναι δυνατό να τα αγνοείς. Τώρα, στα θέματα που αναφέρεσαι, νομίζω ότι μόνο σε μια περίπτωση δεν τα είχαμε αγνοήσει (και αυτό είχε συμβεί λόγω συγκεκριμένου λάθους εκφώνησης/διευκρίνισης κτλ). Κ. 2014-04-03 21:44 GMT+03:00 Elgo Kostas <kostakiskakos(a)hotmail.com>: > Καλησπέρα! Θα ήθελα ρωτήσω κι εγώ κάτι! > > 1) Στον tomasulo όταν έχω λάθος πρόβλεψη για μια εντολή διακλάδωσης > ακολουθούν κάποιες εντολές μέχρι να γίνει γνωστό το αποτέλεσμα της > διακλάδωσης οι οποίες στη συνέχεια γίνονται flush. Έστω ότι στις εντολές > αυτές υπάρχει μια load ή store. H κατάσταση στην cache επηρεάζεται μόνο αν > προλάβει να ολοκληρωθεί το στάδιο EX της εντολής load/store; Τι γίνεται με > την cache αν το EX "κοπεί" στη μέση; > > 2) Βλέπω στα θέματα αλλού αγνοούμε τα 2 τελευταία bits του PC για τη > δεικτοδότηση των predictors και αλλού όχι. Τι από τα δύο είναι σωστό; > > Ευχαριστώ > > _______________________________________________ > Advcomparch mailing list > Advcomparch(a)lists.cslab.ece.ntua.gr > http://lists.cslab.ece.ntua.gr/mailman/listinfo/advcomparch > -- Dr. Konstantinos Nikas Computing Systems Laboratory School of Electrical and Computer Engineering National Technical University of Athens Tel: +30-210-7724159 e-mail: knikas(a)cslab.ece.ntua.gr http://www.cslab.ece.ntua.gr/~knikas

1 0

Re: [Advcomparch] branch prediction
by Konstantinos Nikas 04 Apr '14

04 Apr '14

To 1o σχήμα δείχνει το FSM ενός 2-bit predictor όπως έχει προταθεί στη βιβλιογραφία. Εμείς όμως (όπως έχουμε εξηγήσει στο μάθημα και σε κάθε θέμα που κοιτάμε branch predictors) θεωρούμε (συνήθως) ένα πιο απλό FSM στο οποίο οι μεταβάσεις είναι + ή - 1. Κ. 2014-04-03 21:31 GMT+03:00 <fbourikas(a)easyrental.gr>: > Καλησπέρα, έχω την εξής ερώτηση: Στον 2-bit branch predictor, δηλαδή στις > διαφάνειες του branch prediction, στην 22η διαφάνεια, το σχήμα δείχνει ότι > αν βρισκόμαστε στο 1 (01) και γίνει Taken πάμε στο 3 (11), σωστά? Γιατί στην > αμέσως επόμενη διαφάνεια στην αρχή είναι στο 1 και με T πάει στο 2 και μετά > στο 3. > Ευχαριστώ > > _______________________________________________ > Advcomparch mailing list > Advcomparch(a)lists.cslab.ece.ntua.gr > http://lists.cslab.ece.ntua.gr/mailman/listinfo/advcomparch > -- Dr. Konstantinos Nikas Computing Systems Laboratory School of Electrical and Computer Engineering National Technical University of Athens Tel: +30-210-7724159 e-mail: knikas(a)cslab.ece.ntua.gr http://www.cslab.ece.ntua.gr/~knikas

1 0

Απορία
by Elgo Kostas 03 Apr '14

03 Apr '14

Καλησπέρα! Θα ήθελα ρωτήσω κι εγώ κάτι! 1) Στον tomasulo όταν έχω λάθος πρόβλεψη για μια εντολή διακλάδωσης ακολουθούν κάποιες εντολές μέχρι να γίνει γνωστό το αποτέλεσμα της διακλάδωσης οι οποίες στη συνέχεια γίνονται flush. Έστω ότι στις εντολές αυτές υπάρχει μια load ή store. H κατάσταση στην cache επηρεάζεται μόνο αν προλάβει να ολοκληρωθεί το στάδιο EX της εντολής load/store; Τι γίνεται με την cache αν το EX "κοπεί" στη μέση; 2) Βλέπω στα θέματα αλλού αγνοούμε τα 2 τελευταία bits του PC για τη δεικτοδότηση των predictors και αλλού όχι. Τι από τα δύο είναι σωστό; Ευχαριστώ

1 0

branch prediction
by fbourikas＠easyrental.gr 03 Apr '14

03 Apr '14

Καλησπέρα, έχω την εξής ερώτηση: Στον 2-bit branch predictor, δηλαδή στις διαφάνειες του branch prediction, στην 22η διαφάνεια, το σχήμα δείχνει ότι αν βρισκόμαστε στο 1 (01) και γίνει Taken πάμε στο 3 (11), σωστά? Γιατί στην αμέσως επόμενη διαφάνεια στην αρχή είναι στο 1 και με T πάει στο 2 και μετά στο 3. Ευχαριστώ

1 0

Re: [Advcomparch] Απορίες.
by Konstantinos Nikas 03 Apr '14

03 Apr '14

Η cache A έχει το block X σε κατάσταση Μ. Όταν η cache Β ζητήσει το Χ (και εφόσον έχουμε διάδρομο) τότε θα γίνει 1 BusRdX transaction, στο οποίο θα πάρουν τα δεδομένα τόσο η B όσο και η μνήμη. Κ. 2014-04-03 14:43 GMT+03:00 Ανδρέας Παντελόπουλος <padelopoulos(a)gmail.com>: > Συνεχίζοντας την ερώτηση μου λοιπόν, αφού ισχύουν τα παραπάνω και έστω > κάποια cache φύγει από το M και πρέπει να γράψει στην μνήμη κάποιο block > αλλά και να κάνει κάποια cache-to-cache transfer. Έστω λοιπόν ότι το καθένα > απο αυτά κοστίζει x κύκλους. Τότε το συνολικό κόστος και των 2 λειτουργιών > θα είναι x ή 2x? > > Αντίστοιχο θέμα είχε πέσει και στην κανονική. Το δίλημα μου προκύπτει από το > γεγονός ότι στο bus κάνεις broadcast κάτι και το ακούνε όλοι. > Ελπίζω να έγινα κατανοητός. > > Ευχαριστώ πολύ. > > > Στις 3 Απριλίου 2014 - 1:22 μ.μ., ο χρήστης Konstantinos Nikas > <knikas(a)cslab.ece.ntua.gr> έγραψε: >> >> Καλημέρα, >> >> όταν η cache είναι Μ, προφανώς έχεις cache-to-cache. Η υλοποίηση >> παίζει ρόλο στο ποιος απαντάει όταν ζητηθεί κάτι που το έχει μια άλλη >> cache S. Εμείς υποθέτουμε ότι σε αυτή την περίπτωση απαντά η cache, >> αλλά σε κάποια "χαζή" υλοποίηση θα μπορούσε να παρέχει τα δεδόμενα και >> το επόμενο επίπεδο μνήμης. >> >> Στο 2ο ερώτημα δε νομίζω ότι χρειάζεται να απαντήσω :-). >> >> K. >> >> 2014-04-03 13:08 GMT+03:00 Ανδρέας Παντελόπουλος <padelopoulos(a)gmail.com>: >> > Καλημέρα στο πρωτόκολλο MESI θα ήθελα να ξεκαθαρίσω κάτι. >> > >> > Συγκεκριμένα cache-to-cache μεταφορά δεδομένων πότε ακριβώς έχουμε? Στις >> > διαφάνειες λέει μόνο ότι στο M state η cache είναι υπεύθυνη για να >> > παρέχει >> > τα δεδομένα σε όποιον τα ζητήσει, αν και νομίζω ότι έχει ειπωθεί ότι >> > είναι >> > και θέμα υλοποίησης. >> > >> > Επίσης, στο ίδιο πρωτόκολλο με τις write-back caches, η εγγραφή στην >> > μνήμη >> > ενός block θα γίνει από την cache που ήταν στο state M σε αυτό το block, >> > την >> > στιγμή που αναγκάζεται να φύγει από αυτό το state? Λόγω μίας άλλης >> > εγγραφής >> > στο ίδιο block από άλλον επεξεργαστή, ή λόγω ενός read. >> > >> > Ευχαριστώ πολύ. >> > Παντελόπουλος Ανδρέας. >> > >> > _______________________________________________ >> > Advcomparch mailing list >> > Advcomparch(a)lists.cslab.ece.ntua.gr >> > http://lists.cslab.ece.ntua.gr/mailman/listinfo/advcomparch >> > >> >> >> >> -- >> Dr. Konstantinos Nikas >> Computing Systems Laboratory >> School of Electrical and Computer Engineering >> National Technical University of Athens >> >> Tel: +30-210-7724159 >> e-mail: knikas(a)cslab.ece.ntua.gr >> http://www.cslab.ece.ntua.gr/~knikas > > -- Dr. Konstantinos Nikas Computing Systems Laboratory School of Electrical and Computer Engineering National Technical University of Athens Tel: +30-210-7724159 e-mail: knikas(a)cslab.ece.ntua.gr http://www.cslab.ece.ntua.gr/~knikas

2 2

Re: [Advcomparch] Απορίες
by Konstantinos Nikas 03 Apr '14

03 Apr '14

ΟΚ τώρα κατάλαβα. Ναι προφανώς χρειάζεσαι και το συνολικό αριθμό των entries. Στη συγκεκριμένη περίπτωση δίναμε 16 entries. Απλά είχε γίνει κάποιο λάθος κατά τη δημιουργία των λύσεων. Το διορθώσαμε (μαζί με άλλο ένα λάθος στο ίδιο θέμα) και το ανεβάσαμε στο site. K. 2014-04-03 15:53 GMT+03:00 George Matikas <g_matikas(a)hotmail.com>: > Σας ευχαριστώ για την άμεση απάντηση στις απορίες μου! > > Όσον αφορά την 3η απορία μου: > > 3) Αυτό που εννοώ είναι ότι, πέραν του μεγέθους (2, 2) για τον global > history predictor, δεν χρειαζόμαστε και τον αριθμό των bits που > διευθυνσιοδοτούν τον πίνακα PHT; Γιατί από το μέγεθος (2, 2) αυτό > που συμπεραίνουμε μόνο είναι ότι για κάθε εγγραφή του PHT έχουμε > 4 2-bit predictors. Αλλά χωρίς τον αριθμό bit που ανέφερα παραπάνω > δεν γνωρίζουμε πόσες εγγραφές έχει ο PHT συνολικά και οπότε δεν > μπορούμε να συμπεράνουμε αν τα δύο branches “πέφτουν” τελικά > πάνω στην ίδια τετράδα 2-bit predictors του PHT (αν δηλαδή έχουμε > aliasing) ή αν πέφτουν σε διαφορετικές τετράδες. > > Ευχαριστώ, > Ματίκας Γεώργιος > > > On Thursday, 3 April 2014 at 12:48 μ.μ., Konstantinos Nikas wrote: > >> Καλημέρα, >> >> 1) Τα παραδείγματα στα οποία αναφέρεσαι είναι από το βιβλίο (Παράρτημα >> Α5, σχήματα Α33, Α34 στην ελληνική (3η) έκδοση), όπου μπορείς να βρεις >> λίγο παραπάνω λεπτομέρειες. >> >> Στη διαφάνεια 40 η εντολή κάνει stall γιατί όπως έχουμε μάθει στο απλό >> 5-stage pipeline δεν μπορεί να βρίσκεται παραπάνω από μια εντολή στο >> ίδιο στάδιο. Όπως όμως λέει το κείμενο (και εμείς στην παράδοση), >> μπορεί το πρόβλημα αυτό να αντιμετωπιστεί με επιπλέον υλικό. Έτσι >> καταλήγουμε στη διαφάνεια 41, όπου σωστά υποθέτεις ότι οι εντολές >> μπορούν να βρίσκονται ταυτόχρονα στο ΜΕΜ, καθώς μόνο μια από αυτές >> χρησιμοποιεί τη μνήμη και άρα δεν υπάρχει πραγματικός structural >> hazard. >> >> 2) Το loop unrolling προφανώς βοηθάει στα control stalls. Βοηθάει όμως >> και στα data hazards stalls (αναφερόμαστε πάντα σε in-order >> επεξεργαστή). Σκέψου τον εξής κώδικα: >> >> for(i = 0; i < N; i++) >> a[i]++; >> >> o οποίος σε επίπεδο assembly είναι ld -> add -> st με RAW >> dependencies, τα οποία προκαλούν stalls. Αν κάνεις unrolling, τότε ο >> compiler θα μπορέσει να αναδιατάξει τις εντολές και να επικαλύψει έτσι >> τα stalls με χρήσιμη δουλειά. >> >> 3) Δεν είμαι σίγουρος ότι καταλαβαίνω τι με ρωτάς. Όταν λέμε ότι >> υπάρχει ένας global history predictor, δίνουμε και τα χαρακτηριστικά >> του (στο θέμα που αναφέρεις λέμε ότι είναι (2,2)) με βάση τα οποία >> μπορείτε να τον "σχεδιάσετε" και να καταλάβετε τη δομή και τη >> λειτουργία του. >> >> Κ. >> >> >> 2014-04-03 2:46 GMT+03:00 George Matikas <g_matikas(a)hotmail.com (mailto:g_matikas@hotmail.com)>: >> > Γεια σας! >> > >> > Καθώς προετοιμάζομαι για την ερχόμενη εξέταση της Παρασκευής μου γεννήθηκαν >> > κάποιες απορίες. Θα μπορούσατε να με βοηθήσετε να τις λύσω; >> > >> > 1) Στις διαφάνειες "Lec1-overview-13" στη σελίδα 41, αναφέρει ότι υπάρχει το ενδεχόμενο >> > να εμφανιστεί structural hazard λόγω ταυτόχρονης εγγραφής του register file στο στάδιο WB. >> > Ωστόσο, πιστεύω ότι αυτό δεν είναι εφικτό, αφού πάντα πριν το στάδιο WB βρίσκεται στο >> > pipeline του παραδείγματος το στάδιο MEM. Άρα θα έχουμε εκεί structural hazard και >> > επομένως stall και δεν θα συμπέσουν ποτέ 2 WB στάδια. Μία σκέψη που μου πέρασε από το >> > >> > μυαλλό είναι ότι δεν μας πειράζει που θα πέσουν δύο ή περισσότερα στάδια MEM μαζί από >> > τη στιγμή που οι εντολές αυτές δεν κάνουν τίποτα στα στάδια αυτά (δηλαδή δεν διαβάζουν >> > ή γράφουν τη μνήμη), οπότε και γι’ αυτό επιτρέπουμε να πέσουν μαζί και δεν έχουμε stall >> > όπως ανέφερα παραπάνω. Ωστόσο, η σκέψη αυτή αναιρείται από την προηγούμενη σελίδα >> > των διαφανειών (σελ. 40) όπου τοποθετείται ένα επιπλέον stall ανάμεσα στις 2 τελευταίες >> > εντολές για να μην συμπέσουν τα στάδια MEM τους, παρόλο που η μία δεν κάνει τίποτα σε >> > αυτό το στάδιο. >> > >> > 2) Στις διαφάνειες αναφέρετε συχνά σε ένα συγκεκριμένο slide (πχ "Lec5-dynamic-13.pps” >> > σελ. 3) ότι το loop unrolling βοηθάει στα Data Hazard Stalls, αλλά δεν μπορώ να καταλάβω >> > >> > γιατί αυτό συμβαίνει. Μήπως το βελάκι προοριζόταν να δείχνει ότι το loop unrolling βοηθάει >> > στα Control Stalls; >> > >> > 3) Όταν αναφέρετε ότι μας δίνεται “ένας” global history predictor, όπως πχ στο θέμα 3 της >> > εξέτασης Ιουλίου 2010, εννοείται ότι κάθε εντολή άλματος έχει τις δικιές της εγγραφές >> > στον PHT με βάση τα τελευταία bits του PC ή ότι όλες έχουν το ίδιο σετ εγγραφών και >> > όλες χρησιμοποιούν αυτό; >> > >> > >> > Ευχαριστώ εκ των προτέρων, >> > Ματίκας Γεώργιος >> > >> > >> > _______________________________________________ >> > Advcomparch mailing list >> > Advcomparch(a)lists.cslab.ece.ntua.gr (mailto:Advcomparch@lists.cslab.ece.ntua.gr) >> > http://lists.cslab.ece.ntua.gr/mailman/listinfo/advcomparch >> >> >> >> >> >> -- >> Dr. Konstantinos Nikas >> Computing Systems Laboratory >> School of Electrical and Computer Engineering >> National Technical University of Athens >> >> Tel: +30-210-7724159 >> e-mail: knikas(a)cslab.ece.ntua.gr (mailto:knikas@cslab.ece.ntua.gr) >> http://www.cslab.ece.ntua.gr/~knikas > > > -- Dr. Konstantinos Nikas Computing Systems Laboratory School of Electrical and Computer Engineering National Technical University of Athens Tel: +30-210-7724159 e-mail: knikas(a)cslab.ece.ntua.gr http://www.cslab.ece.ntua.gr/~knikas

1 0

Re: [Advcomparch] Απορίες
by Konstantinos Nikas 03 Apr '14

03 Apr '14

Καλημέρα, 1) Τα παραδείγματα στα οποία αναφέρεσαι είναι από το βιβλίο (Παράρτημα Α5, σχήματα Α33, Α34 στην ελληνική (3η) έκδοση), όπου μπορείς να βρεις λίγο παραπάνω λεπτομέρειες. Στη διαφάνεια 40 η εντολή κάνει stall γιατί όπως έχουμε μάθει στο απλό 5-stage pipeline δεν μπορεί να βρίσκεται παραπάνω από μια εντολή στο ίδιο στάδιο. Όπως όμως λέει το κείμενο (και εμείς στην παράδοση), μπορεί το πρόβλημα αυτό να αντιμετωπιστεί με επιπλέον υλικό. Έτσι καταλήγουμε στη διαφάνεια 41, όπου σωστά υποθέτεις ότι οι εντολές μπορούν να βρίσκονται ταυτόχρονα στο ΜΕΜ, καθώς μόνο μια από αυτές χρησιμοποιεί τη μνήμη και άρα δεν υπάρχει πραγματικός structural hazard. 2) Το loop unrolling προφανώς βοηθάει στα control stalls. Βοηθάει όμως και στα data hazards stalls (αναφερόμαστε πάντα σε in-order επεξεργαστή). Σκέψου τον εξής κώδικα: for(i = 0; i < N; i++) a[i]++; o οποίος σε επίπεδο assembly είναι ld -> add -> st με RAW dependencies, τα οποία προκαλούν stalls. Αν κάνεις unrolling, τότε ο compiler θα μπορέσει να αναδιατάξει τις εντολές και να επικαλύψει έτσι τα stalls με χρήσιμη δουλειά. 3) Δεν είμαι σίγουρος ότι καταλαβαίνω τι με ρωτάς. Όταν λέμε ότι υπάρχει ένας global history predictor, δίνουμε και τα χαρακτηριστικά του (στο θέμα που αναφέρεις λέμε ότι είναι (2,2)) με βάση τα οποία μπορείτε να τον "σχεδιάσετε" και να καταλάβετε τη δομή και τη λειτουργία του. Κ. 2014-04-03 2:46 GMT+03:00 George Matikas <g_matikas(a)hotmail.com>: > Γεια σας! > > Καθώς προετοιμάζομαι για την ερχόμενη εξέταση της Παρασκευής μου γεννήθηκαν > κάποιες απορίες. Θα μπορούσατε να με βοηθήσετε να τις λύσω; > > 1) Στις διαφάνειες "Lec1-overview-13" στη σελίδα 41, αναφέρει ότι υπάρχει το ενδεχόμενο > να εμφανιστεί structural hazard λόγω ταυτόχρονης εγγραφής του register file στο στάδιο WB. > Ωστόσο, πιστεύω ότι αυτό δεν είναι εφικτό, αφού πάντα πριν το στάδιο WB βρίσκεται στο > pipeline του παραδείγματος το στάδιο MEM. Άρα θα έχουμε εκεί structural hazard και > επομένως stall και δεν θα συμπέσουν ποτέ 2 WB στάδια. Μία σκέψη που μου πέρασε από το > > μυαλλό είναι ότι δεν μας πειράζει που θα πέσουν δύο ή περισσότερα στάδια MEM μαζί από > τη στιγμή που οι εντολές αυτές δεν κάνουν τίποτα στα στάδια αυτά (δηλαδή δεν διαβάζουν > ή γράφουν τη μνήμη), οπότε και γι’ αυτό επιτρέπουμε να πέσουν μαζί και δεν έχουμε stall > όπως ανέφερα παραπάνω. Ωστόσο, η σκέψη αυτή αναιρείται από την προηγούμενη σελίδα > των διαφανειών (σελ. 40) όπου τοποθετείται ένα επιπλέον stall ανάμεσα στις 2 τελευταίες > εντολές για να μην συμπέσουν τα στάδια MEM τους, παρόλο που η μία δεν κάνει τίποτα σε > αυτό το στάδιο. > > 2) Στις διαφάνειες αναφέρετε συχνά σε ένα συγκεκριμένο slide (πχ "Lec5-dynamic-13.pps” > σελ. 3) ότι το loop unrolling βοηθάει στα Data Hazard Stalls, αλλά δεν μπορώ να καταλάβω > > γιατί αυτό συμβαίνει. Μήπως το βελάκι προοριζόταν να δείχνει ότι το loop unrolling βοηθάει > στα Control Stalls; > > 3) Όταν αναφέρετε ότι μας δίνεται “ένας” global history predictor, όπως πχ στο θέμα 3 της > εξέτασης Ιουλίου 2010, εννοείται ότι κάθε εντολή άλματος έχει τις δικιές της εγγραφές > στον PHT με βάση τα τελευταία bits του PC ή ότι όλες έχουν το ίδιο σετ εγγραφών και > όλες χρησιμοποιούν αυτό; > > > Ευχαριστώ εκ των προτέρων, > Ματίκας Γεώργιος > > > _______________________________________________ > Advcomparch mailing list > Advcomparch(a)lists.cslab.ece.ntua.gr > http://lists.cslab.ece.ntua.gr/mailman/listinfo/advcomparch -- Dr. Konstantinos Nikas Computing Systems Laboratory School of Electrical and Computer Engineering National Technical University of Athens Tel: +30-210-7724159 e-mail: knikas(a)cslab.ece.ntua.gr http://www.cslab.ece.ntua.gr/~knikas

2 1

Re: [Advcomparch] Απορίες.
by Konstantinos Nikas 03 Apr '14

03 Apr '14

Καλημέρα, όταν η cache είναι Μ, προφανώς έχεις cache-to-cache. Η υλοποίηση παίζει ρόλο στο ποιος απαντάει όταν ζητηθεί κάτι που το έχει μια άλλη cache S. Εμείς υποθέτουμε ότι σε αυτή την περίπτωση απαντά η cache, αλλά σε κάποια "χαζή" υλοποίηση θα μπορούσε να παρέχει τα δεδόμενα και το επόμενο επίπεδο μνήμης. Στο 2ο ερώτημα δε νομίζω ότι χρειάζεται να απαντήσω :-). K. 2014-04-03 13:08 GMT+03:00 Ανδρέας Παντελόπουλος <padelopoulos(a)gmail.com>: > Καλημέρα στο πρωτόκολλο MESI θα ήθελα να ξεκαθαρίσω κάτι. > > Συγκεκριμένα cache-to-cache μεταφορά δεδομένων πότε ακριβώς έχουμε? Στις > διαφάνειες λέει μόνο ότι στο M state η cache είναι υπεύθυνη για να παρέχει > τα δεδομένα σε όποιον τα ζητήσει, αν και νομίζω ότι έχει ειπωθεί ότι είναι > και θέμα υλοποίησης. > > Επίσης, στο ίδιο πρωτόκολλο με τις write-back caches, η εγγραφή στην μνήμη > ενός block θα γίνει από την cache που ήταν στο state M σε αυτό το block, την > στιγμή που αναγκάζεται να φύγει από αυτό το state? Λόγω μίας άλλης εγγραφής > στο ίδιο block από άλλον επεξεργαστή, ή λόγω ενός read. > > Ευχαριστώ πολύ. > Παντελόπουλος Ανδρέας. > > _______________________________________________ > Advcomparch mailing list > Advcomparch(a)lists.cslab.ece.ntua.gr > http://lists.cslab.ece.ntua.gr/mailman/listinfo/advcomparch > -- Dr. Konstantinos Nikas Computing Systems Laboratory School of Electrical and Computer Engineering National Technical University of Athens Tel: +30-210-7724159 e-mail: knikas(a)cslab.ece.ntua.gr http://www.cslab.ece.ntua.gr/~knikas

2 1

Απορίες.
by Ανδρέας Παντελόπουλος 03 Apr '14

03 Apr '14

Καλημέρα στο πρωτόκολλο MESI θα ήθελα να ξεκαθαρίσω κάτι. Συγκεκριμένα cache-to-cache μεταφορά δεδομένων πότε ακριβώς έχουμε? Στις διαφάνειες λέει μόνο ότι στο M state η cache είναι υπεύθυνη για να παρέχει τα δεδομένα σε όποιον τα ζητήσει, αν και νομίζω ότι έχει ειπωθεί ότι είναι και θέμα υλοποίησης. Επίσης, στο ίδιο πρωτόκολλο με τις write-back caches, η εγγραφή στην μνήμη ενός block θα γίνει από την cache που ήταν στο state M σε αυτό το block, την στιγμή που αναγκάζεται να φύγει από αυτό το state? Λόγω μίας άλλης εγγραφής στο ίδιο block από άλλον επεξεργαστή, ή λόγω ενός read. Ευχαριστώ πολύ. Παντελόπουλος Ανδρέας.

1 0

Απορίες
by George Matikas 02 Apr '14

02 Apr '14

Γεια σας! Καθώς προετοιμάζομαι για την ερχόμενη εξέταση της Παρασκευής μου γεννήθηκαν κάποιες απορίες. Θα μπορούσατε να με βοηθήσετε να τις λύσω; 1) Στις διαφάνειες "Lec1-overview-13" στη σελίδα 41, αναφέρει ότι υπάρχει το ενδεχόμενο να εμφανιστεί structural hazard λόγω ταυτόχρονης εγγραφής του register file στο στάδιο WB. Ωστόσο, πιστεύω ότι αυτό δεν είναι εφικτό, αφού πάντα πριν το στάδιο WB βρίσκεται στο pipeline του παραδείγματος το στάδιο MEM. Άρα θα έχουμε εκεί structural hazard και επομένως stall και δεν θα συμπέσουν ποτέ 2 WB στάδια. Μία σκέψη που μου πέρασε από το μυαλλό είναι ότι δεν μας πειράζει που θα πέσουν δύο ή περισσότερα στάδια MEM μαζί από τη στιγμή που οι εντολές αυτές δεν κάνουν τίποτα στα στάδια αυτά (δηλαδή δεν διαβάζουν ή γράφουν τη μνήμη), οπότε και γι’ αυτό επιτρέπουμε να πέσουν μαζί και δεν έχουμε stall όπως ανέφερα παραπάνω. Ωστόσο, η σκέψη αυτή αναιρείται από την προηγούμενη σελίδα των διαφανειών (σελ. 40) όπου τοποθετείται ένα επιπλέον stall ανάμεσα στις 2 τελευταίες εντολές για να μην συμπέσουν τα στάδια MEM τους, παρόλο που η μία δεν κάνει τίποτα σε αυτό το στάδιο. 2) Στις διαφάνειες αναφέρετε συχνά σε ένα συγκεκριμένο slide (πχ "Lec5-dynamic-13.pps” σελ. 3) ότι το loop unrolling βοηθάει στα Data Hazard Stalls, αλλά δεν μπορώ να καταλάβω γιατί αυτό συμβαίνει. Μήπως το βελάκι προοριζόταν να δείχνει ότι το loop unrolling βοηθάει στα Control Stalls; 3) Όταν αναφέρετε ότι μας δίνεται “ένας” global history predictor, όπως πχ στο θέμα 3 της εξέτασης Ιουλίου 2010, εννοείται ότι κάθε εντολή άλματος έχει τις δικιές της εγγραφές στον PHT με βάση τα τελευταία bits του PC ή ότι όλες έχουν το ίδιο σετ εγγραφών και όλες χρησιμοποιούν αυτό; Ευχαριστώ εκ των προτέρων, Ματίκας Γεώργιος

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Advcomparch April 2014