Καλησπέρα,
Θα ήθελα να μου λύσετε μια απορία σχετικά με την εκφώνηση της 4ης άσκησης. Λέει στο Α.2.3 :
*Καθώς οι caches έχουν μηδενικούς χρόνους πρόσβασης, ο αριθμός των κύκλων που δίνει ο simics* *για την εκτέλεση μιας περιοχής ενδιαφέροντος δεν είναι σωστός. Για αυτό τον λόγο απαιτείται ένα* *μοντέλο απόδοσης το οποίο θα προσεγγίζει με μεγαλύτερη ακρίβεια τον πραγματικό αριθμό* *απαιτούμενων κύκλων. * *Το μοντέλο του simics για τις x86 αρχιτεκτονικές είναι ένας in-order επεξεργαστής με IPC=1. Εμείς* *θεωρούμε ότι οι εντολές πρόσβασης στις caches πρώτου επιπέδου δεν προκαλούν καθυστέρηση* *εφόσον είναι hits. Κάθε miss στις L1 στοιχίζει 10 κύκλους και κάθε miss στην L2 200 κύκλους* *αντίστοιχα. Επομένως, ο συνολικός αριθμός των κύκλων μπορεί να προσεγγιστεί ως εξής :* *Cycles = Instructions + (L1D_misses+L1I_misses) * L1_penalty + L2_misses * L2_penalty* *Για τον υπολογισμό των συνολικών εντολών που εκτελέστηκαν χρησιμοποιήστε το μέγεθος* *"Instruction fetch transactions" από τα στατιστικά της instruction cache.* * * Από τα παραπάνω εξάγω το συμπέρασμα ότι δεν θα χρησιμοποιήσουμε την ptime, όπως στην άσκηση1, για να μετρήσουμε τους κύκλους, αλλά θα τους υπολογίσουμε με βάση τα υπόλοιπα (έγκυρα) στατιστικά, με χρήση του τύπου που μας δίνει η εκφώνηση. Πιο πριν όμως, διαβάζω
*5. Στο πρώτο σημείο διακοπής της εκτέλεσης, φορτώνετε την ιεραρχία της μνήμης, η οποία* *δίνεται στο Παράρτημα B και συνεχίζετε την εκτέλεση (αφού λάβετε τα αναγκαία στατιστικά).* *a. simics> run-command-file cache-hierarcy.simics* *b. simics> c* *6. Το δεύτερο σημείο διακοπής της εκτέλεσης σηματοδοτεί το τέλος της προσομοίωσης.* *Επομένως συγκεντρώνετε τα στατιστικά που σας ενδιαφέρουν και προχωράτε στην επόμενη* *περίπτωση.* * * Και αναρωτιέμαι τι νόημα έχει η συλλογή στατιστικών, σε σημείο όπου δεν έχει ξεκινήσει η εκτέλεση του τμήματος κώδικα που μας ενδιαφέρει, και που είναι κοινό για όλες τις αναδιατάξεις που δοκιμάζουμε. Υπάρχει κάποιο χρήσιμο στατιστικό στοιχείο που πρέπει να συλλέξουμε εκεί; κι αν ναι, που θα το χρησιμοποιήσουμε;
Και κάτι τελευταίο: η απόδοση μιας αναδιάταξης κρίνεται μόνο με βάση την παράμετρο Cycles? αν δηλαδή μια αναδιάταξη δίνει λιγότερους κύκλους, αλλά έχει καλύτερα miss rates από μια άλλη, θα την θεωρήσουμε "καλύτερη";
Ευχαριστώ για το χρόνο σας,
Δοκιμάκης Βύρωνας
Μια διόρθωση: στο τελευταίο ερώτημα ήθελα να γράψω "η απόδοση μιας αναδιάταξης κρίνεται μόνο με βάση την παράμετρο Cycles? αν δηλαδή μια αναδιάταξη δίνει λιγότερους κύκλους, αλλά έχει *μεγαλύτερα* miss rates από μια άλλη, θα την θεωρήσουμε "καλύτερη";"
Στις 14 Ιουλίου 2011 11:01 μ.μ., ο χρήστης ΒΥΡΩΝΑΣ ΔΟΚΙΜΑΚΗΣ < b.dokimakis@gmail.com> έγραψε:
Καλησπέρα,
Θα ήθελα να μου λύσετε μια απορία σχετικά με την εκφώνηση της 4ης άσκησης. Λέει στο Α.2.3 :
*Καθώς οι caches έχουν μηδενικούς χρόνους πρόσβασης, ο αριθμός των κύκλων που δίνει ο simics* *για την εκτέλεση μιας περιοχής ενδιαφέροντος δεν είναι σωστός. Για αυτό τον λόγο απαιτείται ένα* *μοντέλο απόδοσης το οποίο θα προσεγγίζει με μεγαλύτερη ακρίβεια τον πραγματικό αριθμό* *απαιτούμενων κύκλων. * *Το μοντέλο του simics για τις x86 αρχιτεκτονικές είναι ένας in-order επεξεργαστής με IPC=1. Εμείς* *θεωρούμε ότι οι εντολές πρόσβασης στις caches πρώτου επιπέδου δεν προκαλούν καθυστέρηση* *εφόσον είναι hits. Κάθε miss στις L1 στοιχίζει 10 κύκλους και κάθε miss στην L2 200 κύκλους* *αντίστοιχα. Επομένως, ο συνολικός αριθμός των κύκλων μπορεί να προσεγγιστεί ως εξής :* *Cycles = Instructions + (L1D_misses+L1I_misses) * L1_penalty + L2_misses
- L2_penalty*
*Για τον υπολογισμό των συνολικών εντολών που εκτελέστηκαν χρησιμοποιήστε το μέγεθος* *"Instruction fetch transactions" από τα στατιστικά της instruction cache.
Από τα παραπάνω εξάγω το συμπέρασμα ότι δεν θα χρησιμοποιήσουμε την ptime, όπως στην άσκηση1, για να μετρήσουμε τους κύκλους, αλλά θα τους υπολογίσουμε με βάση τα υπόλοιπα (έγκυρα) στατιστικά, με χρήση του τύπου που μας δίνει η εκφώνηση. Πιο πριν όμως, διαβάζω
*5. Στο πρώτο σημείο διακοπής της εκτέλεσης, φορτώνετε την ιεραρχία της μνήμης, η οποία* *δίνεται στο Παράρτημα B και συνεχίζετε την εκτέλεση (αφού λάβετε τα αναγκαία στατιστικά).* *a. simics> run-command-file cache-hierarcy.simics* *b. simics> c* *6. Το δεύτερο σημείο διακοπής της εκτέλεσης σηματοδοτεί το τέλος της προσομοίωσης.* *Επομένως συγκεντρώνετε τα στατιστικά που σας ενδιαφέρουν και προχωράτε στην επόμενη* *περίπτωση.*
Και αναρωτιέμαι τι νόημα έχει η συλλογή στατιστικών, σε σημείο όπου δεν έχει ξεκινήσει η εκτέλεση του τμήματος κώδικα που μας ενδιαφέρει, και που είναι κοινό για όλες τις αναδιατάξεις που δοκιμάζουμε. Υπάρχει κάποιο χρήσιμο στατιστικό στοιχείο που πρέπει να συλλέξουμε εκεί; κι αν ναι, που θα το χρησιμοποιήσουμε;
Και κάτι τελευταίο: η απόδοση μιας αναδιάταξης κρίνεται μόνο με βάση την παράμετρο Cycles? αν δηλαδή μια αναδιάταξη δίνει λιγότερους κύκλους, αλλά έχει καλύτερα miss rates από μια άλλη, θα την θεωρήσουμε "καλύτερη";
Ευχαριστώ για το χρόνο σας,
Δοκιμάκης Βύρωνας
On 07/14/2011 11:01 PM, ΒΥΡΩΝΑΣ ΔΟΚΙΜΑΚΗΣ wrote:
Καλησπέρα,
Θα ήθελα να μου λύσετε μια απορία σχετικά με την εκφώνηση της 4ης άσκησης. Λέει στο Α.2.3 :
/Καθώς οι caches έχουν μηδενικούς χρόνους πρόσβασης, ο αριθμός των κύκλων που δίνει ο simics/ /για την εκτέλεση μιας περιοχής ενδιαφέροντος δεν είναι σωστός. Για αυτό τον λόγο απαιτείται ένα/ /μοντέλο απόδοσης το οποίο θα προσεγγίζει με μεγαλύτερη ακρίβεια τον πραγματικό αριθμό/ /απαιτούμενων κύκλων. / /Το μοντέλο του simics για τις x86 αρχιτεκτονικές είναι ένας in-order επεξεργαστής με IPC=1. Εμείς/ /θεωρούμε ότι οι εντολές πρόσβασης στις caches πρώτου επιπέδου δεν προκαλούν καθυστέρηση/ /εφόσον είναι hits. Κάθε miss στις L1 στοιχίζει 10 κύκλους και κάθε miss στην L2 200 κύκλους/ /αντίστοιχα. Επομένως, ο συνολικός αριθμός των κύκλων μπορεί να προσεγγιστεί ως εξής :/ /Cycles = Instructions + (L1D_misses+L1I_misses) * L1_penalty + L2_misses * L2_penalty/ /Για τον υπολογισμό των συνολικών εντολών που εκτελέστηκαν χρησιμοποιήστε το μέγεθος/ /"Instruction fetch transactions" από τα στατιστικά της instruction cache./ / / Από τα παραπάνω εξάγω το συμπέρασμα ότι δεν θα χρησιμοποιήσουμε την ptime, όπως στην άσκηση1, για να μετρήσουμε τους κύκλους, αλλά θα τους υπολογίσουμε με βάση τα υπόλοιπα (έγκυρα) στατιστικά, με χρήση του τύπου που μας δίνει η εκφώνηση. Πιο πριν όμως, διαβάζω
/5. Στο πρώτο σημείο διακοπής της εκτέλεσης, φορτώνετε την ιεραρχία της μνήμης, η οποία/ /δίνεται στο Παράρτημα B και συνεχίζετε την εκτέλεση (αφού λάβετε τα αναγκαία στατιστικά)./ /a. simics> run-command-file cache-hierarcy.simics/ /b. simics> c/ /6. Το δεύτερο σημείο διακοπής της εκτέλεσης σηματοδοτεί το τέλος της προσομοίωσης./ /Επομένως συγκεντρώνετε τα στατιστικά που σας ενδιαφέρουν και προχωράτε στην επόμενη/ /περίπτωση./ / / Και αναρωτιέμαι τι νόημα έχει η συλλογή στατιστικών, σε σημείο όπου δεν έχει ξεκινήσει η εκτέλεση του τμήματος κώδικα που μας ενδιαφέρει, και που είναι κοινό για όλες τις αναδιατάξεις που δοκιμάζουμε.
Υπάρχει
κάποιο χρήσιμο στατιστικό στοιχείο που πρέπει να συλλέξουμε εκεί;
Στην προκειμένη περίπτωση όχι, αφού στο σημείο που προκύπτει το 1ο breakpoint φορτώνεται και η ιεραρχία της μνήμης που αρχικά είναι κενή. Αν όμως κάποιος επιλέξει να κάνει π.χ. cache warmup με εγκατεστημένη την ιεραρχία μνήμης, τότε θα πρέπει να πάρει τα diffs των απαραίτητων στατιστικών ανάμεσα στα 2 breakpoints.
Και κάτι τελευταίο: η απόδοση μιας αναδιάταξης κρίνεται μόνο με βάση την παράμετρο Cycles? αν δηλαδή μια αναδιάταξη δίνει λιγότερους κύκλους, αλλά έχει καλύτερα miss rates από μια άλλη, θα την θεωρήσουμε "καλύτερη";
Αυτή η απορία έχει συζητηθεί στη λίστα τις προηγούμενες μέρες, δες εδώ: http://lists.cslab.ece.ntua.gr/pipermail/advcomparch/2011-July/000690.html
Ν.
advcomparch@lists.cslab.ece.ntua.gr
-
Nikos Anastopoulos -
ΒΥΡΩΝΑΣ ΔΟΚΙΜΑΚΗΣ