%
% PDS homework_1 report
%
% authors:
%   Χρήστος Χουτουρίδης ΑΕΜ 8997
%   cchoutou@ece.auth.gr


\documentclass[a4paper, 11pt]{AUTHReport}

% Document configuration
\AuthorName{Χρήστος Χουτουρίδης}
\AuthorMail{cchoutou@ece.auth.gr}
\AuthorAEM{8997}

%\CoAuthorName{asdf}
%\CoAuthorMail{asdf}
%\CoAuthorAEM{9874}

%\WorkGroup{Ομάδα 3}

\DocTitle{Εργασία 1: knnsearch}
\DocSubTitle{Συστήματα με κοινή μνήμη}
\Department{Τμημα ΗΜΜΥ. Τομεάς Ηλεκτρονικής}
\ClassName{Παράλληλα και Διανεμημένα Συστήματα}

\InstructorName{Νικόλαος Πιτσιάνης}
\InstructorMail{nikos.pitsianis@eng.auth.gr}
\CurrentDate{\today}


\usepackage{capt-of}
\usepackage{enumitem}
\usepackage{tabularx}
\usepackage{array}

\begin{document}

\setlist[itemize]{topsep=0pt, partopsep=0pt, itemsep=3pt, parsep=3pt}

\InsertTitle

%\tableofcontents

\sloppy

\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.
Για το σκοπό αυτό έχουμε ένα όρισμα στη συνάρτηση το οποίο μας κόβει τον αριθμό των κοντινότερων γειτόνων.
Σε αυτή την προσέγγιση υπάρχει ακόμα ένα ουσιαστικότερο όφελος.
Ο χωρισμός σε slices μας δίνει την δυνατότητα να δημιουργήσουμε threads που δεν θα χρειαστεί ποτέ να χρειαστούν κομμάτια μνήμης από άλλα threads.
Αυτό ο διαχωρισμός γίνεται στον έξω βρόχο επανάληψης της knnsearch
\begin{verbatim}
   #pragma omp parallel for
    for (size_t qi = 0; qi < num_slices; ++qi)
        worker_body (corpus_slices, query_slices, idx, dst, qi,
                     num_slices, corpus_slice_size, query_slice_size, k, m);
\end{verbatim}
Για τα το παραπάνω snippet (που είναι και “καρδιά” του αλγόριθμου), ο κάθε worker δουλεύει σε δικό του corpus και query slice και αποθηκεύει τα δεδομένα σε δικό του slice πίσω στους idx και dst.
Με αυτό τον τρόπο δεν χρειαζόμαστε κανέναν συγχρονισμό για τα threads.

\subsection{Μετρήσεις}

Για την παραγωγή των εκτελέσιμων χρησιμοποιήσαμε το προσωπικό μας(μου) laptop.
Στον κατάλογο με τον πηγαίο κώδικα υπάρχει ότι είναι απαραίτητο για την μεταγλώττιση και εκτέλεση του κώδικα.
Για τη μεταγλώττιση κάναμε χρήση του image hpcimage που βρίσκεται \href{https://hub.docker.com/r/hoo2/hpcimage}{εδώ}.
Για την μεταγλώττιση και εκτέλεση μπορεί κάποιος να δώσει τις παρακάτω εντολές στο root κατάλογο “homework\_1”.
\begin{verbatim}
    DOCK="docker run --rm -v <PATH_to_homework_1>:/usr/src/PDS_homework_1 \
         -w /usr/src/PDS_homework_1/ hoo2/hpcimage"
    make -j IMAGE=hoo2/hpcimage v0
    make -j IMAGE=hoo2/hpcimage v1
    make -j IMAGE=hoo2/hpcimage v1_cilk
    make -j IMAGE=hoo2/hpcimage v1_omp
    make -j IMAGE=hoo2/hpcimage v1_pth
    # run pthreads version with 4 slices
    eval $DOCK ./out/knnsearch_v1_pth -c <path to hdf5> /test -k 100 -s 4 -t
\end{verbatim}

\section{Αποτελέσματα}

Παρακάτω παραθέτουμε τα αποτελέσματα των μετρήσεων.
Για αυτές:
\begin{itemize}
    \item Εκτελέσαμε την κάθε έκδοση του προγράμματος της v1 για\textbf{ διαφορετικό αριθμό από threads} για δύο διαφορετικούς πίνακες(all-to-all) ώστε να δούμε την συμπεριφορά.
    Τα threads μπορούν να περαστούν από τη γραμμή εντολών.
    \item Εκτελέσαμε την κάθε έκδοση του προγράμματος για δύο διαφορετικούς πίνακες(all-to-all) για \textbf{διαφορετική επιθυμητή ακρίβεια}.
\end{itemize}

Για αντιπαραβολή παραθέτουμε ότι ότι στο ίδιο μηχάνημα το οποίο πήραμε τις μετρήσεις η knnsearch έκδοση του \textbf{matlab} κάνει:
\begin{itemize}
    \item sift: \textbf{3.223628 [sec]}
    \item mnist: \textbf{20.634987 [sec]}
\end{itemize}

\subsection{Επίδραση των threads - OpenMP}

Για την έκδοση με την openMP, χρησιμοποιώντας διαφορετικό αριθμό threads έχουμε: \\
\includegraphics[width=\textwidth]{../measurements/OMP_over_threads.png}
\captionof{figure}{Βελτιστοποίηση από την παραλληλοποίηση [openMP].}
\label{fig:openMP_th}

\subsection{Επίδραση των threads - openCilk}

Για την έκδοση με την Cilk έχουμε: \\
\includegraphics[width=\textwidth]{../measurements/CILK_over_threads.png}
\captionof{figure}{Βελτιστοποίηση από την παραλληλοποίηση  [open-cilk].}
\label{fig:cilk_th}

\subsection{Επίδραση των threads - pthreads}

Για την έκδοση με τα pthreads έχουμε: \\
\includegraphics[width=\textwidth]{../measurements/Pthreads_over_threads.png}
\captionof{figure}{Βελτιστοποίηση από την παραλληλοποίηση [pthreads].}
\label{fig:pthreads_th}

\subsection{Επίδραση της ακρίβειας - OpenMP}

Για την έκδοση με την openMP όσο αλλάζουμε την ακρίβεια έχουμε: \\
\includegraphics[width=\textwidth]{../measurements/OMP_over_accuracy.png}
\captionof{figure}{Βελτιστοποίηση λόγο μειωμένης ακρίβειας [openMP].}
\label{fig:openMP_acc}

\subsection{Επίδραση της ακρίβειας - openCilk}

Για την έκδοση με την Cilk όσο αλλάζουμε την ακρίβεια έχουμε: \\
\includegraphics[width=\textwidth]{../measurements/CILK_over_accuracy.png}
\captionof{figure}{Βελτιστοποίηση λόγο μειωμένης ακρίβειας [open-cilk].}
\label{fig:cilk_acc}

\subsection{Επίδραση της ακρίβειας - pthreads}

Για την έκδοση με τα pthreads όσο αλλάζουμε την ακρίβεια έχουμε: \\
\includegraphics[width=\textwidth]{../measurements/Pthreads_over_accuracy.png}
\captionof{figure}{Βελτιστοποίηση λόγο μειωμένης ακρίβειας [pthreads].}
\label{fig:pthreads_acc}


\section{Συμπεράσματα}

%\justifying

Απ' ότι βλέπουμε παραπάνω, ενώ ο χρόνος βελτιώνεται καθώς χρησιμοποιούμε παραπάνω threads, αυτό δεν συμβαίνει όταν μειώνουμε την ακρίβεια.
Τουλάχιστον όχι όσο θα θέλαμε.
Φυσικά αυτό έχει να κάνει με την υλοποίηση μας, καθώς δεν επιλέξαμε καλή τεχνική συνένωσης.
Στην υλοποίησή μας δεν έγινε πολύ επιθετική στρατηγική μείωσης της ακρίβειας των αποτελεσμάτων.
Να πούμε επίσης ότι ο συγκεκριμένος αλγόριθμος, λόγο της ουσιαστικά “μη” επικοινωνίας που χρειάζονται τα threads, θα μπορούσε να χρησιμοποιηθεί και σε απομακρυσμένα συστήματα κάνοντας χρήση του MPI.


\end{document}
