THMMY.gr

Συζήτηση για την πρώτη φετινή εργασία

έχει τρέξει κανείς τα pthreads να συγκρίνουμε λίγο συμπεριφορά? έχω επιτάχυνση 2x σε σχέση με το sequential αλλά κάποια πράγματα με προβληματίζουν

Ναι, με διπύρηνο laptop, πετυχαίνω x2 επιτάχυνση και εγώ

ε εγώ έχω 4πύρηνο για αυτό με προβληματίζει, αν και τώρα έφτασα 2.5x επιτάχυνση και δεν νομίζω ότι πάει παραπάνω εύκολα

Μήπως έχεις πολύ "ψιλό κόκκο" παραλληλίας;

το ελάχιστο grain το βάζω περίπου στην τάξη του 2^14-18. για πιο μικρό το overhead είναι πολύ σημαντικό και καταλήγει να κάνει λιγότερο απο 2x επιτάχυνση

Ετρεξα την qsort-sequential με και χωρις τη Cilk και βρισκω τον ίδιο χρόνο. Σ' εσάς υπάρχει διαφορά;

Και εγώ τόσο, αλλά και παραπάνω. Δεν νομίζω πως είναι εκεί το πρόβλημα.

Την πρώτη (ή μπορεί και τις πρώτες) partition όπου έχουν πολλά δεδομένα να χωρίσουν και τρέχει μόνο ένα instance της qsort-xxx(), την κάνεις παράλληλα;


Αν κάνεις compile την qsort-sequential με gcc -fcilkpluss τότε θα τρέξει sequentially. Πρέπει να κάνεις αλλαγές στον κώδικα για να τρέξει παράλληλα κάτι.

Εγω με 6 πυρήνες στο cilk έχω περίπου 3 φορές καλύτερο χρόνο. Προφανώς δεν πηγαίνει αναλογικά με τα cores. Οι 4 workers απο τους 6 πχ δεν έχουν τρελή διαφορά.

Έκανα αλλαγές στον κώδικα και την έτρεξα. Ξαναδοκίμασα, αναιρώντας τις αλλαγές, και μου έβγαλε τον ίδιο χρόνο. Γι' αυτό ρωτάω, κατά πόσο το δοκιμάσατε εσείς να μου πείτε αν κάνω κάπου λάθος.

Καταρχας θα σου πρότεινα να δημιουργήσεις νέο .c για κάθε υλοποίηση ώστε να μπορείς να τα τρέχεις και ταυτόχρονα :Ρ

Κατά δεύτερον σίγουρα πετυχαίνεις παραλληλοποιηση; Τσέκαρε με το system monitor την χρήση των cpu σου (αν είσαι σε Ubuntu, φαντάζομαι υπάρχει αντίστοιχο για Windows και mac)

Έχει προσπαθήσει κάποιος να παραλληλοποιήσει την partition? Με πολύ προσεκτικό κώδικα ίσως να γίνεται σωστά, χρειάζεται όμως? Κυρίως για openmp μιλάω.

Μικρή διαφορά βλέπω εγώ και μόνο στην περίπτωση μεγάλης εισόδου (2^30). Όπου ο δικός μου υπολογιστής χρειάζεται 60" στο σύνολο για να τα βάλει στην σειρά εκ των οποίων τα ~6" είναι το πρώτο ένα thread που τρέχει μόνο του την partition. Για να μην πήξει στα locks θέλει και αλλαγή ο κώδικας.

Τέσπα, βλέπω ΜΟ ~58" με παραλληλία στην partition (αντί του ΜΟ ~60") αλλά δεν έχω κάνει αρκετές επαναλήψεις για να πω πως τα συμπεράσματα είναι ορθά.

Τελικα την partition την παραλληλοποιουμε?
Ο πιτσιανης μου ειπε πως αν βελτιωνει τον χρονο να το κανω αλλα το θεωρω λιγο ανουσιο απο την στιγμη που τρεχει παραλληλα καθε χωρισμα της Quicksort... Πειτε λιγο καποιος αν εχει κανει κατι παραπανω τουλαχιστον να ξερω αν ειναι να μη το προσπαθω τζαμπα...

Το ακριβώς προηγούμενο πόστ αναφέρεται στην partition :P

Η εκφώνηση αναφέρει πως δίνουμε σαν είσοδο τα threads που θέλουμε να χρησιμοποιήσουμε. Στο cilk και το openmp αυτό φαίνεται λογικό. Στα pthreads όμως είναι υλοποιήσιμο στη δική μας αναδρομική περίπτωση? Μπορούμε να βάλουμε κάποιο δείκτη μέσα στην αναδρομή ώστε να σταματάει. Αυτό κάνατε εσείς? Γενικά η δημιουργία των threads θα έπρεπε να γίνεται μέσα στην αναδρομή?

Ναι, η «επικοινωνία» των threads με τα pthreads γίνεται μέσο global μεταβλητών.

Οπότε ένας απλός counter χρειάζεται

Δεν εχω καταλαβει στην cilk πως υλοποιητε αυτο...
Με τον Set Worker Count?  :(

Ο αριθμός των threads? Υπάρχει built-in συνάρτηση.

<3

Ξέρει κανείς τι παίζει με το diades; είναι ενεργό; και αν ειναι πώς τρέχω οτιδήποτε εκεί;

πως μπορω να περάσω τον πίνακα και το μέγεθος του στα pthreads; μπορω να το κάνω με struct;

Πριν λίγο συνδέθηκα οπότε ναι, είναι ενεργό. Για να τρέξεις κάτι μπορείς είτε να στείλεις το αρχείο με scp είτε να το γράψεις εκεί με κάποιον editor (nano, emacs, vim) και να το κάνεις compile/run.

Μόνο έτσι γίνεται

Έχει καταφέρει κανείς να φτιάξει pthread με επανεκκίνηση των νημάτων μετά την ολοκλήρωση της πρώτης κλήσης τους;

Όχι... νομίζω θέλει πολύ δουλιά και back end κώδικα για να ελέγχει αν κάποια νήματα έχουν τελειώσει και περιμένουν.

Μιλάω για την περίπτωση όπου δεν αφήνεις τα νήματα να πεθάνουν και μετά να ξαναφτιάξεις άλλα. Αυτό και απαιτεί πολλούς πόρους και δεν νομίζω είναι εφικτό με την δομή του προβλήματος μας.

Κάτι άλλο εγώ...
Με την CILK, στον υπολογιστή μου δεν μπορώ να θέσω το nworkers 2^7 και 2^8 και στον diades πάλι δεν δέχεται nworkers 2^8.

Εσείς τι συναντάτε;

Εγω εχω καταλάβει ότι στη Cilk και στο Openmp δεν μπορείς να χρησιμοποιήσεις παραπάνω θρεντς απο τους πυρήνες σου και αυτό διότι ενα θρεντ τρέχει σε ενα core. Στο openmp πχ όταν δήλωνα 4, έβλεπα ότι οι 4 πυρήνες ήταν στο 100% και οι υπόλοιποι σε idle. Βέβαια μπορεί να είναι και θέμα υλοποίησης. Εννοείς ότι δίνει κάποιο σφάλμα ή ότι δεν έχεις βελτίωση στο χρόνο?

Κάθε στιγμή τρέχουν μόνο τόσα threads όσο ο αριθμός των πυρήνων σου, ενώ τα υπόλοιπα απλά περιμένουν. Ωστόσο μπορείς να εκκινήσεις όσα νήματα θες* ανεξάρτητα υλοποίησης (Cilk/openmp), απλά πρέπει να προσέξεις πως θα το κάνεις. Στην openmp για παράδειγμα δε φτάνει να θέσεις τον αριθμό νημάτων. Πρέπει να απενεργοποιήσεις και τον δυναμικό καθορισμό του αριθμού τους.

*νταξ, υπάρχει ένα άνω όριο αλλά είναι μεγάλο, η openmp για παράδειγμα ξεκινάει μέχρι 2^13 νήματα σε εμένα, μετά πετάει ένα error message

Κάπου είχε πάρει το μάτι μου μια εντολή για να δεις μέχρι πόσα threads επιτρέπει το λογισμικό σου. Πρακτικά όμως το να χρησιμοποιείς παραπάνω threads απο τους πυρήνες σου προσθέτει ενα switching overhead που μπορεί να κάνει ζημιά. Είναι σαν να έχεις 8 εργάτες αλλα 4 εργαλεία.

Στο github είδα κάποιες βιβλιοθήκες που προσφέρουν δυνατότητα thread pooling στα pthreads. Θέλει αρκετή δουλειά η οποία δεν νομίζω οτι χρειάζεται για την εργασία. 

Μπορείς με όλες τις τεχνικές να ορίσεις μεγάλο αριθμό threads. Δεν είναι κάτι περίεργο να τρέχουν πολλά threads σε ένα μηχάνημα, ή για μια διεργασία.

(https://www.thmmy.gr/smf/index.php?action=dlattach;topic=72694.0;attach=57990)

Δες στο μηχάνημα μου, όπου συνολικά τρέχουν 1395 threads με το dropbox (στο screenshot) να τρέχει 128 και τώρα που γράφω 131.

Φυσικά και υπάρχει overhead στην δημιουργία των threads, αλλά από την στιγμή που τα έχεις φτιάξει, απλά σου τρώνε λίγο μνήμη. Δεν είναι τόσο μεγαλύτερο το overhead των κλήσεων των threads στον επεξεργαστή, σε σχέση με την κλήση των processes.

Τώρα, για την cilk, η __cilkrts_set_param() είναι που ορίζει και την παράμετρο nworkers, και το πρόβλημα μου είναι πως για τις τιμές που αναφέρω, επιστρέφει τιμή διάφορη του 0, και συγκεκριμένα επιστρέφει 2, όπου στο cilk-api.h διαβάζω σημαίνει πως η τιμή όπου του έδωσα είναι out of range. Νομίζω αν δεν κάνεις εσύ τον έλεγχο για το τι επιστρέφει, συνεχίζει το πρόγραμμα με την default τιμή.

Ναι έχεις δίκιο. Και σε μένα αυτές οι δύο τιμές επιστρέφουν 2. Επίσης βλέπω πως για 64 threads ο χρόνος ανεβαίνει πάρα πολύ σε σχέση με τα προηγούμενα και δεν έχω καν κέρδος έναντι του σειριακού.

Συμφωνώ με το αποτέλεσμα σου.

Αλλά για pthread και openmp μπορώ να έχω στατιστικά από 2^1 .. 2^8 και μου την σπάει που η cilk αρνείται.

Είναι θέμα της cilk που εξαρτάται απο τον επεξεργαστή, έτρεξα το πρόγραμμα στην ιδρυματική συστοιχία με 16 φυσικούς πυρήνες και δέχθηκε 256 threads. Ο χρόνος πάντως είναι πάλι χειρότερος.  Το 0 που φαίνεται στην αρχή είναι η τιμή που επέστρεψε η __cilkrts_set_param(). Λίγο τσαπατσούλικο αλλα βιαζόμουν  :P

Παιδιά καλησπέρα,

Υπάρχει κανείς που να είδε speed-up μεγαλύτερο από τον αριθμό των πυρήνων του (χάρη στο multi-threading)

Έχω 4 πυρήνες με multi-threading στα 8 και για cilk έχω 3,9 φορές επιτάχυνση (στα 8 threads), για omp 3,8  (στα 8 threads) και για pthreads 4,1  (στα 64! threads)

Ο Πιτσιάνης μου είχε πει ότι στα 8 threads ίσως μπορέσω να δω και 6 επιτάχυνση, κάτι τέτοιο όμως δεν το βλέπω και πολύ εφικτό

Φέρτε laptop αύριο όσοι έρθετε στο σεμινάριο!
Υπάρχει κάποιο τεχνικό πρόβλημα με την Βεργίνα
(και με την αποστολή emails) :P

εχω ένα περίεργο πρόβλημα στην cilk. Για p=1 ή p=2 (δηλαδη 2 και 4 threads) ο χρόνος π κάνει είναι σταθερός και λίγο πιο αργός απο τον sequential ανεξαρτήτως από grain size ενώ επίσης τρέχουν όσοι επεξεργαστές θα έπρεπε (2 και 4). Από p=3 και μετά όμως ο χρόνος είναι κανονικά παρόμοιος με openmp/pthreads (3x επιτάχυνση περίπου). Το έχει αντιμετωπίσει κανείς? είναι φυσιολογικό?

Προσπαθω να τρεξω τον κωδικα των pthreads και μου λεει  "undefined reference to function"
Δε μου το εβγαζε χθες αλλα σημερα αλλαξα τον κωδικα και εβαλα αλλες δυο συναρτησουλες στο αρχειο qsort-pthread.
ΤΙ ΣΥΜΒΑΙΝΕΙ? ΓΙΑΤΙ ΜΟΥ ΣΠΑΕΙ ΤΑ ΝΕΥΡΑ?

Δοκίμασε να βάλεις flag -lpthread όταν κάνεις compile. (αν δεν δουλέψει και πάλι, δοκίμασε το flag -pthread)

μεχρι χθες ετρεχε κανονικα, δεν ειναι θεμα τα flags... :-\ :-\ :-\

λείπει κάποιο declaration προφανώς. λογικά ξέχασες κάτι να βάλεις στο header ή μπορει να έχεις βάλει τις συναρτήσεις κάτω από τον κώδικα και να μην τις έχεις δηλώσει πάνω πάνω (ή εμπάς η περιπτώση πριν γίνει η κλήση της συνάρτησης) αν είναι στο ίδιο αρχείο και όχι στο header.

εντωμεταξύ μαρέσει που λες "Μου βγάζει σφάλμα σε αυτό που πρόσθεσα τώρα! Αλλά δεν βγάζει νόημα, χθες έτρεχε κανονικά πριν προσθέσω το κομμάτι που δημιουργεί το σφάλμα!"   :P

Professorα μην μας τρελάνεις. Αν έχεις προσθέσει το header, βάζεις και σωστά τα flags στο compilation, δύσκολα να έχεις θέμα. Επίσης, το σφάλμα που σου βγάζει σου λέει σε ποια σειρά εμφανίζεται. Τσέκαρε μήπως κάνεις κάνα typo.

Με pthreads μου βγάζει 2x επιτάχυνση περίπου σε σύστημα 6c/12t είναι λογικό;
Επίσης για να γίνει compile με pthreads προσθέτουμε το -lpthread στο τέλος του all ή χρειάζεται κάτι παραπάνω;

Ξέρουμε αν θα πάρει παράταση η 1η Εργασία;

Κανονικά εκεί που υποστηρίζει ο επεξεργαστής το multithreading  θα έχεις την καλύτερη απόδοση αλλά με τα pthreads έχω και εγώ παρόμοιο πρόβλημα ( να πετυχαίνω καλύτερο χρόνο με περισσότερα threads ) . Ξέρει μήπως κανείς γιατί μπορεί να γίνεται αυτό?

Νομίζω πως θα μπορούσες να έχεις αρκετά καλύτερη βελτίωση με τέτοιο σύστημα. Εγώ σε 6 πυρήνες έχω 4x και μπορεί να βελτιώνεται και αλλο.

Παιδία, η αναφορά πρέπει να είναι το μέγιστο 3 σελίδες;;;

Πιστευετε θα μπορούσε να δοθεί παράταση;

στο τελευταιο μαθημα ο πιτσιανης ειπε οτι θα προσπαθησει να τηρηθουν τα deadline

τελικά με πια qsort πρέπει να συγκρίνουμε τις παράλληλες εκδοχές μας; Με την qsort_seq που μας δίνει ή πρέπει να βρούμε αυτήν που έχει στην stdlib;

Την Κυριακή η παράδοση!  :D

ΠΑΡΑΤΑΣΗ!! Μέχρι Κυριακή 4 π.μ.

ούτε εγώ μπορώ να τρέξω στην cilk και openmp για 128 ή 256 threads, μήπως φταίει ότι έχω διπύρηνο λάπτοπ;

το cilk και σε μένα τρέχει μόνο ως 64 threads (αν βάλεις παραπάνω το αγνοεί), αναμενόμενο, μας το είπε και ο Πιτσιάνης, νομίζω έχει να κάνει με τον compiler
openmp δεν έχω θέμα, παει ως 256, δεν έλεγξα παραπάνω
στα pthreads έχω θέμα, μου επιστρέφει error 11 η συνάρτηση pthread_create όταν βάζω πάνω από 8 threads και πίνακες πάνω απο 2^14 (με 8 threads πάει σε πίνακα 2^24 χωρίς πρόβλημα και με 256 threads πάει μόνο μέχρι πίνακα 2^14 χωρίς error αυτό εννοω)
έχω τετραπύρηνο i5 και 8 gb ram γι'αυτό μου κάνει εντύπωση, έχει κανένας παρόμοιο πρόβλημα?

και επειδή έχασα το μάθημα της Τρίτης μπορεί να πει κάποιος αν είπε κάτι διαδικαστικό ο Πιτσιάνης?
πχ Τρίτη ήταν το τελευταίο μάθημα? μήπως θα κάνει ο Δημήτρης καμιά διάλεξη?
και αν ανέφερε μέχρι πότε μας αφήνει περιθώριο η nvidia να υποβάλουμε την άσκηση, ty

Θα έχουμε πρόσβαση στα VMs της Nvidia για ενα ολόκληρο χρόνο! Δεν είναι ξεκάθαρο το deadline της εργασίας αλλα δεν είναι απίθανο να είναι και αυτό για ενα χρόνο.  Τώρα για το πρόβλημα σου, είσαι σίγουρος ότι ελέγχεις σωστά τον αριθμό των threads που δημιουργείς? Μήπως ξεφεύγει πολύ και βγαίνει απο τα όρια?

Στα pthreads έχω το εξής περίεργο πρόβλημα: τρέχοντας ακριβώς τον ίδιο κώδικα σε σύστημα με AMD 6c/12t παίρνω επιτυχανυση το πολύ x3.5, ενώ τρέχοντας το σε Intel 4c/8t έχω επιτάχυνση x4.5+. Υπάρχει κάποια πιθανή εξήγηση γι αυτό;
οι εκδόσεις με cilk / openmp τρέχουν κανονικά με αναμενόμενο αποτέλεσμα

Από το elearning στο μάθημα των παράλληλων έχει αρχεία, παραδείγματα. Κατέβασε το pthread και άνοιξέ το fib.c ώστε να βάλεις 200 και threads. Κάνε compile κι αν τρέχει καλά για μεγάλο αριθμό και βλέπεις ότι πράγματι τρέχουνε όλα τα threads τότε δεν έχει πρόβλημα το μηχάνημα σου.

Απ' ό,τι διάβασα οι κατασκευαστές ενσωματώνουν, κάπως, τη λειτουργία των pthreads απ' ευθείας στο πυρίτιο. Ίσως η ιντελ να έκανε καλύτερη δουλειά...

με την αξιολόγηση τί παίζει;

Αξιολογείς κάποιες εργασίες απο συμφοιτητές. Εαν είσαι δίκαιος παίρνεις κάποιους βαθμούς. Αν δεν την κάνεις καθόλου, η εργασία σου παίρνει μέγιστο 8.

Στις αξιολογήσεις τι διαφορά έχουν τα πρώτα 2 aspects?

αν και εχει περασει η προθεσμία φαντάζομαι ότι ίσχυε αυτό:

στο πρώτο έλεγχες η υλοποίηση να εβγαζε σωστά αποτελέσματα, ανεξαρτήτου χρόνου. Δηλαδή αν ταξινομούσε σωστά και με την σωστή αξιοποίηση threads (2^P αντι για πχ αποκλειστικά 4) λογικά.

στο δεύτερο έπαιζε προφανώς ρόλο η ταχύτητα/βελτιστοποίηση.

Την Τετάρτη 14 Νοεμβρίου θα δοθεί παρουσίαση από την ομάδα του Hellasgrid στις 17:00 στην αίθουσα Α3. Θα δείτε αναλυτικές οδηγίες για την σύνδεση στο grid και την εκτέλεση πειραμάτων σε αυτό.