Advcomparch May 2013

advcomparch@lists.cslab.ece.ntua.gr

26 participants
55 discussions

Re: [Advcomparch] IPC για benchmark dedup
by Konstantinos Nikas 25 May '13

25 May '13

Καλησπέρα, έχει ξαναγίνει μια πρώτη κουβέντα για το dedup http://lists.cslab.ece.ntua.gr/pipermail/advcomparch/2013-May/000942.html Σε σχέση με τότε αυτό που έχουμε διαπιστώσει είναι ότι για κάποιο λόγο όσο αυξάνεται το window_size (διατηρώντας σταθερό το dispatch_width) φαίνεται να αυξάνονται οι κύκλοι που εκτελούνται ifetch, χωρίς όμως να αλλάζουν τα instruction cache miss rates. Γενικά είναι λίγο περίεργη η συμπεριφορά και το ψάχνουμε και εμείς. Έχουμε επικοινωνήσει και με την ομάδα του snipersim αλλά δεν έχουμε καταλήξει σε κάποιο συμπέρασμα ακόμα. Και αυτοί όμως αποσυνέδεσαν τη συμπεριφορά αυτή από το συνολικό χρόνο έκτελεσης. Το ότι κάνει παραπάνω μέχρι να φτάσει στο ROI από τα υπόλοιπα benchmarks θεωρείται χαρακτηριστικό της εφαρμογής και για αυτό "φυσιολογικό". Κ. 2013/5/24 Dimitris Tsipras <dtsip(a)hotmail.com> > Καλησπέρα, > > κάνοντας τις γραφικές παραστάσεις για τα διάφορα benchmarks, παρατηρώ ότι > η συπεριφορά του dedup (ως προς το IPC) στις μεταβολές των παραμέτρων, > είναι εντελώς αντίθετη με αυτή των υπόλοιπων benchmarks. Η συμπεριφορά αυτή > είναι μη αναμενόμενη, και η μεταβολές φαίνονται ακανόνιστες. Δεδομένου ότι > το benchmark είχε σημαντικά μεγαλύτερο χρόνο εκτέλεσης από τα υπόλοιπα, > γνωρίζουμε τι πρόβλημα μπορεί να υπάρχει με το συγκεκριμένο benchmark; > > _______________________________________________ > 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 Spyridon Mastorakis 25 May '13

25 May '13

ÊáôÜëáâá. Óáò åõ÷áñéóôþ ðïëý ãéá ôçí áðÜíôçóç. Óôéò 25 Ìáú 2013, 12:30 ì.ì., ï/ç Konstantinos Nikas <knikas(a)cslab.ece.ntua.gr> Ýãñáøå: ÊáëçìÝñá, ãéáôß íá êÜíåéò flush ôéò caches; Œôáí Ý÷åéò Ýíá branch misprediction ðñÝðåé íá êÜíåéò ôá åîÞò: 1. Íá ãõñßóåéò óôï óùóôü architectural state. Áí ÷ñçóéìïðïéåßò ROB üðùò åßäáìå êáé óôï ìÜèçìá äå ÷ñåéÜæåôáé íá êÜíåéò áðïëýôùò ôßðïôá, ìéáò êáé ôï in order commit óïõ åããõÜôáé ôï state óïõ åßíáé ïê. 2. Íá óôáìáôÞóåéò íá åêôåëåßò á÷ñåßáóôåò åíôïëÝò. Ãéá áõôü ôï ëüãï êáé êÜíåéò flush ôï pipeline, ðñïêåéìÝíïõ íá áðåëåõèåñùèïýí ôá äéÜöïñá components êáé íá ÷ñçóéìïðïéçèïýí áðü ôéò óùóôÝò åíôïëÝò ÷ùñßò êáèõóôÝñçóç. Ôéò caches ãéáôß üìùò íá ôéò êÜíåéò flush? ÊáôÜ ôçí åêôÝëåóç ôïõ mispredicted path, Ý÷åéò öÝñåé óôçí ÷åéñüôåñç ðåñßðôùóç êÜðïéá "á÷ñåßáóôá" loads, ôá ïðïßá óßãïõñá åßíáé ðïëý ëéãüôåñá áðü ôïí óõíïëéêü áñéèìü ôùí blocks ðïõ èá ÷Üóåéò êÜíïíôáò flush. Ê. 2013/5/23 Spyridon Mastorakis <el09195(a)mail.ntua.gr> ÊáëçóðÝñá óáò. ž÷ù ìéá åñþôçóç ðïõ áöïñÜ ôçí ðåñßðôùóç ðïõ êÜíïõìå ëÜèïò óôï branch prediction, ïðüôå êáé ÷ñåéÜæåôáé íá êÜíïõìå flush ôï pipeline. Óôçí ðåñßðôùóç áõôÞ , åêôüò áðü ôï pipeline , èá êÜíïõìå flush êáé ôéò caches. ÓùóôÜ? ÕðÜñ÷åé, êÜðïéï Üëëï unit ðïõ èá ðñÝðåé íá ãßíåé flush óôçí ðåñßðôùóç áõôÞ? Óáò åõ÷áñéóôþ ðïëý åê' ôùí ðñïôÝñùí ãéá ôçí áðÜíôçóç. Óðýñïò ÌáóôïñÜêçò. _______________________________________________ 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 25 May '13

25 May '13

Καλημέρα, γιατί να κάνεις flush τις caches; Όταν έχεις ένα branch misprediction πρέπει να κάνεις τα εξής: 1. Να γυρίσεις στο σωστό architectural state. Αν χρησιμοποιείς ROB όπως είδαμε και στο μάθημα δε χρειάζεται να κάνεις απολύτως τίποτα, μιας και το in order commit σου εγγυάται το state σου είναι οκ. 2. Να σταματήσεις να εκτελείς αχρείαστες εντολές. Για αυτό το λόγο και κάνεις flush το pipeline, προκειμένου να απελευθερωθούν τα διάφορα components και να χρησιμοποιηθούν από τις σωστές εντολές χωρίς καθυστέρηση. Τις caches γιατί όμως να τις κάνεις flush? Κατά την εκτέλεση του mispredicted path, έχεις φέρει στην χειρότερη περίπτωση κάποια "αχρείαστα" loads, τα οποία σίγουρα είναι πολύ λιγότερα από τον συνολικό αριθμό των blocks που θα χάσεις κάνοντας flush. Κ. 2013/5/23 Spyridon Mastorakis <el09195(a)mail.ntua.gr> > Καλησπέρα σας. > > Έχω μια ερώτηση που αφορά την περίπτωση που κάνουμε λάθος στο branch > prediction, οπότε και > χρειάζεται να κάνουμε flush το pipeline. > > Στην περίπτωση αυτή , εκτός από το pipeline , θα κάνουμε flush και τις > caches. Σωστά? > Υπάρχει, κάποιο άλλο unit που θα πρέπει να γίνει flush στην περίπτωση αυτή? > > Σας ευχαριστώ πολύ εκ' των προτέρων για την απάντηση. > Σπύρος Μαστοράκης. > > _______________________________________________ > 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

IPC για benchmark dedup
by Dimitris Tsipras 24 May '13

24 May '13

Καλησπέρα, κάνοντας τις γραφικές παραστάσεις για τα διάφορα benchmarks, παρατηρώ ότι η συπεριφορά του dedup (ως προς το IPC) στις μεταβολές των παραμέτρων, είναι εντελώς αντίθετη με αυτή των υπόλοιπων benchmarks. Η συμπεριφορά αυτή είναι μη αναμενόμενη, και η μεταβολές φαίνονται ακανόνιστες. Δεδομένου ότι το benchmark είχε σημαντικά μεγαλύτερο χρόνο εκτέλεσης από τα υπόλοιπα, γνωρίζουμε τι πρόβλημα μπορεί να υπάρχει με το συγκεκριμένο benchmark;

1 0

Απορία για Commit εντολών και Reorder Buffer
by Christos Sakaridis 23 May '13

23 May '13

Καλησπέρα! Θα ήθελα να ρωτήσω κάτι που ίσως είχε διευκρινιστεί στο αντίστοιχο μάθημα αλλά δυστυχώς δεν είχα την ευκαιρία να το παρακολουθήσω. Έστω ότι στον κύκλο k ο ROB είναι πλήρης και η εντολή που αντιστοιχεί στο entry στο οποίο δείχνει ο commit pointer κάνει Write Result, οπότε γίνεται ready για commit. Στον κύκλο k+1, στον οποίο θα γίνει commit η εντολή και θα αδειάσει αυτό το entry, θα μπει ταυτόχρονα σε αυτό η επόμενη προς έκδοση εντολή ή θα γίνει στον κύκλο k+2 το issue και η κατάληψη του άδειου entry από τη νέα εντολή; Ευχαριστώ εκ των προτέρων για τον κόπο σας! Χρήστος Σακαρίδης

1 0

Ερώτηση σχετικά με λάθος στο branch prediction
by Spyridon Mastorakis 23 May '13

23 May '13

ÊáëçóðÝñá óáò. ž÷ù ìéá åñþôçóç ðïõ áöïñÜ ôçí ðåñßðôùóç ðïõ êÜíïõìå ëÜèïò óôï branch prediction, ïðüôå êáé ÷ñåéÜæåôáé íá êÜíïõìå flush ôï pipeline. Óôçí ðåñßðôùóç áõôÞ , åêôüò áðü ôï pipeline , èá êÜíïõìå flush êáé ôéò caches. ÓùóôÜ? ÕðÜñ÷åé, êÜðïéï Üëëï unit ðïõ èá ðñÝðåé íá ãßíåé flush óôçí ðåñßðôùóç áõôÞ? Óáò åõ÷áñéóôþ ðïëý åê' ôùí ðñïôÝñùí ãéá ôçí áðÜíôçóç. Óðýñïò ÌáóôïñÜêçò.

1 0

Re: [Advcomparch] disp_width & window_size
by Konstantinos Nikas 22 May '13

22 May '13

Καλησπέρα, γενικά δεν έχει νόημα να ψάχνετε αυτή την πληροφορία στα datasheets της Intel. Αυτό που πρέπει να κάνετε είναι να βρείτε τον τύπο του επεξεργαστή σας και στη συνέχεις να ψάξετε στο google για τα χαρακτηριστικά της αρχιτεκτονικής (π.χ. Sandy Bridge, Nehalem, Westemere κτλ). Θα βρείτε περιγραφές αυτών των αρχιτεκτονικών σε sites όπως τα anandtech, arstechnica, realworldtech. Επίσης δεν είναι υποχρεωτικό να βρείτε τα μεγέθη που ψάχνουμε με αυτούς ακριβώς τους όρους, δηλ. window_size και dispatch width. K. 2013/5/22 Stamatopoulos Stamatis <stamatis.stamatopoulos(a)gmail.com> > Καλημέρα, > > Δεν αναφέρεται σε κανένα datasheet χωρητικότητα window size& dispatch > width. > Πρέπει να τα υπολογίσουμε από κάποιο άλλο μέγεθος? > > Ευχαριστώ, > > Φιλικά, > Σ. > > _______________________________________________ > 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

disp_width & window_size
by Stamatopoulos Stamatis 22 May '13

22 May '13

Καλημέρα, Δεν αναφέρεται σε κανένα datasheet χωρητικότητα window size& dispatch width. Πρέπει να τα υπολογίσουμε από κάποιο άλλο μέγεθος? Ευχαριστώ, Φιλικά, Σ.

1 0

Re: [Advcomparch] Απορία για Tomasulo και άλλες μικρές απορίες
by Konstantinos Nikas 20 May '13

20 May '13

Καλημέρα, ας τα πάρουμε με τη σειρά: 1) Πολύ καλή ερώτηση, ίσως δεν το ξεκαθαρίσαμε σωστά στο μάθημα. Πράγματι τα stores στους πραγματικούς ΟοΟ επεξεργαστές εκτελούνται (αλλάζουν δηλαδή την τιμή στην cache) αφού γίνουν commit. Αν η αλλαγή αυτή γινόταν speculatively (δηλαδή πριν το CMT) τότε σε περίπτωση που θα χρειαζόταν να αναιρεθούν εντολές (αν. πχ. το ST βρίσκεται στο mispredicted path ενός branch) θα έπρεπε να επαναφέρουμε και τις τιμές στις μνήμες. Αντίθετα τα LD εκτελούνται κανονικά πριν το CMT, μιας και αν ακόμα αναιρεθεί η εντολή δεν έχει αλλάξει κάτι στο architectural state του συστήματος (έχει έρθει μεν ένα "αχρείαστο" block στην cache αλλά η μνήμη έχει σωστές τιμές). Εμείς στις ασκήσεις που κάνουμε στο πλαίσιο του μαθήματος (για λόγους απλότητας) θεωρούμε ότι, όπως ακριβώς και στα LDs, στο EX γίνεται ο υπολογισμός της διεύθυνσης και η προσπέλαση στην cache ώστε αν πρόκειται για miss να έρθει το σωστό block από τα επόμενα επίπεδα της ιεραρχίας της μνήμης. Η αλλαγή στην cache θεωρούμε ότι γίνεται στο CMT. Θα μπορούσαμε να θεωρούμε ότι και η αλλαγή της τιμής γίνεται στο EX και υπάρχει κάποιος μηχανισμός που εγγυάται ότι η μνήμη θα έχει τις σωστές τιμές σε περιπτώσεις flush χωρίς να αλλάζει κάτι στην άσκηση. 2) Και εμείς το ψάχνουμε :-). Υπάρχουν αντίστοιχα φαινόμενα και στα άλλα benchmarks αλλά όχι σε τέτοιο βαθμό. Στο dedup αν δείτε τα αναλυτικά στατιστικά (τρέξτε cpistack.py για να σας δώσει το breakdown του cpi) θα δείτε ότι αυξάνονται πολύ οι κύκλοι που μετράει ως "dispatch_width", η καθυστέρηση δηλαδή λόγω περιορισμών του dispatch. Επομένως, θα μπορούσε ίσως αυτή η πτώση που παρατηρούμε να οφείλεται στο πως ο sniper μοντελοποιεί τις καθυστερήσεις. Έχουμε κάνει μια ερώτηση και στο forum και περιμένουμε :-). 3) Το dispatch είναι το πόσες εντολές προωθούνται για εκτέλεση στα reservation stations. Όπως εξηγήσαμε στο μάθημα, για να μπορέσουν οι x86 αρχιτεκτονικές να εκμεταλλευτούν τα προτερήματα των RISC και να μπορέσουν να γίνουν ΟοΟ κτλ. σπάνε τις CISC εντολές σε micro-ops (τα οποία και μετά προωθούνται στα RS και τα FUs). To 6 λοιπόν σημαίνει ότι μπορείς να κάνεις schedule το πολύ 6 μ-οps σε κάθε κύκλο. Το 1.3 που αναφέρεις είναι ο μέσος όρος (δε ξέρω αν είναι το σωστό νούμερο για τα Sandy Bridge αλλά δεν έχει και σημασία). Κάποιες εντολές μπορεί να αντιστοιχούν σε 1 μ-op, κάποιες σε 2 και καποιες σε 3 ή και παραπάνω. Κ. 2013/5/18 Lambros Flokas <lamflokas(a)gmail.com> > Καλημέρα σας, > έχω μια απορία για την εκφώνηση της άσκησης. > Δεν καταλαβαίνω πως οι εντολές store έχουν δικαίωμα να κάνουν προσπέλαση > στη μνήμη στο EX από τη στιγμή που δεν γνωρίζουμε εκεί αν η εκτέλεση τους > είναι υποθετική.Νομίζω ότι το έχω διαβάσει και σε λύση από τα παλιά θέματα > ότι νομιμοποιούμαστε να το κάνουμε αυτό μόνο για load εντολές ενώ για τις > store γίνεται στο CMT. > Το μόνο που μπορώ να φανταστώ είναι ότι το κάνουμε για απλοποίηση ώστε το > CMT να είναι πάντα ένας κύκλος και η πολυπλοκότητα να παραμένει στο ex > όπου έτσι κι αλλιώς δεν έχουν όλες οι εντολές την ίδια διάρκεια. > Μια ακόμη απορία μου είναι αν είναι δυνατόν λόγω του missprediction > επεξεργαστές με μεγαλύτερο ROB να τρώνε περισσότερη ζημιά > επειδή εκκαθαρίζουν περισσότερες εντολές έτσι ώστε τελικά να έχουν > μικρότερο IPC από τον ίδιο επεξεργαστή αλλά με μικρότερο ROB.Γιατί > δυσκολεύομαι να ερμηνεύσω αλλιώς τα αποτελέσματα του dedup(αν έχω κάνει > σωστά τις προσομοιώσεις του βέβαια) > Τέλος διάβασα για τον Sandy Bridge ότι σε κάθε κύκλο αποκωδικοποιεί 4 > εντολές και τις μετατρέπει σε μικρο- εντολές (με την αντιστοιχία 1.3 όπως > νομίζω είπαμε στο μάθημα) αλλά μετά έχει 6 dispatch ports.Διαισθητικά > καταλαβαίνω ότι το dispatch width είναι 6 αλλά λογικά θα ήταν σωστότερο > να παίρναμε το 4*1.3=5.2 δηλαδή 5.Εδώ η διαφορά φαίνεται μικρή αλλά θα > βοηθούσε να καταλάβω το εξής :το dispatch width είναι πόσες εντολές έχουμε > δυνατότητα να κάνουμε decode, πόσες εντολές μπορούμε να προωθήσουμε στα > reservation stations ή το μικρότερο των δυο? > > _______________________________________________ > 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

Απορία για Tomasulo και άλλες μικρές απορίες
by Lambros Flokas 18 May '13

18 May '13

Καλημέρα σας, έχω μια απορία για την εκφώνηση της άσκησης. Δεν καταλαβαίνω πως οι εντολές store έχουν δικαίωμα να κάνουν προσπέλαση στη μνήμη στο EX από τη στιγμή που δεν γνωρίζουμε εκεί αν η εκτέλεση τους είναι υποθετική.Νομίζω ότι το έχω διαβάσει και σε λύση από τα παλιά θέματα ότι νομιμοποιούμαστε να το κάνουμε αυτό μόνο για load εντολές ενώ για τις store γίνεται στο CMT. Το μόνο που μπορώ να φανταστώ είναι ότι το κάνουμε για απλοποίηση ώστε το CMT να είναι πάντα ένας κύκλος και η πολυπλοκότητα να παραμένει στο ex όπου έτσι κι αλλιώς δεν έχουν όλες οι εντολές την ίδια διάρκεια. Μια ακόμη απορία μου είναι αν είναι δυνατόν λόγω του missprediction επεξεργαστές με μεγαλύτερο ROB να τρώνε περισσότερη ζημιά επειδή εκκαθαρίζουν περισσότερες εντολές έτσι ώστε τελικά να έχουν μικρότερο IPC από τον ίδιο επεξεργαστή αλλά με μικρότερο ROB.Γιατί δυσκολεύομαι να ερμηνεύσω αλλιώς τα αποτελέσματα του dedup(αν έχω κάνει σωστά τις προσομοιώσεις του βέβαια) Τέλος διάβασα για τον Sandy Bridge ότι σε κάθε κύκλο αποκωδικοποιεί 4 εντολές και τις μετατρέπει σε μικρο- εντολές (με την αντιστοιχία 1.3 όπως νομίζω είπαμε στο μάθημα) αλλά μετά έχει 6 dispatch ports.Διαισθητικά καταλαβαίνω ότι το dispatch width είναι 6 αλλά λογικά θα ήταν σωστότερο να παίρναμε το 4*1.3=5.2 δηλαδή 5.Εδώ η διαφορά φαίνεται μικρή αλλά θα βοηθούσε να καταλάβω το εξής :το dispatch width είναι πόσες εντολές έχουμε δυνατότητα να κάνουμε decode, πόσες εντολές μπορούμε να προωθήσουμε στα reservation stations ή το μικρότερο των δυο?

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Advcomparch May 2013