Καλημέρα, ας τα πάρουμε με τη σειρά:
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@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@lists.cslab.ece.ntua.gr http://lists.cslab.ece.ntua.gr/mailman/listinfo/advcomparch