/articles/toma

 

 There are also two major OpenCL frameworks supporting general-purpose processors. AMD and Intel deliver their own SDKs, but the processors by both vendors are supported in either case. The AMD framework is not capable to run ALU algorithm efficiently without further adaption. A faster reconstruction is possible if the simpler standard algorithm is used instead. Still, it is significantly slower compared to the performance delivered by the Intel SDK running the same OpenCL code on the same hardware. The speed is even faster if Intel is running the ALU variant with advanced caching mode and $h_x$ caching enabled. The best performance is measured in a 4-slice reconstruction mode and with 64x64 regions assigned per thread block. To evaluate performance we compared the reconstruction speed against CPU-version of PyHST~\cite{chilingaryan2011gpu}. It implements multi-thread and cache-aware reconstruction, but does not perform implicit vectorization. Each thread processes a subset of all slices. The compound sinograms for simultaneous reconstruction of several slices are not supported . The performance is summarized in the \tablename~\ref{tbl:cpu_perf}. PyHST outperforms our OpenCL prototype executed in the single-slice mode, but slower if multi-slice reconstruction is performed. The performance of 33~GU/s is measured if a newer server with dual Xeon E5-2680 v.3 is used. Even then the achieved reconstruction speed is inferior to the performance delivered by the slowest of considered GPUs.

 

\begin{threeparttable}

\caption{\label{tbl:cpu_perf} Performance using general-purpose processors}

\centering