[Advcomparch] historySize στο ερώτημα Δ.
Konstantinos Nikas
knikas at cslab.ece.ntua.gr
Sun May 18 19:16:31 EEST 2008
Καλησπέρα,
> Στο ερώτημα Δ της δεύτερης άσκησης θα πρέπει να προσομοιώσουμε έναν Local-History two-level predictor.Οπότε έχω κάποιες απορίες για το πώς μπορούμε να υπολογίζουμε το historySize.
>
> α) Το συνολικό μέγεθος που είναι 16K αναφέρεται στο συνολικό αριθμό απο bits που περιέχουν οι πίνακες BHT, PHT ή είναι ένα μέγεθος εγγραφών ;
>
16Κ είναι ο συνολικός αριθμός bits για τους πίνακες BHT και PHT.
> β) Απο ότι έχω καταλάβει στον χρειαζόμαστε log2(N) bits απο τον PC όπου Ν το μέγεθος του BHT για τον προσπελάσουμε.
> Ο BHT περιέχει το history, κάποια bits δηλαδή των οποίων το πλήθος είναι το ζητούμενο(historySize). Οπότε με βάση το νουμερο του index του BHT και το περιεχόμενο αυτής της θέσης θα πρέπει να δημιουργήσουμε ένα νέο index για να προσπελάσουμε τον PHT. Τώρα όμως ο PHT είναι fixed στα 1024 οπότε θέλουμε log2(1024) = 10bits για να τον προσπελάσουμε..και εδώ αρχίζει το μπέρδεμα.
>
> Το bits για κάποιο index του BHT σύμφωνα με την άσκηση είναι log2(1024) = 10 ή log2(2048) = 11 bits αντίστοιχα. Πώς λοιπόν απο αυτά τα 10 ή 11 bits θα προσθέσουμε και κάτι άλλο που είναι το μέγεθος του history register που θα μας δώσει αποτέλεσμα 10 για να προσπελάσουμε τον PHT ;
>
> Ενναλακτικά στο παραπάνω μήπως εννοούμε οτι 16K μέγεθος hardware σημαίνει 8 set απο PHT tables με 1024*2 = 2048 ο καθένας οπότε 2048*8 = 16K bits άρα θέλουμε log2(8) = 3 bits + 10 bits = 13 bits για να προσπελάσουμε τον PHT οπότε το history size θα είναι στην μια περίπτωση που το l1 εχει 10bit index θα είναι 3 bit και στην άλλη περίπτωση που έχουμε 11bit index θα είναι 2 για να έχουμε πάντα άθροισμα 13 ;
>
Έχεις δίκιο για το μπέρδεμα αυτό. Η ίδια απορία τέθηκε και στο μάθημα
την προηγούμενη βδομάδα. Όπως είπα και εκεί πρόκειται για ένα λάθος δικό
μας (το οποίο μεταφέρθηκε και στην εκφώνηση της άσκησης χωρίς να το
καταλάβουμε μέχρι πρόσφατα).
Όπως σωστά παρατηρείς σε μία περίπτωση τα bits ενός entry του ΒΗΤ
υπολογίζονται *> 10* , ενώ θεωρητικά (σύμφωνα με τις διαφάνειες) θα
έπρεπε τα bits του ΒΗΤ και κάποια από το PC να είναι *ακριβώς 10*. Δεν
υπάρχει πρόβλημα όμως, καθώς ο SESC κατασκευάζει έτσι τα components ώστε
τελικά να παίρνει τα 10 bits που χρειάζεται για να προσπελάσει τον PHT.
Τώρα, για το πόσο σωστό και efficient είναι αυτό το σύστημα, έχει να
κάνει με τον τρόπο που το προσομοιώνει ο SESC (και άρα τον τρόπο που
σχεδιάζεται).
Aν ας πούμε απλά πάει και παίρνει τα 10 LSB του ΒΤΗ, τότε όπως
καταλαβαίνεις δεν χρησιμοποιείται όλη η διαθέσιμη πληροφορία, με
αποτέλεσμα ένα ποσοστό του hardware να έχει σπαταληθεί σε κάτι που δεν
χρησιμοποιείται, αντί να χρησιμοποιηθεί κάπου άλλου που θα βοηθούσε το
performance. Από την άλλη, θα μπορούσε ας πούμε, το index του PHT να
υπολογιζόταν από ένα συνδυασμό διαφόρων ΧΟR και άλλων hash functions
μεταξύ όλων των bits του entry του BTH και του PC.
Σε κάθε περίπτωση, όσον αφορά την άσκηση απλά χρησιμοποίησε τα νούμερα
που βρήκες για να κάνεις τις απαιτούμενες προσομοιώσεις. Το ότι βρήκες
το λάθος σημαίνει ότι έχεις καταλάβει τον τρόπο οργάνωσης και σχεδιασμού
του συγκεκριμένου predictor.
Κωστής
PS: Θα σε παρακαλούσα για μελλοντικές απορίες να γραφτείς στην λίστα του
μαθήματος ώστε να μπορούν και οι υπόλοιποι συμφοιτητές σου να βλέπουν
τις απορίες και τις απαντήσεις. Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cslab.ece.ntua.gr/pipermail/advcomparch/attachments/20080518/ac6d4645/attachment.htm>
More information about the Advcomparch
mailing list