Στην εκφώνηση λέτε να χρησιμοποιήσουμε τους ίδιους αριθμούς νημάτων με τις προσομοιώσεις.Παρατηρώ όμως ότι αν δοκιμάσω για περισσότερα νήματα από ότι πυρήνες στο vm μου βγάζει το ακόλουθο μήνυμα Error in pthread_setaffinity_np. Αυτό μου φαίνεται πολύ λογικό αφού η αντιστοίχιση νημάτων και πυρήνων γίνεται όπως λέει και η εκφώνηση 1 προς 1 . Απλά ρωτάω για επιβεβαίωση κυρίως, αν θα τρέξουμε τις προσομοιώσεις μέχρι το πλήθος πυρήνων του vm ή αν κάνω εγώ κάτι λάθος. Σας ευχαριστώ εκ των προτέρων Λάμπρος Φλόκας
Καλησπέρα,
On 06/29/2013 01:03 PM, Lambros Flokas wrote:
Στην εκφώνηση λέτε να χρησιμοποιήσουμε τους ίδιους αριθμούς νημάτων με τις προσομοιώσεις.Παρατηρώ όμως ότι αν δοκιμάσω για περισσότερα νήματα από ότι πυρήνες στο vm μου βγάζει το ακόλουθο μήνυμα Error in pthread_setaffinity_np. Αυτό μου φαίνεται πολύ λογικό αφού η αντιστοίχιση νημάτων και πυρήνων γίνεται όπως λέει και η εκφώνηση 1 προς 1 .
Ναι, είναι λογικό να συμβαίνει αυτό όταν ο αριθμός των threads (Ν) είναι μεγαλύτερος από τον αριθμό των πυρήνων (C), αφού σε αυτήν την περίπτωση η pthread_setaffinity_np θα προσπαθήσει να κάνει bind π.χ. το thread i > C στην cpu i, που ειναι ανύπαρκτη. Συνεπώς θα επιστραφεί σφάλμα.
Για να το αποφύγετε αυτό, προτείνω να κάνετε κάτι από τα εξής: α) Να βάλετε την pthread_setaffinity σε σχόλια. Με αυτόν τον τρόπο δεν ορίζετε εσείς το affinity, αλλά αφήνετε το λειτουργικό να κάνει αυτό το scheduling των threads όπως νομίζει.
β) Να κάνετε bind τα threads στις cpus με κυκλικό τρόπο. Δηλαδή, το thread i στην cpu i mod C (ουσιαστικά αλλάζετε την κληση CPU_SET(ta->my_id, &mask) σε CPU_SET(ta->my_id % C, &mask) -- φυσικά χρειάζεται να δινετε στο προγραμμα σαν επιπλέον παραμετρο τον αριθμό C των cpus).
Λογικά και οι 2 αυτοι τροποι θα πρέπει να δίνουν αντιστοιχα αποτελέσματα.
Ν.
Απλά ρωτάω για επιβεβαίωση κυρίως, αν θα τρέξουμε τις προσομοιώσεις μέχρι το πλήθος πυρήνων του vm ή αν κάνω εγώ κάτι λάθος. Σας ευχαριστώ εκ των προτέρων Λάμπρος Φλόκας
Advcomparch mailing list Advcomparch@lists.cslab.ece.ntua.gr http://lists.cslab.ece.ntua.gr/mailman/listinfo/advcomparch
Αυτό που παρατηρώ τώρα (έχοντας κάνει κάμποσα μπρος πίσω λόγω λαθών στην lock) είναι ότι ακόμα και για 16 πυρήνες και grain size 1 με πλήθος επαναλήψεων (10^8) ώστε το ένα thread να κάνει κάπου στα 6 δευτερόλεπτα ο χρόνος εκτέλεσης φτάνει σε τετραπύρηνο vm την 1 ώρα.Από ότι βλέπω αν πάμε στο grain size 100 ακόμα και να πάει 10 φορές ο χρόνος πρακτικά δεν πρόκειται να τελειώσω σε μια εβδομάδα ενώ αν πάει ο χρόνος επί 100 πρακτικά δεν θα τελειώσουμε ούτε σε 3 εβδομάδες. Από την μια μπορώ να πάρω 10^6 επαναλήψεις αλλά οι μισές μετρήσεις θα βγούν κάτω από 10 δευτερόλεπτα ή για τα μεγαλύτερα grain να μειώνω τις επαναλήψεις. Εκτός και αν δεν έχω εκτιμήσει σωστά τον ρόλο του grain (από ότι κατάλαβα από τον κώδικα απλά μεγαλώνει το critical section άρα έχουμε περισσότερες πράξεις αλλά και περισσότερες προσβάσεις στο κλειδί από τα άλλα νήματα) Επίσης από ότι βλέπω οι επαναλήψεις που βάζουμε είναι για κάθε νήμα χωριστά (το συμπέρανα και από τα αποτελέσματα του deebug mode).Στις προσομοιώσεις που αυξάνουμε τους πύρινες ταυτόχρονα καταλαβαίνω ότι ζητάμε από δεκαπλάσιο π.χ hardware να εκτελέσει δεκαπλάσια εργασία και θέλουμε να δούμε πόσο χρόνο θα κάνουμε.Στο πραγματικό σύστημα όμως δεν καταλαβαίνω πρακτικά τι ψάχνουμε όταν πηγαίνουμε πάνω από τους επεξεργαστές του συστήματος. Εδώ είναι και τα μέχρι τώρα αποτελέσματα μου για 10^8 επαναλήψεις με tas σε 1 2 4 8 16 πυρήνες και grain 1 Execution time:5.242893 seconds Execution time:51.152378 seconds Execution time:207.640789 seconds Execution time:924.958131 seconds Execution time:3806.550578 seconds Μπορεί να μου δώσει κανείς καμιά ιδέα/συμβουλή: Ευχαριστώ εκ των προτέρων
2013/6/30 Nikos Anastopoulos anastop@cslab.ece.ntua.gr
Καλησπέρα,
On 06/29/2013 01:03 PM, Lambros Flokas wrote:
Στην εκφώνηση λέτε να χρησιμοποιήσουμε τους ίδιους αριθμούς νημάτων με τις προσομοιώσεις.Παρατηρώ όμως ότι αν δοκιμάσω για περισσότερα νήματα από ότι πυρήνες στο vm μου βγάζει το ακόλουθο μήνυμα Error in pthread_setaffinity_np. Αυτό μου φαίνεται πολύ λογικό αφού η αντιστοίχιση νημάτων και πυρήνων γίνεται όπως λέει και η εκφώνηση 1 προς 1 .
Ναι, είναι λογικό να συμβαίνει αυτό όταν ο αριθμός των threads (Ν) είναι μεγαλύτερος από τον αριθμό των πυρήνων (C), αφού σε αυτήν την περίπτωση η pthread_setaffinity_np θα προσπαθήσει να κάνει bind π.χ. το thread i > C στην cpu i, που ειναι ανύπαρκτη. Συνεπώς θα επιστραφεί σφάλμα.
Για να το αποφύγετε αυτό, προτείνω να κάνετε κάτι από τα εξής: α) Να βάλετε την pthread_setaffinity σε σχόλια. Με αυτόν τον τρόπο δεν ορίζετε εσείς το affinity, αλλά αφήνετε το λειτουργικό να κάνει αυτό το scheduling των threads όπως νομίζει.
β) Να κάνετε bind τα threads στις cpus με κυκλικό τρόπο. Δηλαδή, το thread i στην cpu i mod C (ουσιαστικά αλλάζετε την κληση CPU_SET(ta->my_id, &mask) σε CPU_SET(ta->my_id % C, &mask) -- φυσικά χρειάζεται να δινετε στο προγραμμα σαν επιπλέον παραμετρο τον αριθμό C των cpus).
Λογικά και οι 2 αυτοι τροποι θα πρέπει να δίνουν αντιστοιχα αποτελέσματα.
Ν.
Απλά ρωτάω για επιβεβαίωση κυρίως, αν θα τρέξουμε τις προσομοιώσεις
μέχρι το πλήθος πυρήνων του vm ή αν κάνω εγώ κάτι λάθος. Σας ευχαριστώ εκ των προτέρων Λάμπρος Φλόκας
______________________________**_________________ Advcomparch mailing list Advcomparch@lists.cslab.ece.**ntua.grAdvcomparch@lists.cslab.ece.ntua.gr http://lists.cslab.ece.ntua.**gr/mailman/listinfo/**advcomparchhttp://lists.cslab.ece.ntua.gr/mailman/listinfo/advcomparch
-- Dr. Nikos Anastopoulos
Research Associate National Technical University of Athens (NTUA) School of Electrical and Computer Engineering Computing Systems Laboratory
e-mail: anastop@cslab.ece.ntua.gr Tel: +30-210-7724159
On 06/30/2013 06:45 PM, Lambros Flokas wrote:
Αυτό που παρατηρώ τώρα (έχοντας κάνει κάμποσα μπρος πίσω λόγω λαθών στην lock) είναι ότι ακόμα και για 16 πυρήνες και grain size 1 με πλήθος επαναλήψεων (10^8) ώστε το ένα thread να κάνει κάπου στα 6 δευτερόλεπτα ο χρόνος εκτέλεσης φτάνει σε τετραπύρηνο vm την 1 ώρα.
Τα 6 δευτερόλεπτα θεωρώ ότι είναι κάπως μεγάλος χρόνος. Μπορείς να μειώσεις τις επαναλήψεις σου ώστε να έχεις ναι μεν μικρότερο χρόνο αλλά σε κάθε περίπτωση μετρήσιμο και όχι στα όρια του στατιστικού λάθους (π.χ. της τάξης των αρκετών msec).
Από ότι βλέπω αν
πάμε στο grain size 100 ακόμα και να πάει 10 φορές ο χρόνος πρακτικά δεν πρόκειται να τελειώσω σε μια εβδομάδα ενώ αν πάει ο χρόνος επί 100 πρακτικά δεν θα τελειώσουμε ούτε σε 3 εβδομάδες. Από την μια μπορώ να πάρω 10^6 επαναλήψεις αλλά οι μισές μετρήσεις θα βγούν κάτω από 10 δευτερόλεπτα ή για τα μεγαλύτερα grain να μειώνω τις επαναλήψεις.
Για μεγαλύτερα grain sizes προφανώς μπορείτε να παίξετε με λιγότερες επαναλήψεις ώστε ο χρόνος εκτέλεσης να κυμαίνεται σε λογικά πλαίσια.
Επίσης από ότι βλέπω οι επαναλήψεις που βάζουμε είναι για κάθε νήμα χωριστά (το συμπέρανα και από τα αποτελέσματα του deebug mode).Στις προσομοιώσεις που αυξάνουμε τους πύρινες ταυτόχρονα καταλαβαίνω ότι ζητάμε από δεκαπλάσιο π.χ hardware να εκτελέσει δεκαπλάσια εργασία και θέλουμε να δούμε πόσο χρόνο θα κάνουμε.Στο πραγματικό σύστημα όμως δεν καταλαβαίνω πρακτικά τι ψάχνουμε όταν πηγαίνουμε πάνω από τους επεξεργαστές του συστήματος.
Θεωρητικά, όντως δεν έχει νόημα στα πλαίσια της παράλληλης επεξεργασίας να κάνετε "overcommit" τους επεξεργαστές του συστήματος με περισσότερα threads από το πλήθος τους, αφού κάθε επεξεργαστής σε αυτήν την περίπτωση θα πρέπει να γίνεται time-share ανάμεσα σε 2 ή περισσότερα threads, χωρίς να υπάρχει πραγματική παραλληλία. Τι συμβαίνει όμως στην πράξη; Μένει αμετάβλητη η απόδοση όπως αναμένουμε θεωρητικά, ή όχι; Αυτό καλείστε ουσιαστικά να δείτε και να εξηγήσετε.
Ν.
advcomparch@lists.cslab.ece.ntua.gr
-
Lambros Flokas -
Nikos Anastopoulos