/articles/toma

 To evaluate the performance of the proposed methods, we have selected 9 graphics adapters with varying micro-architectures which were produced by AMD and NVIDIA. Table \ref{table:gpus} summarizes the considered GPUs. 

 These GPUs were assembled into the 3 GPU servers. The newer NVIDIA cards with Maxwell and Pascal architectures were installed in the Supermicro 7047GT based server specified in the table~\ref{table:sys1}. The older NVIDIA cards and all AMD cards were installed in two identical systems based on Supermicro 7046GT platform. The full specification is given in the table~\ref{table:sys2}. Additionally, we have tested how the developed code is performing on Intel Xeon Phi 5110P accelerator. The accelerator was installed in the first platform along with the newer NVIDIA cards.

 

 In this article we are not aiming to precisely characterize the performance of the graphics cards, but rather validate efficiency of the proposed optimizations. For this reason we take a relatively relaxed approach to the performance measurements. In most tests, we use a data set consisting of 2048 projections with dimensions of 2048 by 2048 pixels each. 512 slices with the same dimensions are reconstructed and the median reconstruction time is used to estimate performance. 

 To avoid long code listings we use pseudo-code to describe the algorithms. We adapted an approach mixing the mathematical and \emph{C}-style notation to keep it minimalistic and easy to follow. We mostly adapt \emph{C}  syntaxes for operations, loops, and conditionals. We use $\idiv$ to denote integer division and $\%$ for modulo operation. No floating point division is performed in any of algorithms. The division is always executed on positive integer arguments and produces integer number which is rounded towards zero. The standard  naming scheme for variables is used across all presented algorithms. We group related variables together. The same letter is used to refer all variables of the group and the actual variable is specified using subscript. Furthermore, some algorithms use shared memory to cache the data stored in global or constant memory. In such cases, we keep the variable name, but add superscript indicating the memory domain. For instance, $\shmem{c_s}$ points to the sine of the projection angle stored in the shared memory. $c$ is a group of variables storing the projection constants. $c_s$ refers specifically the sine of the projection angle and the superscript $\shmem{\cdot}$ indicates that the copy in shared memory is accessed. All variables used across algorithms are listed in \tablename~\ref{table:alg_prms}, \ref{table:alg_idxs}, \ref{table:alg_vars}. The superscripts used to indicate memory segment are specified in \tablename~\ref{table:alg_ss}.

 We use $\vdata{\cdot}$ symbol to denote all vector variables, i.e. $float2$, $float4$, etc. Furthermore, all proposed algorithms are capable to reconstruct 1 to 4 slices in parallel. If more than 1 slice is reconstructed, the accumulator and a few other temporary variables use the floating-point vector format to store values for multiple slices. These variables are marked with $\vfloat{\cdot}$. All arithmetic operations in this case are performed in vector form and affect all slices. The vector multiplication is performed element wise as it would be in CUDA and OpenCL. We use the standard \emph{C} notation to refer array indexes and components of the vector variables. The arrays are indexed from 0. For instance $\vx{\vfloat{s}[0]}$ refers to the first component of the accumulator. The assignment between vector variable and scalars are shown using curly braces, like $\vlist{x, y} = \vfloat{s}[0]$. The floating point constants are shown without \emph{C} type specification. However, it is of utmost importance to qualify all floating-point constants as single precision in the \emph{C} code, i.e. using $0.5f$ in place of $0.5$. Otherwise the double-precision arithmetic will be executed severely penalizing performance on majority of consumer-grade GPUs.

 To perform thread synchronization and to access the texture engine, the algorithms rely on a few functions provided by CUDA SDK or defined in the OpenCL specifications. To preserve neutrality of notation, we use abbreviated keywords to reference this functions. This list of used abbreviations along with the corresponding CUDA and OpenCL functions are listed in \tablename~\ref{table:alg_cmd}. Actually, the syntax of OpenCL and CUDA kernels is very closely related. Only a few language keywords are named differently. It should be a trivial task to generate both CUDA and OpenCL kernels based on the provided pseudo-code. 

 We use integer division and modulo operations across the code listings. These operations are very slow on GPUs and actually should be performed as bit mangling operations instead. However, the optimizing compilers will generate proper hardware instructions automatically. So, we are free to use notation which is easier to read. There are a few other cases when the optimization is left to compiler.