Να παραλληλίσω ή να μη παραλληλίσω και πώς;

[dop]

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

 

Έχετε να υλοποιήσετε μια εφαρμογή η οποία χρειάζεται είτε να επεξεργαστεί μεγάλο όγκο δεδομένων, όπως ένα πρόγραμμα επεξεργασίας εικόνας/βίντεο ή επιστημονικού υπολογισμού, είτε να πετύχει high throughput, όπως για παράδειγμα μια εφαρμογή realtime transcoding για live streaming - όχι ακριβώς απλά καθημερινά παραδείγματα, απλώς παραδείγματα

 

1. Καταρχάς θα διαλέγατε να κάνετε την εφαρμογή σας σειριακή ή παράλληλη (μια εφαρμογή που χρησιμοποιεί threads για I/O δεν θεωρείται παράλληλη); Τι θα σας σταματούσε από το να σκεφτείτε να την κάνετε παράλληλη (hardware, φόβος για το αν ένα παράλληλο πρόγραμμα θα δούλευε σωστά);
2. Ποιά γλώσσα θα διαλέγατε και γιατί (Fortran, C/C++, Java, Python, Perl, C#, Visual Basic κλπ); Αν η αιτιολόγηση συνοδεύεται από βιβλιογραφία και αδιάψευστα πειράματα, τόσο το καλύτερο, αλλά δεν είναι υποχρεωτικό. Απάντηση "επειδή μόνον αυτή τη γλώσσα ξέρω" είναι αποδεκτές, απαντήση "επειδή όλες οι υπόλοιπες είναι απαράδεκτες" δεν είναι αποδεκτή.
3. Ποιο παράλληλο μοντέλο θα διαλέγατε και γιατί; Για παράδειγμα Message passing (πχ MPI, PVM), shared-memory (OpenMP, Cilk/Cilk++, Intel Threading Building Blocks, Intel Array Building Blocks κλπ), global address space (GASNet, Unified Parallel C, Titanium, X10, Chapel κλπ), heterogeneous (πχ OpenCL, CUDA) ή κάποια ad-hoc λύση (pthreads, C++0x threads, sockets, RPC).
4. Πόσο σας ενδιαφέρει το portability της εφαρμογής σας και η διάρκεια ζωής της; Είναι κάτι που έχετε σκοπό να δουλεύει για χρόνια ή απλά κάτι για σήμερα και αύριο βλέπουμε; Πόσο σκεφτήκατε αυτά τα δύο θέματα για να απαντήσετε τις ερωτήσεις 1-3;
5. Τι σας απασχολεί όταν αναπτύσσετε μια εφαρμογή σαν προγραμματιστές; Είστε διατεθιμένοι να θυσιάσετε την απόλυτη απόδοση σήμερα για να έχετε ένα καθαρό codebase ή θα κάνετε ό,τι "βρώμικο" κόλπο υπάρχει για να κερδίσετε 1-2 κύκλους; Πόσο αυτή σας η αντίληψη για τον κώδικα επηρρέασε τις παραπάνω απαντήσεις σας;
6. Τέλος, αν υπάρχει ένα framework που σας επιτρέπει να εκφράζετε την εφαρμογή σας σαν tasks και αναλαμβάνει τα πάντα, από communication σε distributed memory, task execution και placement καθώς και χρήση GPUs, καθώς και είναι φτιαγμένο ώστε να είναι portable σε όλες τις αρχιτεκτονικές, θα ήσαστε διατεθειμένοι να το χρησιμοποιήσετε; Ή θα μένατε σε μια δοκιμασμένη λύση (πχ MPI, OpenMP);

Ευχαριστώ

[Evgenios1]

Αν και δεν εχω καποιο χαρτι που να λεει οτι ειμαι προγραμματιστης.

 

1) Αν κουπου εχουμε να κανουμε με "αργο" ΙΟ σιγουρα θα παω σε async αλλα οχι σε threads (τα win εχουν api για async file,socket etc..)

2) Win api (αυτο το ρημαδι με τα message ειναι πολυ γρηγορο) (γλωσσα καποια compiled)

 

4) Εξαρτατε, αν ειναι γραμενω σε καποιο framework, build και γεια σου, αν ειναι σε καποιο σοβαρο api (βλεπε win που κραταει πραγματα απο nt 16bit, η καποιο αλλο που σεβεται το εαυτο του) σιγουρα θα το σκεφτω.

 

5) 4

 

6) Kernel mode > User mode

 

 

Πλζ μην με flamαρετε, δεν διαφημιζω τα windows, απλα μονο αυτα ξερω

 

[parsifal]

1α. Παράλληλη, αν για το πρόβλημα υπάρχει tried and true παράλληλος αλγόριθμος(-οι) που να επιτυγχάνει scalability άξιο λόγου

1β. Το ενδεχόμενο οι παραπάνω υποθετικοί αλγόριθμοι να είναι πέραν των δυνατοτήτων μου για πλήρη κατανόηση, ώστε να τους κωδικοποιήσω με αυτοπεποίθηση. Ή να είναι πρακτικά ανεφάρμοστοι στις ιδιαίτερες συνθήκες υπό τις οποίες θα κληθεί να τρέχει η εφαρμογή

 

2. C/C++, Java, C#. Αυτές ξέρω επαρκώς

 

3. Shared memory (OpenMP) ή ad-hoc (pthreads ή κάποιο abstraction layer τους όπως οι threading classes του Qt framework, sockets, RPC), κατά περίπτωση και ανάλογα με το υπολογιστικό σύστημα που θα τρέχει η εφαρμογή. Τεχνολογίες όπως OpenCL και CUDA είναι ιδιαίτερα ενδιαφέρουσες, αλλά με πολύ περιοριστικές υλοποιήσεις προς το παρόν

 

4α. Αρκετά, αλλά δεν είναι το παν. Καθοριστικός παράγοντας θα είναι η ανάλυση απαιτήσεων

4β. Αναγκαστικά, αρκετά

 

5α. Επειδή είμαι και κάπως φειδωλός στο code commenting, προτιμώ καθαρό, ευκολοδιάβαστο κώδικα παρά να γράφω ταρζανιές για να κερδίσω ψιλοπράγματα

5β. Όχι ιδιαίτερα, η αντίληψη νομίζω πως έχει κατά κανόνα εφαρμογή σε όλες τις υψηλού επίπεδου γλώσσες προγραμματισμου

 

6. Θα ήμουν διατεθειμένος να το δοκιμάσω, σίγουρα. Αν έβρισκα άμεσα ορατά πλεονεκτήματα έναντι των πιο καθιερωμένων λύσεων, ίσως να ήμουν διατεθειμένος και να το χρησιμοποιήσω

[worldcitizen]

1. Καταρχάς θα διαλέγατε να κάνετε την εφαρμογή σας σειριακή ή παράλληλη (μια εφαρμογή που χρησιμοποιεί threads για I/O δεν θεωρείται παράλληλη); Τι θα σας σταματούσε από το να σκεφτείτε να την κάνετε παράλληλη (hardware, φόβος για το αν ένα παράλληλο πρόγραμμα θα δούλευε σωστά);
   

 

Σίγουρα θα το σκεφτόμουν και στην πλειοψηφία των εφαρμογών που έχω υπόψη μου θα το έκανα. Θα με σταματούσε ένας δύσκολος σχεδιασμός πάνω στην παραλληλοποίηση που θα αύξανε αρκετά την πολυπλοκότητα του κώδικα.

 

• Ποιά γλώσσα θα διαλέγατε και γιατί (Fortran, C/C++, Java, Python, Perl, C#, Visual Basic κλπ); Αν η αιτιολόγηση συνοδεύεται από βιβλιογραφία και αδιάψευστα πειράματα, τόσο το καλύτερο, αλλά δεν είναι υποχρεωτικό. Απάντηση "επειδή μόνον αυτή τη γλώσσα ξέρω" είναι αποδεκτές, απαντήση "επειδή όλες οι υπόλοιπες είναι απαράδεκτες" δεν είναι αποδεκτή.
  

 

Σε Fortran και C/C++ κυρίως, ενώ σε Python θα υλοποιούσα κυρίως με threads αφού απ' όσο γνωρίζω τα υπόλοιπα είναι δημιουργίες χρηστών και δεν υποστηρίζονται στην επίσημη διανομή.

 

• Ποιο παράλληλο μοντέλο θα διαλέγατε και γιατί; Για παράδειγμα Message passing (πχ MPI, PVM), shared-memory (OpenMP, Cilk/Cilk++, Intel Threading Building Blocks, Intel Array Building Blocks κλπ), global address space (GASNet, Unified Parallel C, Titanium, X10, Chapel κλπ), heterogeneous (πχ OpenCL, CUDA) ή κάποια ad-hoc λύση (pthreads, C++0x threads, sockets, RPC).
  

 

• OpenMP γιατί υπάρχουν περιπτώσεις που με λίγο κόπο μπορείς να πετύχεις παραλληλοποίηση με καλή απόδοση.
  
• MPI για να εκμεταλλευτούμε πολλά μηχανήματα.
  
• CUDA γιατί γνωρίζει μεγάλη ανάπτυξη σαν framework/αρχιτεκτονική και υπάρχει αρκετό υλικό για αυτή και
  
• OpenCL γιατί είναι ένα ανοικτό μοντέλο και είναι κρίμα να μην εκμεταλλευόμαστε τις κάρτες γραφικών
  

 

Γενικά θα πω πάντως ότι προσπαθώ να υπάρχουν διαφορετικές εκδόσεις του ίδιου προγράμματος ανάλογα με το παράλληλο μοντέλο, με την επιλογή να γίνεται στο compilation. Για παράδειγμα δεν θα υλοποιήσω μια εφαρμογή αποκλειστικά σε CUDA, αλλά θα υπάρχει και το σειριακό (ή OpenMP) ανάλογο. Ο κόπος σε κάποιες περιπτώσεις δεν είναι τόσο μεγάλος.

 

Επίσης προτιμώ μοντέλα που είναι ανοικτά, έχουν σχετικά μεγάλο user base και αρκετές βιβλιοθήκες (όχι κατ' ανάγκη όλα μαζί).

 

• Πόσο σας ενδιαφέρει το portability της εφαρμογής σας και η διάρκεια ζωής της; Είναι κάτι που έχετε σκοπό να δουλεύει για χρόνια ή απλά κάτι για σήμερα και αύριο βλέπουμε; Πόσο σκεφτήκατε αυτά τα δύο θέματα για να απαντήσετε τις ερωτήσεις 1-3;
  

 

Εξαρτάται από την εφαρμογή. Συνήθως θα έλεγα ότι ξεκινάω με κάτι προσωρινό και αν δω ότι υπάρχει προοπτική, γίνονται οι απαραίτητες διορθώσεις/προσθήκες/αλλαγές για πιο long-term projects. Εννοείται ότι αποφεύγω να γράφω σκουπίδια, κι ότι ο "πρόχειρος" κώδικας πληρεί κάποια κριτήρια. Φυσικά όμως "premature optimization is the root of all evil".

 

• Τι σας απασχολεί όταν αναπτύσσετε μια εφαρμογή σαν προγραμματιστές; Είστε διατεθιμένοι να θυσιάσετε την απόλυτη απόδοση σήμερα για να έχετε ένα καθαρό codebase ή θα κάνετε ό,τι "βρώμικο" κόλπο υπάρχει για να κερδίσετε 1-2 κύκλους; Πόσο αυτή σας η αντίληψη για τον κώδικα επηρρέασε τις παραπάνω απαντήσεις σας;
  

 

"Programs must be written for people to read, and only incidentally for machines to execute."

Την έχω πατήσει αρκετές φορές και θα προτιμήσω το "καθαρό codebase". Πιθανότατα να δοκιμάσω κάποιο "βρώμικο κόλπο" αλλά δεν θα το έβαζα στην "τελική" έκδοση. Βασικό είναι να δίνει σωστά αποτελέσματα για τους σωστούς λόγους και να είναι όσο πιο ξεκάθαρο γίνεται.

 

• Τέλος, αν υπάρχει ένα framework που σας επιτρέπει να εκφράζετε την εφαρμογή σας σαν tasks και αναλαμβάνει τα πάντα, από communication σε distributed memory, task execution και placement καθώς και χρήση GPUs, καθώς και είναι φτιαγμένο ώστε να είναι portable σε όλες τις αρχιτεκτονικές, θα ήσαστε διατεθειμένοι να το χρησιμοποιήσετε; Ή θα μένατε σε μια δοκιμασμένη λύση (πχ MPI, OpenMP);

 

Για λόγους περιέργειας θα το δοκίμαζα, αλλά για να το χρησιμοποιήσω production θα έπρεπε να πληρεί κάποια κριτήρια. Αυτά που μπορώ να σκεφτώ τώρα είναι:

• να υπάρχει ενεργή ανάπτυξη. Σε αυτό θα βοηθούσε και θα έδινε περισσότερο κύρος αν συμμετείχαν κάποιες μεγάλες εταιρίες,
  
• να υπάρχει ικανό userbase,
  
• να υπάρχουν αρκετές αξιόλογες βιβλιοθήκες,
  
• να υπάρχουν υλοποιήσεις στις γνωστές γλώσσες προγραμματισμού,
  
• να είναι ανοικτό "πρότυπο
  
• και να έχει ξαναχρησιμοποιηθεί σε εφαρμογές του κλάδου.
  

 

Αυτά σε συνδυασμό με το να μου προσφέρει κάτι παραπάνω από τις υπάρχουσες λύσεις.

[soulcon]

Εγώ θα έλεγα πως η OpenCL είναι μια καλή πρόταση μόνο και μόνο επειδή δεν θα χρειαστεί να την αλλάξεις για όσο θα υλοποιείς το πρόγραμμά σου (δηλαδή για 4-5 χρονάκια βάααλε) το καλό είναι ότι είναι crossplatform και υποστηρίζεται σε ΟΛΕΣ τις κάρτες γραφικών, αλλά φαίνεται πολύ ερευνητική και πειραματική προς το παρόν.

 

Εν αντιθέσει η CUDA είναι έτοιμη και πλήρης βιβλιοθήκη, έχει κάνει επίσης ντεμπούτο σε διάφορα commercial προγράμματα, όπως π.χ. τα video editors Movavi και Badaboom, ενώ έχω την εντύπωση πως ίσως να παίζει και σε έναν Renderer (ίσως τον VRay προσφέροντας previews σε ημι-πραγματικό χρόνο).