HPC/Project1/project_1_maggioni_claudio.tex

\documentclass[unicode,11pt,a4paper,oneside,numbers=endperiod,openany]{scrartcl}

\input{assignment.sty}
\usepackage{float}
\usepackage{subcaption}
\usepackage{graphicx}
\usepackage{tikz}
\usetikzlibrary{decorations.markings}
\usepackage{url}
\hypersetup{pdfborder = {0 0 0}}
\usepackage{xcolor}
\usepackage{multirow}
\usepackage{makecell}
\usepackage{booktabs}
\usepackage{algorithm2e}
\usepackage[nomessages]{fp}

\begin{document}

\setassignment
\setduedate{12.10.2022 (midnight)}

\serieheader{High-Performance Computing Lab}{2022}{Student: Claudio Maggioni}{
    Discussed with: Gianmarco De Vita}{Solution for Project 1}{}
\newline

%\assignmentpolicy
%In this project you will practice memory access optimization,
%performance-oriented programming, and OpenMP parallelizaton on the ICS Cluster.  

\tableofcontents

\section{Explaining Memory Hierarchies \punkte{25}}

\subsection{Memory Hierarchy Parameters of the Cluster}
By invoking \texttt{likwid-topology} for the cache topology and \texttt{free -g}
for the amount of primary memory, the following memory hierarchy parameters are
found:

\begin{center}
\begin{tabular}{llll}
Main memory & 62 GB              \\
L3 cache    & 25 MB per socket   \\
L2 cache    & 256 kB per core    \\
L1 cache    & 32 kB per core    
\end{tabular}
\end{center}

All values are reported using base 2 IEC byte units. The cluster has 2 sockets
and a total of 20 cores (10 per socket). The cache topology diagram reported by
\texttt{likwid-topology -g} is shown in Figure \ref{fig:topo}.

\pagebreak[4]

\begin{figure}[t]
    \begin{center}
       Socket 0:\vspace{0.3cm}
        \begin{tabular}{|l|l|l|l|l|l|l|l|l|l|}
            \hline 0 & 1 & 2 & 3 & 4 & 5 & 6 & 7 & 8 & 9 \\\hline
            32 kB & 32 kB & 32 kB & 32 kB & 32 kB & 32 kB & 32 kB & 32 kB & 32
            kB & 32 kB \\\hline
            256 kB & 256 kB & 256 kB & 256 kB & 256 kB & 256 kB & 256 kB & 256
            kB & 256 kB & 256 kB \\\hline
            \multicolumn{10}{|c|}{25 MB} \\\hline
      \end{tabular}\vspace{0.8cm}\\
       Socket 1:\vspace{0.3cm}
       \begin{tabular}{|l|l|l|l|l|l|l|l|l|l|}
            \hline 10 & 11 & 12 & 13 & 14 & 15 & 16 & 17 & 18 & 19 \\\hline
            32 kB & 32 kB & 32 kB & 32 kB & 32 kB & 32 kB & 32 kB & 32 kB & 32
            kB & 32 kB \\\hline
            256 kB & 256 kB & 256 kB & 256 kB & 256 kB & 256 kB & 256 kB & 256
            kB & 256 kB & 256 kB \\\hline
            \multicolumn{10}{|c|}{25 MB} \\\hline
       \end{tabular}
    \end{center}
    \caption{Cache topology diagram as outputted by \texttt{likwid-topology -g}.
    Byte sizes all in IEC units.}
    \label{fig:topo}
\end{figure}

\subsection{Memory Access Pattern of \texttt{membench.c}}

\begin{figure}[t]
\begin{center}
\begin{tikzpicture}
    \tikzset{->-/.style={decoration={
  markings,
  mark=at position .75 with {\arrow{>}}},postaction={decorate}}};

    \draw (0,0) grid (5,1);
    \draw [dashed] (5,0) -- (5.5,0);
    \draw [dashed] (5,1) -- (5.5,1);
    \draw [dashed] (6.5,0) -- (7,0);
    \draw [dashed] (6.5,1) -- (7,1);
    \draw (7,0) grid (12,1);

    \foreach \r in {0,1,...,4}{
        \fill (\r + 0.5,0.5) circle [radius=2pt];
        \draw[->-] (\r-0.5,0.5) to[bend left] (\r+0.5,0.5);
        \draw (\r + 0.5, -0.5) node {$\r$};
    }
    \draw[->-] (4.5,0.5) to[bend left] (5.5,0.5);
    \foreach \r in {7,8,...,11}{
        \fill (\r + 0.5,0.5) circle [radius=2pt];
        \FPeval{l}{round(\r + 128 - 12, 0)}
        \draw[->-] (\r-0.5,0.5) to[bend left] (\r+0.5,0.5);
        \draw (\r + 0.5, -0.5) node {$\l$};
    }
    
    \draw (0,-3) grid (3,-2);
    \draw [dashed] (3,-2) -- (3.5,-2);
    \draw [dashed] (3,-3) -- (3.5,-3);
    \draw [dashed] (4,-2) -- (4.5,-2);
    \draw [dashed] (4,-3) -- (4.5,-3);
    \draw (4.5,-2) -- (7.5,-2);
    \draw (4.5,-3) -- (7.5,-3);
    \foreach \r in {4.5,5.5,...,7.5}{
        \draw (\r,-3) -- (\r,-2);
    }
    \draw [dashed] (7.5,-2) -- (8,-2);
    \draw [dashed] (7.5,-3) -- (8,-3);
    \draw [dashed] (8.5,-2) -- (9,-2);
    \draw [dashed] (8.5,-3) -- (9,-3);
    \draw (9,-3) grid (12,-2);

    \fill (0.5,-2.5) circle [radius=2pt];
    \fill (6,-2.5) circle [radius=2pt];
    \foreach \r in {0,1,2}{
        \draw (\r + 0.5, -3.5) node {$\r$};
    }
    \foreach \r in {9,10,11}{
        \FPeval{l}{round(\r - 12, 0)}
        \draw (\r + 0.5, -3.5) node {\tiny $2^{20}  \l$};
    }
    \draw (5, -3.5) node {\tiny $2^{19} - 1$};
    \draw (6, -3.5) node {\tiny $2^{19}$};
    \draw (7,-3.5) node {\tiny $2^{19} + 1$};
    \draw[->-] (-0.5,-2.5) to[bend left] (0.5,-2.5);
    \draw[->-] (0.5,-2.5) to[bend left] (6,-2.5);
\end{tikzpicture}
\end{center}
    \caption{Memory access patterns of \texttt{membench.c} for \texttt{csize =
    128} and \texttt{stride = 1} (above) and for \texttt{csize = $2^{20}$} and
    \texttt{stride = $2^{19}$} (below)}
    \label{fig:access}
\end{figure}

The benchmark \texttt{membench.c} measures the average time of repeated read and
write overations across a set of indices of a stack-allocated array of 32-bit
signed integers. The indices vary according to the access pattern used, which in
turn is defined by two variables, \texttt{csize} and \texttt{stride}.
\texttt{csize} is an upper bound on the index value, i.e.  (one more of) the
highest index used to access the array in the pattern.  \texttt{stride}
determines the difference between array indexes over access iterations, i.e. a
\texttt{stride} of 1 will access every array index, a \texttt{stride} of 2 will
skip every other index, a \texttt{stride} of 4 will access one index then skip 3
and so on and so forth. The benchmark stops when the index to access is strictly
greater than \texttt{csize - stride}.

Therefore, for \texttt{csize = 128} and \texttt{stride = 1} the array will
access all indexes between 0 and 127 sequentially, and for \texttt{csize =
$2^{20}$} and \texttt{stride = $2^{19}$} the benchmark will access index 0, then
index $2^{19}-1$. The access patterns for these
two configurations are shown visually in Figure \ref{fig:access}.

By running the \texttt{membench.c} both on my personal laptop and on the
cluster, the results shown in Figure \ref{fig:mem} are obtained. \textit{csize}
values are shown as different data series and labeled by byte size and
\textit{stride} values are mapped on the $x$ axis by the byte-equivalent value
as well\footnote{Byte values are a factor of 4 greater than the values used in
the code and in Figure \ref{fig:mem}. This is due to the fact that the array
elements used in the benchmark are 32-bit signed integers, which take up 4 bytes
each.}. For $\texttt{csize = 128} = 512$ bytes and $\texttt{stride = 1} = 4$
bytes the mean access time is $0.124$ nanoseconds, while for $\texttt{csize =
$2^{20}$} = 4$MB and for $\texttt{stride = $2^{19}$} = 2$MB the mean access time
is $1.156$ nanoseconds. The first set of parameters performs well thanks to the
low \textit{stride} value, thus achieving very good space locality and
maximizing cache hits. However, the second set of parameters achieves good
performance as well thanks to the few values accessed with each pass, thus
improving the temporal locality of each address accessed. This observation
applies for the few last data points in each data series of Figure
\ref{fig:mem}, i.e. for \textit{stride} values close to \textit{csize}. 

\subsection{Analyzing Benchmark Results}

\begin{figure}[t]
    \begin{subfigure}{0.5\textwidth}
\includegraphics[width=\textwidth]{generic_macos.pdf}
        \caption{Personal laptop}
        \label{fig:mem:laptop}
    \end{subfigure}
    \begin{subfigure}{0.5\textwidth}
\includegraphics[width=\textwidth]{generic_cluster.pdf}
        \caption{Cluster}
        \label{fig:mem:cluster}
    \end{subfigure}
    \caption{Results of the \texttt{membench.c} benchmark for both my personal
    laptop (in Figure \ref{fig:mem:laptop}) and the cluster (in Figure
    \ref{fig:mem:cluster}).}
    \label{fig:mem}
\end{figure}

The \texttt{membench.c} benchmark results for my personal laptop (Macbook Pro
2018 with a Core i7-8750H CPU) and the cluster are shown in figure
\ref{fig:mem}.

The memory access graph for the cluster's benchmark results shows that temporal
locality is best for small array sizes and for small \texttt{stride} values.
In particular, for array memory sizes of 16MB or lower (\texttt{csize} of $4
\cdot 2^{20}$ or lower) and \texttt{stride} values of 2048 or lower the mean
read+write time is less than 10 nanoseconds. Temporal locality is worst for
large sizes and strides, although the largest values of \texttt{stride} for each
size (like \texttt{csize / 2} and \texttt{csize / 4}) achieve better mean times
for the aformentioned effect of having \textit{stride} values close to
\textit{csize}.

The pattern that can be read from the graphs, especially the one for the
cluster, shows that the \textit{stride} axis is divided in regions showing
memory access time of similar magnitude. The boundary between the first and the
second region is a \textit{stride} value of rougly 2KB, while a \textit{stride}
of 512KB roughly separates the second and the third region. The difference in
performance between regions and the similarity of performance within regions
suggest the threshold stride values are related to changes in the use of the
cache hierarchy. In particular, the first region may characterize regions where
the L1 cache, the fastest non-register memory available, is predominantly used.
Then the second region might overlap with a more intense use of the L2 cache and
likewise between the third region and the L3 cache.
\marginpar[right text]{\color{white}\url{https://youtu.be/JzJlzGaQFoc}}

\section{Optimize Square Matrix-Matrix Multiplication  \punkte{60}}


\begin{figure}[t]
\begin{verbatim}
INPUT: A (n by n), B (n by n), n
OUTPUT: C (n by n)

s := 26 # block dimension

A_row := <matrix A converted in row major form>
C_temp := <empty s by s matrix>

for i := 0 to n by s:
    i_next := min(i + s, n)

    for j := 0 to n by s:
        j_next := min(j + s, n)

        <set all cells in C_temp to 0>

        for k := 0 to n by s:
            k_next := min(k + s, n)

            # Perform naive matrix multiplication, incrementing cells of C_temp
            # with each multiplication result
            naivemm(A_row[i, k][i_next, k_next], B[k, j][k_next, j_next],
                    C_temp[0, 0][i_next - i, j_next - j])
        end for

        C[i, j][i_next, j_next] = C_temp[0, 0][i_next - i, j_next - j]
    end for
end for
\end{verbatim}
    \caption{Pseudocode listing of my blocked matrix multiplication
    implementation. Matrix indices start from 0 (i.e. row $0$ and column $0$
    denotes the top-left-most cell in a matrix). \\ \texttt{M[a, b][c, d]} denotes
    a rectangular region of the matrix $M$ whose top-left-most cell is the cell
    in $M$ at row $a$ and column $b$ and whose bottom-right-most cell is the 
    cell in $M$ at row $c - 1$ and column $d - 1$.}
    \label{fig:algo}
\end{figure}

The file \texttt{matmult/dgemm-blocked.c} contains a C implementation of the
blocked matrix multiplication algorithm presented in the project. A pseudocode
listing of the implementation is provided in Figure \ref{fig:algo}.

In order to achieve a correct and fast execution, my implementation:

\begin{figure}[t]
\begin{center}
\begin{tikzpicture}
    \fill[blue!60!white] (4,0) rectangle (5,-2);
    \fill[blue!40!white] (4,-2) rectangle (5,-4);
    \fill[blue!60!white] (0,-4) rectangle (2,-5);
    \fill[blue!40!white] (2,-4) rectangle (4,-5);
    \fill[green!40!white] (4,-4) rectangle (5,-5);
    \draw[step=1,gray,very thin] (0,0) grid (5,-5);
    \draw[step=2] (0,0) grid (5,-5);
    \draw[step=5] (0,0) grid (5,-5);
\end{tikzpicture}
\end{center}
    \caption{Result of the block division process of a square matrix of size 5
    using a block size of 2. The 2-by-1 and 1-by-2 rectangular remainders are
    shown in blue and the square matrix of remainder size (i.e. 1) is shown in
    green.}
    \label{fig:matrix}
\end{figure}

\begin{itemize}
    \item Handles the edge cases related to the ``remainders'' in the matrix
        block division, i.e. when the division between the size of the matrix
        and the block size yields a remainder. Assuming only squared matrices
        are multiplied through the algorithm (as in the test suite provided) the
        block division could yield rectangular matrix blocks located in the last
        rows and columns of each matrix, and the bottom-right corner of the
        matrix will be contained in a square matrix block of the size of the
        remainder. The result of this process is shown in Figure
        \ref{fig:matrix};
    \item Converts matrix A into row major format. As shown in Figure
        \ref{fig:iter}, by having A in row major format and B in column major
        format, iterations across matrix block in the inner most loop of the
        algorithm (the one calling \textit{naivemm}) cache hits are maximised by
        achieving space locality between the blocks used. This achieved
        approximately an increase of performance of two percentage points in
        terms of CPU utilization (i.e. from a baseline of $4\%$ to $6\%$),
    \item Caches the result of each innermost iteration into a temporary matrix
        of block size before storing it into matrix C. This achieves better
        space locality when \textit{naivemm} needs to store values in matrix C.
        The block size temporary matrix has virtually no stride and thus cache
        hits are maximised. The copy operation is implemented with bulk copy
        \texttt{memcpy} calls. This optimization achieves an extra half of a
        percentage point in terms of CPU utilization (i.e. from the $6\%$
        discussed above to a final $6.5\%$).
\end{itemize}

The chosen matrix block size for running the benchmark on the cluster is:

$$s = 26$$

as shown in the pseudocode. This value has been obtained by running an empirical
binary search on the value using the benchmark as a metric, i.e. by running
\texttt{./run\_matrixmult.sh} several times with different values. For square
blocks (i.e. the worst case) the total size for the matrix $A$ and $B$ sub-block
and the \texttt{C\_temp} temporary matrix block for $C$ is:

$$\mathrm{Bytes} = \mathrm{cellSize} * s^2 * 3 = 8 * 26^2 * 3 = 16224$$

given that a double-precision floating point number, the data type used for
matrix cells in the scope of this project, is 8 bytes long. The obtained total
bytes size is fairly close to the L1 cache size of the processor used in the
cluster ($32\mathrm{Kb} = 32768$ bytes), which is expected given that the
algorithm needs to exploit fast memory as much as possible. The reason the
empirically best value results in a theoretical cache allocation that is only
half of the complete L1 cache size is due to some real-life factors. For example,
cache misses tipically result in aligned page loads which may load unnecessary
data.

A potential way to exploit the different cache levels is to apply the blocked
matrix algorithm iteratively multiple times. For example, OpenBLAS implements
DGEMM by having two levels of matrix blocks to better exploit the L2 and L3
caches found on most processors.

\begin{figure}[t]
\begin{center}
\begin{tikzpicture}
    \node[align=center] at (2.5,0.5) {Matrix A};
    \fill[orange!10!white] (0,0) rectangle (2,-2);
    \fill[orange!25!white] (2,0) rectangle (4,-2);
    \fill[orange!40!white] (4,0) rectangle (5,-2);
    
    \draw[step=1,gray,very thin] (0,0) grid (5,-5);
    \draw[step=2,black,thick] (0,0) grid (5,-5);
    \draw[step=5,black,thick] (0,0) grid (5,-5);
    
    \draw[-to,step=1,red,very thick] (0.5,-0.5) -- (4.5,-0.5); 
    \draw[-to,step=1,red,very thick] (0.5,-1.5) -- (4.5,-1.5); 
    \draw[-to,step=1,red,very thick] (0.5,-2.5) -- (4.5,-2.5); 
    \draw[-to,step=1,red,very thick] (0.5,-3.5) -- (4.5,-3.5); 
    \draw[-to,step=1,red,very thick] (0.5,-4.5) -- (4.5,-4.5); 
    
    \node[align=center] at (8.5,0.5) {Matrix B};
    \fill[orange!10!white] (6,0) rectangle (8,-2);
    \fill[orange!25!white] (6,-2) rectangle (8,-4);
    \fill[orange!40!white] (6,-4) rectangle (8,-5);
    
    \draw[step=1,gray,very thin] (6,0) grid (11,-5);
    \draw[step=2,black,thick] (6,0) grid (11,-5);
    \draw[step=5,black,thick] (6,0) grid (11,-5);
    \draw[black,thick] (11,0) -- (11,-5);

    \draw[-to,step=1,red,very thick] (6.5,-0.5) -- (6.5,-4.5); 
    \draw[-to,step=1,red,very thick] (7.5,-0.5) -- (7.5,-4.5); 
    \draw[-to,step=1,red,very thick] (8.5,-0.5) -- (8.5,-4.5); 
    \draw[-to,step=1,red,very thick] (9.5,-0.5) -- (9.5,-4.5); 
    \draw[-to,step=1,red,very thick] (10.5,-0.5) -- (10.5,-4.5); 
\end{tikzpicture}
\end{center}
    \caption{Inner most loop iteration of the blocked GEMM algorithm across
    matrices A and B. The red lines represent the ``majorness'' of each matrix
    (A is converted by the algorithm in row-major form, while B is given and
    used in column-major form). The shades of orange represent the blocks used
    in each iteration.}
    \label{fig:iter}
\end{figure}

The results of the matrix multiplication benchmark for the naive, blocked, and
BLAS implementations are shown in Figure \ref{fig:bench} as a graph of GFlop/s
over matrix size or in Figure \ref{fig:benchtab} as a table. The blocked
implementation achieves on average 50\% more FLOPS than the naive
implementation thanks to the optimisations in space and temporal cache locality
described. However, the blocked implementation achives less than a tenth of
FLOPS compared to Intel MKL BLAS based one due to the microarchitecture
optimization the latter one is able to exploit.

I was unable to run this benchmark suite on my personal machine due to Intel MKL
installation issues that prevented the code to compile.

\begin{figure}[t]
    \includegraphics[width=\textwidth]{timing.pdf}
    \caption{GFlop/s per matrix size of the matrix multiplication benchmark for the naive,
    blocked, and BLAS implementations. The Y-axis is log-scaled.}
    \label{fig:bench}
\end{figure}

\begin{figure}[t]
\begin{center}
\begin{tabular}{c|cc|cc|cc}
    \toprule
    & \multicolumn{2}{c|}{Naive} & \multicolumn{2}{c|}{Blocked} &
    \multicolumn{2}{c}{BLAS} \\
    \makecell{Size} & \makecell{MFLOPS} &
    \makecell{\% CPU} & \makecell{MFLOPS} &
    \makecell{\% CPU} & \makecell{MFLOPS} &
    \makecell{\% CPU} \\
    \midrule
        31 & 2393.33 & 6.50 & 2112.63 & 5.74 & 23449.20 & 63.72 \\
        32 & 2400.13 & 6.52 & 2187.44 & 5.94 & 28198.90 & 76.63 \\
        96 & 1998.74 & 5.43 & 2325.39 & 6.32 & 32542.30 & 88.43 \\
        97 & 1996.01 & 5.42 & 2322.81 & 6.31 & 29801.30 & 80.98 \\
        127 & 1923.81 & 5.23 & 2330.30 & 6.33 & 28557.80 & 77.60 \\
        128 & 1731.98 & 4.71 & 2282.93 & 6.20 & 32643.30 & 88.70 \\
        129 & 1903.31 & 5.17 & 2334.25 & 6.34 & 31198.20 & 84.78 \\
        191 & 1736.78 & 4.72 & 2345.91 & 6.37 & 32247.30 & 87.63 \\
        192 & 1694.44 & 4.60 & 2345.38 & 6.37 & 32830.60 & 89.21 \\
        229 & 1715.10 & 4.66 & 2351.01 & 6.39 & 34360.90 & 93.37 \\
        255 & 1720.39 & 4.67 & 2335.21 & 6.35 & 33477.70 & 90.97 \\
        256 & 777.65 & 2.11 & 2306.48 & 6.27 & 33473.90 & 90.96 \\
        257 & 1729.27 & 4.70 & 2330.68 & 6.33 & 33686.50 & 91.54 \\
        319 & 1704.80 & 4.63 & 2360.03 & 6.41 & 34335.20 & 93.30 \\
        320 & 1414.84 & 3.84 & 2364.53 & 6.43 & 36438.10 & 99.02 \\
        321 & 1741.30 & 4.73 & 2366.38 & 6.43 & 35433.70 & 96.29 \\
        417 & 1733.00 & 4.71 & 2378.34 & 6.46 & 36133.70 & 98.19 \\
        479 & 1731.17 & 4.70 & 2233.05 & 6.07 & 32951.40 & 89.54 \\
        480 & 1678.77 & 4.56 & 2187.87 & 5.95 & 37260.00 & 101.25 \\
        511 & 1733.60 & 4.71 & 2224.61 & 6.05 & 34128.00 & 92.74 \\
        512 & 782.96 & 2.13 & 2284.85 & 6.21 & 36526.40 & 99.26 \\
        639 & 1714.42 & 4.66 & 2292.78 & 6.23 & 35249.20 & 95.79 \\
        640 & 663.42 & 1.80 & 2264.70 & 6.15 & 36538.70 & 99.29 \\
        767 & 1690.82 & 4.59 & 2324.83 & 6.32 & 35718.50 & 97.06 \\
        768 & 792.04 & 2.15 & 2363.92 & 6.42 & 32116.80 & 87.27 \\
        769 & 1696.95 & 4.61 & 2321.31 & 6.31 & 33033.90 & 89.77 \\
    \bottomrule
\end{tabular}
\end{center}
    \caption{MFlop/s and CPU utlisation per matrix size of the matrix
    multiplication benchmark for the naive, blocked, and BLAS implementations.}
    \label{fig:benchtab}
\end{figure}
\end{document}