|
|
|
@@ -46,5 +46,167 @@ |
|
|
|
|
|
|
|
\section{Εισαγωγή} |
|
|
|
|
|
|
|
Η παρούσα εργασία αφορά τον παραλληλισμό συστημάτων με κοινή μνήμη. |
|
|
|
Το αντικείμενό είναι ο παραλληλισμός τους αλγορίθμου εύρεσης κοντινότερων γειτόνων \textbf{knnseach}. |
|
|
|
Στην εργασία αυτή υλοποιούμε τόσο μια σειριακή προσέγγιση όσο και μια που παραλληλοποιείται με \textbf{pthreads}, με \textbf{open-cilk} και με \textbf{open-mp}. |
|
|
|
Στην παραλληλοποιήσιμη έκδοση δεν μας ενδιαφέρει η ακρίβεια του αλγορίθμου, κάτι που μας δίνει την δυνατότητα να βελτιώσουμε τον χρόνο εκτέλεσης. |
|
|
|
|
|
|
|
|
|
|
|
\section{Παραδοτέα} |
|
|
|
Τα παραδοτέα της εργασίας αποτελούνται από: |
|
|
|
\begin{itemize} |
|
|
|
\item Την παρούσα αναφορά. |
|
|
|
\item Το \href{https://git.hoo2.net/hoo2/PDS/src/branch/master/homework_1}{σύνδεσμο με το αποθετήριο} που περιέχει τον κώδικα για την παραγωγή των εκτελέσιμων, της αναφοράς και τις μετρήσεις. |
|
|
|
\item Τον \href{https://hub.docker.com/r/hoo2/hpcimage}{σύνδεσμο} με το image με το οποίο μεταγλωττίσαμε και εκτελέσαμε τις μετρήσεις. |
|
|
|
\end{itemize} |
|
|
|
|
|
|
|
\section {Υλοποίηση} |
|
|
|
Πριν ξεκινήσουμε να αναλύουμε τον παραλληλισμό και τις μετρήσεις καλό θα ήταν να αναφερθούμε στην υλοποίηση. |
|
|
|
Για την παρούσα εργασία χρησιμοποιήσαμε τη γλώσσα \textbf{C++} και πέρα από τις βιβλιοθήκες που ζητούνται από την εκφώνηση (cilk/omp) έγινε και χρήση της \textbf{openblas}. |
|
|
|
Βοηθητικά έγινε επίσης χρήση του \textbf{bash} και της \textbf{matlab} κυρίως για την λήψη και οπτικοποίηση των αποτελεσμάτων. |
|
|
|
Στην παρούσα εργασία γίνεται ευρεία χρήση πινάκων τόσο για εισαγωγή και εξαγωγή των δεδομένων, όσο και για τους υπολογισμούς. |
|
|
|
Για το λόγο αυτό θεωρήσαμε ότι έπρεπε πρώτα να υλοποιήσουμε κάποιες αφαιρέσεις που θα μας επέτρεπαν να χειριστούμε ευκολότερα το πρόβλημα |
|
|
|
|
|
|
|
\subsection{Ο τύπος Matrix} |
|
|
|
Η πιο βασική αφαίρεση που υλοποιήσαμε είναι ο τύπος \textbf{Matrix}. |
|
|
|
Πρόκειται για μια αναπαράσταση πινάκων, είτε μονοδιάστατων είτε δισδιάστατων. |
|
|
|
Η υλοποίησή του έγινε με χρήση templates και έτσι μπορούμε να κατασκευάζουμε πίνακες οποιουδήποτε τύπου. |
|
|
|
Η αφαίρεση εσωτερικά κάνει χρίση μονοδιάστατης αποθήκευσης των δεδομένων με αποτέλεσμα να έχουμε την δυνατότητα να διαλέγουμε εμείς το ordering του πίνακα. |
|
|
|
Αν είναι δηλαδή column-major ή row-major. |
|
|
|
Στην αφαίρεση δημιουργούμε πίνακες στους οποίους τον έλεγχο της μνήμης τον έχουμε εσωτερικά στο αντικείμενο. |
|
|
|
Για την αποθήκευση χρησιμοποιούμε \textbf{std::vector} κάτι που μας δίνει ευελιξία στο μέγεθος αλλά και στη χρήση. |
|
|
|
\par |
|
|
|
Η κύρια όμως λειτουργικότητα που καθιστά την αφαίρεση βολική για την συγκεκριμένη εργασία είναι η δυνατότητα να κατασκευάσουμε αντικείμενα των οποίων η μνήμη είναι και εξωτερικά του αντικειμένου. |
|
|
|
Να λειτουργήσει δηλαδή ο ίδιος ο τύπος ώς viewer, όπως για παράδειγμα το \href{https://en.cppreference.com/w/cpp/header/string_view}{string view}, χωρίς όμως να χρειάζεται να έχουμε διαφορετικό τύπο για αυτή τη δουλειά. |
|
|
|
Σε αυτή την περίπτωση στο εσωτερικό storage δεν αποθηκεύουμε παρά μόνο μια διεύθυνση στα δεδομένα του άλλου πίνακα. |
|
|
|
Μπορούμε όμως να χρησιμοποιήσουμε όλη την λειτουργικότητα του πίνακα. |
|
|
|
Αυτό μας δίνει τη δυνατότητα να δημιουργούμε αντικείμενα που “βλέπουν” σε ολόκληρους ή και σε \textbf{slices }από πίνακες. |
|
|
|
|
|
|
|
Για παράδειγμα μπορούμε να γράψουμε: |
|
|
|
\begin{verbatim} |
|
|
|
Matrix<double> A(4,5); // Πίνακας 4x5 |
|
|
|
Matrix<double> vA(A, 0, 2, 5); // View στις 2 πρώτες γραμμές του Α |
|
|
|
for (int i=0 ; i<vA.rows() ; ++i) |
|
|
|
for (int j=0 ; j<vA.columns() ; ++j) |
|
|
|
std::cout << A(i, j); |
|
|
|
\end{verbatim} |
|
|
|
|
|
|
|
Στον παραπάνω παράδειγμα ο πίνακας με τα δεδομένα είναι ο \textbf{Α}. |
|
|
|
o \textbf{vA}, είναι ένα \textit{slice} του A, που δείχνει μόνο στις 2 πρώτες γραμμές του Α. |
|
|
|
|
|
|
|
\subsection{knnsearch version 0} |
|
|
|
Για το πρώτο σκέλος της άσκησης είχαμε να παρουσιάσουμε την knnsearch με σειριακό τρόπο. |
|
|
|
Για το σκοπό αυτό υλοποιήσαμε την \textbf{v0::knnsearch}. |
|
|
|
Η συνάρτηση αυτή κάνει χρήση του παραπάνω τύπου (Matrix) και επομένως είναι και ή ίδια template. |
|
|
|
Η λειτουργία της χωρίζεται σε 3 βασικά μέρη: |
|
|
|
\begin{itemize} |
|
|
|
\item Τον υπολογισμό του \textbf{πίνακα αποστάσεων}. |
|
|
|
Εδώ βρίσκεται ο κύριος υπολογιστικός όγκος της συνάρτησης, λόγω του πολλαπλασιασμού πινάκων που απαιτείται. |
|
|
|
Για το λόγο αυτό κάνουμε χρήση της openblas. |
|
|
|
\item Την \textbf{αντιστοίχηση των αποστάσεων} των σημείων \textbf{με τους δείκτες (indexes)} αυτών των αποστάσεων στον αρχικό πίνακα Corpus. |
|
|
|
Εδώ ουσιαστικά \textit{“ζευγαρώνουμε”} τον κάθε δείκτη με τη απόσταση που του αναλογεί σε μια δομή \textbf{std::pair<>}. |
|
|
|
Αυτό το κάνουμε ώστε ταξινομώντας ένα διάνυσμα με τέτοια ζευγάρια ώς προς τη μικρότερη απόσταση, να ταξινομούνται αυτόματα και οι δείκτες. |
|
|
|
Γιαυτό το σκοπό κατασκευάζουμε για κάθε σημείο του Query, ένα διάνυσμα τέτοιων ζευγαριών. |
|
|
|
\item Την \textbf{μερική ταξινόμηση} του παραπάνω διανύσματος. |
|
|
|
Εδώ κάνουμε χρήση του αλγορίθμου quick-select. |
|
|
|
Ουσιαστικά ταξινομούμε μόνο ένα κομμάτι του διανύσματος όσα τα στοιχεία που θέλουμε (τον αριθμό των γειτόνων που ψάχνουμε). |
|
|
|
Ο αλγόριθμος αυτός είναι γραμμικός, περιορίζοντας έτσι λιγάκι τη “χασούρα”. |
|
|
|
Για το σκοπό αυτό χρησιμοποιήσαμε την std::nth\_element(). |
|
|
|
\end{itemize} |
|
|
|
Στην υλοποίησή μας τα Corpus-Query είναι διαφορετικά, κάτι που δεν μας περιορίζει να λύσουμε το πρόβλημα όπου το Corpus == Query φυσικά. |
|
|
|
|
|
|
|
\subsection{knnsearch version 1} |
|
|
|
Για το δεύτερο σκέλος της εργασίας είχαμε να παρουσιάσουμε την knnsearch την οποία θα παραλληλοποιήσουμε. |
|
|
|
Για το σκοπό αυτό υλοποιήσαμε την \textbf{v1::knnsearch}. |
|
|
|
Η αρχική μας προσέγγιση ήταν \textbf{αναδρομική}. |
|
|
|
Ουσιαστικά χωρίζαμε τα Corpus-Queries σε slices και για καθένα από αυτά καλούσαμε ξανά τον εαυτό μας. |
|
|
|
Η αναδρομή τερματιζόταν όταν τα slices ήταν αρκετά μικρά ώστε να τρέξει ο σειριακός αλγόριθμος. |
|
|
|
Για να μην χάνονται όμως γείτονες η knnsearch έπρεπε να τρέχει για όλους τους συνδυασμούς. |
|
|
|
Το κάθε Corpus με τα δύο διαφορετικά Queries και το κάθε Query αντίστοιχα. |
|
|
|
Έπειτα συνενώναμε τα αποτελέσματα. |
|
|
|
Αν και αυτή η προσέγγιση ήταν η ακριβείς μας έδινε όμως τη δυνατότητα να “φτηνύνουμε” τον τρόπο με τον οποίο ενώναμε τα αποτελέσματα. |
|
|
|
Επίσης για την περίπτωση που το Queryήταν ίδιο με το Corpus, μας προσφέρεται η δυνατότητα να αποφύγουμε έναν από τους 4 συνδυασμούς. |
|
|
|
\par |
|
|
|
Η προσέγγιση αυτή, αν και απλή, δεν βολεύει για παραλληλοποίηση, καθώς τα νήματα που πρέπει να δημιουργηθούν βρίσκονται μέσα στην αναδρομή, καθιστώντας δύσχρηστη(όχι αδύνατη) τη χρήση των εργαλείων της cilk και της openMP. |
|
|
|
Ακόμα και το “μέρος” στο οποίο θα έμπαινε η loop-α με τις join για την περίπτωση των pthreads ήταν περίπλοκο. |
|
|
|
Για το σκοπό αυτό \textbf{“ανοίξαμε” την αναδρομή} σε βρόχο επανάληψης. |
|
|
|
Σε αυτή την υλοποίηση τα Corpus-Queries, χωρίζονται σε ένα αριθμό από slices που μας δίνεται από την γραμμή εντολών. |
|
|
|
Για όλα αυτά σε ένα διπλό βρόχο καλούμε την σειριακή knnsearch. |
|
|
|
Ο διπλός βρόχος ουσιαστικά δημιουργεί όλους τους συνδυασμούς των slice από το Corpus με τα slices από το Query. |
|
|
|
Έτσι πάλι δεν χάνουμε γείτονες. |
|
|
|
Τα αποτελέσματα συνενώνονται όπου και κρατούνται οι κοντινότεροι γείτονες. |
|
|
|
Η διαδικασία επιλογής είναι ίδια με τη σειριακή. |
|
|
|
Γίνεται δηλαδή πάλι χρήση της quick-select. |
|
|
|
Για να μειώσουμε την ακρίβεια και εδώ μπορούμε να “φτωχύνουμε” το merge. |
|
|
|
Για το σκοπό αυτό έχουμε ένα όρισμα στη συνάρτηση το οποίο μας κόβει τον αριθμό των κοντινότερων γειτόνων. |
|
|
|
|
|
|
|
\subsection{knnsearch version 1} |
|
|
|
|
|
|
|
Για την παραγωγή των εκτελέσιμων χρησιμοποιήσαμε το προσωπικό μας(μου) laptop. |
|
|
|
Στον κατάλογο με τον πηγαίο κώδικα υπάρχει ότι είναι απαραίτητο για την μεταγλώττιση και εκτέλεση του κώδικα. |
|
|
|
Για τη μεταγλώττιση κάναμε χρήση του image hpcimage που βρίσκεται \href{https://hub.docker.com/r/hoo2/hpcimage}{εδώ}. |
|
|
|
|
|
|
|
\section{Αποτελέσματα} |
|
|
|
|
|
|
|
Παρακάτω παραθέτουμε τα αποτελέσματα των μετρήσεων. |
|
|
|
Για αυτές: |
|
|
|
\begin{itemize} |
|
|
|
\item Εκτελέσαμε την κάθε έκδοση του προγράμματος της v1 για\textbf{ διαφορετικό αριθμό από threads} για δύο διαφορετικούς πίνακες(all-to-all) ώστε να δούμε την συμπεριφορά. |
|
|
|
Τα threads μπορούν να περαστούν από τη γραμμή εντολών. |
|
|
|
\item Εκτελέσαμε την κάθε έκδοση του προγράμματος για δύο διαφορετικούς πίνακες(all-to-all) για \textbf{διαφορετική επιθυμητή ακρίβεια}. |
|
|
|
\end{itemize} |
|
|
|
|
|
|
|
Για αντιπαραβολή παραθέτουμε ότι ότι στο ίδιο μηχάνημα το οποίο πήραμε τις μετρήσεις η knnsearch έκδοση του matlab κάνει: |
|
|
|
\begin{itemize} |
|
|
|
\item sift: \textbf{3.223628 [sec]} |
|
|
|
\item mnist: \textbf{20.634987 [sec]} |
|
|
|
\end{itemize} |
|
|
|
|
|
|
|
Για την έκδοση με την openMP έχουμε: |
|
|
|
{ |
|
|
|
\centering |
|
|
|
\includegraphics[width=\textwidth]{../measurements/OMP_over_threads.png} |
|
|
|
\captionof{figure}{Βελτιστοποίηση από την παραλληλοποίηση [openMP].} |
|
|
|
\label{fig:openMP_th} |
|
|
|
|
|
|
|
|
|
|
|
Για την έκδοση με την Cilk έχουμε: |
|
|
|
\includegraphics[width=\textwidth]{../measurements/CILK_over_threads.png} |
|
|
|
\captionof{figure}{Βελτιστοποίηση από την παραλληλοποίηση [open-cilk].} |
|
|
|
\label{fig:cilk_th} |
|
|
|
|
|
|
|
Για την έκδοση με τα pthreads έχουμε: |
|
|
|
\includegraphics[width=\textwidth]{../measurements/Pthreads_over_threads.png} |
|
|
|
\captionof{figure}{Βελτιστοποίηση από την παραλληλοποίηση [pthreads].} |
|
|
|
\label{fig:pthreads_th} |
|
|
|
|
|
|
|
|
|
|
|
Για την έκδοση με την openMP όσο αλλάζουμε την ακρίβεια έχουμε: |
|
|
|
\includegraphics[width=\textwidth]{../measurements/OMP_over_accuracy.png} |
|
|
|
\captionof{figure}{Βελτιστοποίηση λόγο μειωμένης ακρίβειας [openMP].} |
|
|
|
\label{fig:openMP_acc} |
|
|
|
|
|
|
|
|
|
|
|
Για την έκδοση με την Cilk όσο αλλάζουμε την ακρίβεια έχουμε: |
|
|
|
\includegraphics[width=\textwidth]{../measurements/CILK_over_accuracy.png} |
|
|
|
\captionof{figure}{Βελτιστοποίηση λόγο μειωμένης ακρίβειας [open-cilk].} |
|
|
|
\label{fig:cilk_acc} |
|
|
|
|
|
|
|
Για την έκδοση με τα pthreads όσο αλλάζουμε την ακρίβεια έχουμε: |
|
|
|
\includegraphics[width=\textwidth]{../measurements/Pthreads_over_accuracy.png} |
|
|
|
\captionof{figure}{Βελτιστοποίηση λόγο μειωμένης ακρίβειας [pthreads].} |
|
|
|
\label{fig:pthreads_acc} |
|
|
|
} |
|
|
|
|
|
|
|
\section{Συμπεράσματα} |
|
|
|
|
|
|
|
%\justifying |
|
|
|
|
|
|
|
Απ' ότι βλέπουμε παραπάνω, ενώ ο χρόνος βελτιώνεται καθώς χρησιμοποιούμε παραπάνω threads, αυτό δεν συμβαίνει όταν μειώνουμε την ακρίβεια. |
|
|
|
Τουλάχιστον όχι όσο θα θέλαμε. |
|
|
|
Φυσικά αυτό έχει να κάνει με την υλοποίηση μας, καθώς δεν επιλέξαμε καλή τεχνική συνένωσης. |
|
|
|
Ακόμα φαίνεται ότι ενώ η μέθοδος με τα pthreads αποδίδει καλά, αυτό δεν συμβαίνει και με την cilk και την openmp. |
|
|
|
Αυτό γιατί στην παρούσα υλοποίηση δεν γίνεται σωστή διαχείριση των threads. |
|
|
|
|
|
|
|
|
|
|
|
\end{document} |
