Προς το περιεχόμενο

Πως θα χρησιμοποιήσω ν-πύρινο επεξεργαστή..?


karabouzouk...

Προτεινόμενες αναρτήσεις

Δημοσ.

Εχω μια απορία... οι επεξεργαστές που έχουν παραπάνω από ενα πυρήνα πως δουλεύουν...? Αν πχ εχω εναν αλγόρυθμο... που κάνει πολλές επαναλήψεις και παίρνει ώρα να τερματήσει, η λύση θα ήταν να τον χωρίσω σε δύο ξεχωριστά κομμάτια και να τα βάλλω να τρέχουν μαζί...? Ετσι θα εκτελούνταν όντως ταυτόχρονα χτησιμοποιώντας κάθε μέρος διαφορετικό πυρήνα..? Είναι αυτό κάτι που αναλαμβάνει το λειτουργικό(??) ή πρέπει να το λάβει υπ οψιν του ο προγραμματιστής με κάποιον τρόπο..?

Ελπιζω να καταλάβατε τι θέλω να ρωτήσω....ευχαριστώ..!

Δημοσ.

Το λειτουργίκο δεν αναλαμβάνει να χωρίζει προγράμματα σε CPUs (δεν είναι εύκολο να γίνει).

 

Αυτό που κάνει το λειτουργικό είναι να μοιράζει τα threads μίας εφαρμογής σε διαφορετικούς πυρήνες ανάλογα με τις απαιτησείς τους και με το τί άλλο τρέχει.

Είναι δουλειά του προγραμματιστή να γράψη την εφαρμογή του με threads (και να χωρίσει την "βαριά" δουλειά σε 2-3-ν threads) ώστε μετά το λειτουργικό να τα μοιράσει όπως πρέπει....

Δημοσ.

Οντως για κανε το λίγο πιο λιανά...!!! σε επίπεδο εγώ γραφω εναν αλγόρυθμο....πες οτι μπορώ να τον χωρίσω σε κομμάτια... πρεπει να φτιάξω διαφορετικα εκτελέσιμα και να τα τρέχω μαζί η κάτι τέτοιο....??

Δημοσ.

Αυτη ειναι δουλεια του λειτουργικου,να χρισημοποιει τους πορους του hardware(για αυτο ειναι το λειτουργικο)

εναν κανεις καπιο προγ το οποιο θα κανει χρηση των πορων αυτοβουλα = crash...

αυτο που θελεις ειναι thread

δλδ εχεις δυο αλγορυθμους

>alg1
{
<<καπιο απιρο loop>>(;
{
<<καπια σιναρτιση output>>("Boom!!")
<<call alg>>
}
}
alg2
{
<<καπια σιναρτιση sleep(απιρο)>>
}

χορης thread το προγ θα εκτιποσει μια φορα το boom!!

με 2 διαφορετικα thread θα εκτιπονει απιρα το boom!!

Δημοσ.

Τα έχετε μπερδέψει λίγο. Άλλο πράγμα το να φτιάχνεις ένα thread για κάθε αλγόριθμο μέσα στο πρόγραμμά σου (άρα κάνουν άσχετη δουλειά το ένα από το άλλο) και άλλο το να υλοποιήσεις τον ίδιο αλγόριθμο για πολυεπεξεργαστικό σύστημα.

 

Με λίγα λόγια, το να χωρίσεις ένα αλγόριθμο σε κομμάτια (υπο-αλγόριθμους σα να λέμε) και να τα στείλεις σε threads, ίσως βελτίωσες την απόδοση σε περισσότερους από έναν πυρήνες, αλλά αυτό δε σημαίνει πως ο αλγόριθμος προγραμματίστηκε ως multi processing...

 

Υ.Γ. Ο Uagm έδωσε όντως σχετική απάντηση όσο έγραφα το μήνυμα.

Δημοσ.

Μπορείς να καθορίσεις σε ποιούς επεξεργαστές-πυρήνες επιτρέπεται να εκτελεστεί ένα thread και σε linux και σε windows. Το θέμα είναι αν θα έχεις κέρδος ή ζημιά από κάτι τέτοιο. Φαντάσου δηλαδή να ορίσεις ότι ένα thread θα εκτελείται μόνο στον core #2. Σε ένα rescheduling πχ μετά από διακοπή, θα πρέπει να περιμένεις υποχρεωτικά να ελευθερωθεί o #2, ενω αν δεν είχες ορίσεις τίποτα, το thread σου θα συνεχιζόταν σε κάποιον άλλο ελεύθερο πυρήνα. Ακόμα χειρότερα, κάποια άλλοι είχαν την ίδια ιδέα με εσένα, και ένας αριθμός threads πασχίζει να εκτελεστεί στον πυρήνα #2, ενώ όλοι οι άλλοι είναι ελεύθεροι. Μια εναλλακτική για αυτό το πρόβλημα στα windows είναι να χρησιμοποιήσεις την SetThreadIdealProcessor με την οποία απλά προτείνεις τον επεξεργαστή που θα χρησιμοποιηθεί, χωρίς να δεσμεύει το scheduler να ακολουθεί την πρότασή σου κάθε φορά, αν κρίνει ότι υπάρχει καλύτερη επιλογή.

Δημοσ.

Καλά δε νομίζω πως για να καταφύγεις σε real multi processing θα κάτσεις να προγραμματίσεις τίποτα custom μαντζούνια περιορισμένης ευθύνης. Μάλλον θα καταφύγεις σε πρακτικές, όπως π.χ. η χρήση του OpenMP που ανέφερε παραπάνω ο Uagm, που θα αναλάβουν για πάρτη σου.

 

Μπορεί σήμερα που ακόμα υπάρχουν dual core επεξεργαστές να μην είναι ακόμα ιδανικό το να πάμε σε τέτοιες τεχνικές προγραμματισμού, αλλά σίγουρα είναι μια αναγκαιότητα για το μέλλον, αφού οδηγούμαστε σε πολυπήρηνους.

Δημοσ.
Καλά δε νομίζω πως για να καταφύγεις σε real multi processing θα κάτσεις να προγραμματίσεις τίποτα custom μαντζούνια περιορισμένης ευθύνης. Μάλλον θα καταφύγεις σε πρακτικές, όπως π.χ. η χρήση του OpenMP που ανέφερε παραπάνω ο Uagm, που θα αναλάβουν για πάρτη σου.

 

Μπορεί σήμερα που ακόμα υπάρχουν dual core επεξεργαστές να μην είναι ακόμα ιδανικό το να πάμε σε τέτοιες τεχνικές προγραμματισμού, αλλά σίγουρα είναι μια αναγκαιότητα για το μέλλον, αφού οδηγούμαστε σε πολυπήρηνους.

 

Σαφώς και είναι προτιμότερο το openmp ειδικά για αλγόριθμους. Αλλά από που και ως που "ματζούνια" να κάνεις ένα fork, όταν έχεις δύο διακριτές διαδικασίες. Γιατί να προτιμήσεις σε ένα τέτοιο σενάριο το openmp που είναι και μπελαλίδικο στο χειρισμό σφαλμάτων.

Δημοσ.

Άμα είσαι σίγουρος για τον εαυτό σου και ξέρεις τί να κάνεις μπορείς να κάνεις ό,τι θέλεις, respect. Αλλά το έτοιμο είναι συνήθως πιο μελετημένο και δοκιμασμένο, με αυτή την έννοια.

:)

 

edit:

Ώπα, τί εννοείς διακριτές? Όπως είπα και παραπάνω, άλλο το να δημιουργείς διαφορετικά threads για κάθε "διακριτή διαδικασία" και άλλο ΜΙΑ διακριτή διαδικασία να την κάνεις multi threaded (με το OpenMP εν προκειμένω). Άλλο το ένα, άλλο το άλλο. Το θέμα είναι να μετατρέψουμε τη σειριακή διαδικασία σε παράλληλη! Πολλά threads, πχ ένα για κάθε "διακριτό", έχουν όλα τα πολυσύνθετα προγράμματα, δεν είναι κάτι νέο.

Δημοσ.
Ώπα, τί εννοείς διακριτές?

Εννοώ όσο διακριτό είναι το user interface από ένα task που τρέχει στο background. Ή ένα ευρετικό που τρέχει ταυτόχρονα έναν genetic algorithm και ένα tabu search, όποιο βρει πιο γρήγορα τη λύση.

Το θέμα είναι να μετατρέψουμε τη σειριακή διαδικασία σε παράλληλη!

Συμφωνούμε απόλυτα ότι το OpenMP είναι η καλύτερη λύση εδώ.

Άμα είσαι σίγουρος για τον εαυτό σου και ξέρεις τί να κάνεις μπορείς να κάνεις ό,τι θέλεις, respect. Αλλά το έτοιμο είναι συνήθως πιο μελετημένο και δοκιμασμένο, με αυτή την έννοια.

Ακριβώς επειδή δεν είμαι τόσο σίγουρος για τον εαυτό μου, στην 'διακριτή' περίπτωση θέλω να ξέρω ακριβώς τι εκτελείται και που κάθε στιγμή. :-)

Δημοσ.

Το να μετατρέψεις ένα πρόβλημα από ακολουθιακό σε παράλληλο είναι ίσως το πιο δύσκολο σε αυτό το κομμάτι!!! Αρκετά προβλήματα δεν είναι δυνατό να τα κάνεις παράλληλα (στο θεωρητικό κομμάτι πάντα).

Τώρα όσον αφορά προγραμματιστικά υπάρχουν αρκετά εργαλεία (OpenMP, MPI, ompi - το δουλεύουν καθηγητές εδώ στα Γιάννενα), το θέμα είναι όμως κατά πόσο είναι παράλληλος ο τρόπος επίλυσης του προβλήματος. Σε OpenMP πχ μπορείς να κάνεις ένα πρόγραμμα για πολλαπλασιασμό πινάκων και κάθε νήμα να αναλαμβάνει κάθε γραμμή.

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

Καλό είναι να μελετήσεις τα εργαλεία που αναφέρθηκαν και παραπάνω αν και δεν είναι λύση για όλα. Πιστεύω ότι το όλο πρόβλημα είναι να μετατρέψεις τον αλγόριθμο από ακολουθιακό σε παράλληλο...

Δημοσ.

ΟΚ, δεν διαφωνούμε ουσιαστικά σε τίποτα.

 

Φαντάζομαι και ο karabouzouklis που ρώτησε αρχικά έχει πάρει την απάντησή του. Απ'όσο κατάλαβα από τον τρόπο που ρώτησε, εκείνο που τον ενδιέφερε ήταν το σειριακό -> παράλληλο (και όντως δεν είναι απλό), γι αυτό εστίασα εκεί.

Αρχειοθετημένο

Αυτό το θέμα έχει αρχειοθετηθεί και είναι κλειστό για περαιτέρω απαντήσεις.

  • Δημιουργία νέου...