Advcomparch July 2014

advcomparch@lists.cslab.ece.ntua.gr

7 participants
11 discussions

Μεγάλο αρχείο κειμένου πρόβλημα στην υποβολή
by Atalanti Mast 27 Jul '14

27 Jul '14

Καλησπέρα σας,Στην εκφώνηση της άσκησης ζητάει το αρχείο που θα υποβάλουμε να είναι της μορφής .odt , .doc ή .pdf (δεν αναφέρεται συμπιεσμένη μορφή). Το πρόβλημα είναι ότι λόγω του μεγέθους της αναφοράς και οι τρεις τύποι αρχείων υπερβαίνουν το αποδεκτό όριο στην υποβολή. Θα μπορούσα να στείλω συμπιεσμένο αρχείο .rar το οποίο θα περιέχει το .pdf?Ευχαριστώ πολύ,Αταλάντη Μαστακούρη

1 0

Υποβολή αναφοράς
by christos markou 27 Jul '14

27 Jul '14

Για κάποιο λόγο, αν και μια μέρα πριν την τελική ημερομηνία παράδοσης της 2ης άσκησης το site δεν επιτρέπει να υποβάλουμε. Πότε να περιμένουμε να ανοίξουν οι υποβολές?

2 1

Re: [Advcomparch] tournament predictor απορία
by Konstantinos Nikas 22 Jul '14

22 Jul '14

Καλησπέρα, > Θα ήθελα να ρωτήσω σε σχέση με την υλοποίηση του tournament predictor τι > εννοείτε στην εκφώνηση ότι πρέπει να έχει 512 entries. Πρέπει δηλαδή με βάση > τα lg(512) = 8 τελευταία bits του PC να θυμάται ποιος predictor έχει > αποδώσει καλύτερα για το branch που βρίσκεται σε αυτό το PC; είναι ένας predictor που περιέχει 512 entries, δηλαδή 512 διαφορετικούς 2-bit counters. > > Επίσης τις παραμέτρους που καθορίζουν αριθμό των entries των predictors > ανάμεσα στους οποίους επιλέγει πρέπει να τον υπολογίσουμε ώστε το hardware > που θα απαιτείτο για την υλοποίηση του να έχει ένα σταθερό κόστος; (και αν > ναι ποιο είναι αυτό;) Η εκφώνηση είναι σαφής: "Οι P0, P1 έχουν overhead 16Κ ο καθένας". Κ. -- 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

tournament predictor απορία
by Giwrgos Paraskevopoulos 21 Jul '14

21 Jul '14

Καλησπέρα, Θα ήθελα να ρωτήσω σε σχέση με την υλοποίηση του tournament predictor τι εννοείτε στην εκφώνηση ότι πρέπει να έχει 512 entries. Πρέπει δηλαδή με βάση τα lg(512) = 8 τελευταία bits του PC να θυμάται ποιος predictor έχει αποδώσει καλύτερα για το branch που βρίσκεται σε αυτό το PC; Επίσης τις παραμέτρους που καθορίζουν αριθμό των entries των predictors ανάμεσα στους οποίους επιλέγει πρέπει να τον υπολογίσουμε ώστε το hardware που θα απαιτείτο για την υλοποίηση του να έχει ένα σταθερό κόστος; (και αν ναι ποιο είναι αυτό;) Ευχαριστώ, Γιώργος Παρασκευόπουλος

1 0

Re: [Advcomparch] Διαφορετικά cfg file
by Konstantinos Nikas 21 Jul '14

21 Jul '14

Καλησπέρα, πουθενά δεν αναφέρουμε στην εκφώνηση ότι υπάρχει config αρχείο entries. Τα config αρχεία που αναφέρουμε είναι το base.cfg και το advcomp.cfg που είχατε χρησιμοποιήσει στην πρώτη άσκηση. Από εκεί και πέρα το make δεν έχει τίποτα να κάνει με το config αρχείο. Make κάνετε όταν πειράζετε τον κώδικα (π.χ. γράφετε έναν καινούριο predictor). Το config αρχείο το δίνετε σαν όρισμα κατά την εκτέλεση του sniper και ότι έχετε ορίσει μέσα σε αυτό το χρησιμοποιεί ο sniper στην προσομοίωση. Κ. 2014-07-19 13:04 GMT+03:00 Εμμανουήλ Βλατάκης <tetraktida42(a)gmail.com>: > Καλησπέρα, > > Η ερώτηση μου αφορά το δεύτερο σκέλος της άσκησης την 5.1 > Λοιπόν στην εκφώνηση της άσκηση αναφέρετε δύο σημεία που μπορούμε να > τσεκάρουμε τα configuration, στο base.cfg και στο entries > > To πρώτο το βρήκα, το δεύτερο δεν το βρήκα (εκτός αν με entries εννοείτε το > αρχείο cfg που δίνουμε εμείς) > > Εμείς πρέπει να κάνουμε αλλάγες και στα δύο αρχεία και πρέπει να κάνουμε > ξανά make τον sniper? > Ρωτάω για να μην αρχίσω τον sniper με λάθος configurations > _________________________________________________________ > Συγκεκριμένα: > > Για παράδειγμα στο base.cfg αρχείο > ειχε : > [perf_model/branch_predictor] > type=one_bit > mispredict_penalty=14 # A guess based on Penryn pipeline depth > size=1024 > > > Στο myconfig.cfg που δίνω σαν όρισμα έχει > > [perf_model/branch_predictor] > type = pentium_m > mispredict_penalty=17 # From microarchitecture.pdf (Nehalem has a longer > pipeline than Core2) > _________________________________________________________ > Ερωτήσεις: >>Από αυτά τα δύο πιο θα επικρατήσει στο τέλος το δικό μου ή το base.cfg? >>Αν αλλάξω απλά το δικό μου αρκεί? >>Πρέπει να αλλάξω και τα δύο και αν ναι, πρέπει να ξαναγίνει make ο >> sniper(μήπως χρησιμοποιεί το base.cfg κατά το compile)? > > Ευχαριστώ πολύ > > > _______________________________________________ > 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

Διαφορετικά cfg file
by Εμμανουήλ Βλατάκης 19 Jul '14

19 Jul '14

Καλησπέρα, Η ερώτηση μου αφορά το δεύτερο σκέλος της άσκησης την 5.1 Λοιπόν στην εκφώνηση της άσκηση αναφέρετε δύο σημεία που μπορούμε να τσεκάρουμε τα configuration, στο base.cfg και στο entries To πρώτο το βρήκα, το δεύτερο δεν το βρήκα (εκτός αν με entries εννοείτε το αρχείο cfg που δίνουμε εμείς) Εμείς πρέπει να κάνουμε αλλάγες και στα δύο αρχεία και πρέπει να κάνουμε ξανά make τον sniper? Ρωτάω για να μην αρχίσω τον sniper με λάθος configurations _________________________________________________________ Συγκεκριμένα: Για παράδειγμα στο base.cfg αρχείο ειχε : [perf_model/branch_predictor] type=one_bit mispredict_penalty=14 # A guess based on Penryn pipeline depth size=1024 Στο myconfig.cfg που δίνω σαν όρισμα έχει [perf_model/branch_predictor] type = pentium_m mispredict_penalty=17 # From microarchitecture.pdf (Nehalem has a longer pipeline than Core2) _________________________________________________________ Ερωτήσεις: >Από αυτά τα δύο πιο θα επικρατήσει στο τέλος το δικό μου ή το base.cfg? >Αν αλλάξω απλά το δικό μου αρκεί? >Πρέπει να αλλάξω και τα δύο και αν ναι, πρέπει να ξαναγίνει make ο sniper(μήπως χρησιμοποιεί το base.cfg κατά το compile)? Ευχαριστώ πολύ

1 0

Re: [Advcomparch] Υλοποίηση του Local History Predictor
by Konstantinos Nikas 18 Jul '14

18 Jul '14

Καλησπέρα, > Είναι όντως αυτό ένα μειονέκτημα του local history predictor, ή είναι λάθος > η υλοποίηση και θα πρέπει να κρατάμε στη θέση x και το πλήρες pc ώστε να > μηδενίσουμε το περιεχόμενο της x μόλις αυτή κληθεί από διαφορετικό pc; αυτό που περιγράφεις είναι ακριβώς το πρόβλημα του aliasing, το οποίο το αντιμετωπίζουν όλα τα συστήματα που προσπαθούν να χωρέσουν πολλή πληροφορία σε μικρό χώρο, όπως και ο local history predictor. Όσον αφορά την άσκηση, η υλοποίηση σας θα πρέπει να είναι "ρεαλιστική", δηλ. όσο πιο κοντά στην πραγματικότητα γίνεται. > Η παράμετρος target που εμφανίζεται για τον κώδικα που μας δόθηκε στις > predict και update συναρτήσεις είναι ο προορισμός του branch σε περίπτωση > που αυτό είναι taken; Ναι > Για τους predictors που θα συνθέσουμε, αρκεί να φτιάξουμε ένα .h αρχείο, να > το συμπεριλάβουμε ως include στο branch_predictor.cc, να το βάλουμε στο > φάκελο του .cc (αυτόν που αναφέρει και η εκφώνηση) και να κάνουμε ένα > συνολικό make στο sniper; Θα πρέπει εκτός από include, να προσθέσετε και τις κατάλληλες κλήσεις για την αρχικοποίηση τους στο branch_predictor.cc. Νομίζω ότι αν δείτε τι έχουμε κάνει για τον nbit predictor, η διαδικασία είναι σαφής. Κ. -- 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

Ερώτηση για config file
by Ilias Pantazelos 17 Jul '14

17 Jul '14

Στην άσκηση με τα branch predictors τα L1 I/D cache,L2 cache και οι επιλογές κάτω από το interval_timer πρέπει να είναι οι default που είχαμε πριν κάνουμε τις όποιες αλλαγές χρειάστηκαν για τις ασκήσεις σωστά; Σε αυτή τη περίπτωση μπορείτε να μου πείτε τα settings για το interval_timer γιατί τα άλλαξα και δε θυμάμαι τα αρχικά.Για τις caches τα αναφέρει στη πρώτη άσκηση οπότε είμαι οκ.

1 0

Υλοποίηση του Local History Predictor
by Christos Michas 16 Jul '14

16 Jul '14

Καλησπέρα, Θα ήθελα να ρωτήσω πώς πρέπει να χειρίζεται τις περιπτώσεις aliasing o local history predictor. Έστω ότι στη θέση x του BHT αντιστοιχούν τα branch με διευθύνσεις pc1 και pc2. Αρχικά μόνο η pc1 κάνει branch, οπότε η θέση x γεμίζει με το ιστορικό της, και στη συνέχεια ο predictor καλείται να χειριστεί το branch με pc2. Όταν θα πρέπει να καταγράψουμε το πραγματικό αποτέλεσμα του branch, κατάλαβα ότι θα μετατοπίσουμε απλώς το ιστορικό στη θέση x για να καταγράψουμε το αποτέλεσμα. Μία τέτοια υλοποίηση όμως θα σήμαινε ότι το ιστορικό του pc1 θα συνεχίσει να επηρεάζει τις αποφάσεις για το pc2 μέχρι να γίνουν κάμποσες προβλέψεις και να καθαρίσει πλήρως το ιστορικό από τις καταχωρήσεις του pc1. Είναι όντως αυτό ένα μειονέκτημα του local history predictor, ή είναι λάθος η υλοποίηση και θα πρέπει να κρατάμε στη θέση x και το πλήρες pc ώστε να μηδενίσουμε το περιεχόμενο της x μόλις αυτή κληθεί από διαφορετικό pc; Και δύο πιο ειδικές, διευκρινιστικές ερωτήσεις: Η παράμετρος target που εμφανίζεται για τον κώδικα που μας δόθηκε στις predict και update συναρτήσεις είναι ο προορισμός του branch σε περίπτωση που αυτό είναι taken; Για τους predictors που θα συνθέσουμε, αρκεί να φτιάξουμε ένα .h αρχείο, να το συμπεριλάβουμε ως include στο branch_predictor.cc, να το βάλουμε στο φάκελο του .cc (αυτόν που αναφέρει και η εκφώνηση) και να κάνουμε ένα συνολικό make στο sniper; Ευχαριστώ πολύ, Μίχας Χρήστος

1 0

Ομιλία Α. Μόσχοβου Παρσκευή 18/07, 14:00
by Konstantinos Nikas 15 Jul '14

15 Jul '14

Καλημέρα, [Ζητώ συγγνώμη αν λάβετε το μήνυμα παραπάνω από μία φορά] Θα θέλαμε να σας προσκαλέσουμε με μεγάλη χαρά στην ομιλία του Prof. Α. Μόσχοβου που θα πραγματοποιηθεί την Παρασκευή 18/07 στις 14:00 με τίτλο "The selfish Transaction and How to Better Exploit Instruction Caches". Ώρα : Παρασκευή 18/07 @ 14:00 Μέρος: Αμφ. Πολυμέσων, Κεντρική Βιβλιοθήκη, ΕΜΠ. Ακολουθεί περίληψη της ομιλίας καθώς και ένα σύντομο βιογραφικό του ομιλητή: ********************** Abstract: Data management systems have evolved into an essential component of numerous applications. Often, they are used to perform "transactional" workloads comprising transactional, that is, requests that lookup or update information based on some selection criteria, e.g., looking up an account's balance or purchasing an item. For such systems, the higher the throughput, that is he number of transactions that are serviced per unit of time, the better and often the more efficient the system. In this presentation we will observe how transactions execute on modern hardware and see that transactions operate selfishly. This behavior ends up penalizing all as it thrashes the instruction caches, a key performance enhancing mechanism. We will then identify two cooperative policies that boost throughput. The policies judiciously decide where, when, and for how long transactions should execute. While targeting transactional workloads the techniques presented could potential benefit any workload that has a large instruction footprint and many threads running over mostly identical pieces of code. ********************** Short Bio: Andreas Moshovos teaches computer design at the Electrical and Computer Engineering Department of the University of Toronto. He has also taught at Northwestern University, the University of Athens, and the Hellenic Open University. He received the ACM SIGARCH Maurice Wilkes Award in 2010. ********************** Χαιρετισμούς, Κωστής -- 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Advcomparch July 2014