[Rtk-users] Difference in rtkfdk (cpu) speed/threading

[Ben Champion]

Hi Simon,

Really appreciate your prompt response!

Indeed, I was not using FFTW. After rebuilding ITK with FFTW, I get 
faster reconstructions, and the time increase between the two commits 
reduces to a little over 2x (See below).

My dataset consists of 344 projections (about 172.0 MB)

Does this sound about right? The CPU utilization still looks a bit like 
a series of spikes for the latter commit (but different than before).

Reconstructing and writing... It took 36.0746 s
FDKConeBeamReconstructionFilter timing:
   Prefilter operations: 2.59479 s
   Ramp filter: 19.3106 s
   Backprojection: 13.8042 s

***versus***

Reconstructing and writing... It took 83.4121 s
FDKConeBeamReconstructionFilter timing:
   Prefilter operations: 2.62535 s
   Ramp filter: 66.5537 s
   Backprojection: 13.8829 s

Thanks again,

Ben



On 20/02/14 06:57, Simon Rit wrote:
> Hi,
> Thank you Ben for the amazing report. I can spot a few things that
> could have gone wrong there but it seems to me that your
> reconstruction is slow both before and after the commit... Two
> potential reasons:
> - you have not activated FFTW in ITK. You should definitely do that,
> the FFT of ITK is (very) slow and probably not multithreaded. You must
> turn on ITK_USE_FFTWD and ITK_USE_FFTWF. Be careful to use a recent
> version of ITK4, I had some issues with the first versions, see
> http://www.itk.org/pipermail/insight-users/2013-April/047562.html
> - you are using a huge dataset.
> If you did not use FFTW, could you try again with FFTW and tell us if
> you still observe a drop in performances? If you had FFTW, can you
> provide the sie of the dataset you used?
> Thanks,
> Simon
>
> On Wed, Feb 19, 2014 at 6:35 PM, Ben Champion
> <benjamin.champion.13 at ucl.ac.uk>  wrote:
>> Hello,
>>
>> First of all, many thanks to the RTK community for this useful toolkit!
>>
>> While experimenting with different versions of the code (I'm a relatively
>> new user), I've encountered large differences in rtkfdk (CPU) reconstruction
>> speed between code versions (a newer version being substantially slower than
>> an older version).
>>
>> To test I ran rtkfdk with "--hardware 'cpu' --verbose" (as well as the
>> required -g, -p, -r and -o flags, but no other flags).
>>
>> Using git-bisect, I narrowed it down to a particular commit. The parent
>> commit runs quite quickly, but the child commit shows nearly 4x
>> reconstruction time, and less-uniform CPU utilization (it looks like a
>> series of spikes).
>>
>> (See below)
>>
>> Looking at the diffs, it seems that in addition to adding the HannY
>> functionality (which should be disabled by default?), there were some
>> changes in this commit related to threading (in
>> code/rtkFFTRampImageFilter.{h,txx}). However, perhaps threading is
>> misleading and the substantial difference consists in changing the FFT Ramp
>> Kernel.
>>
>> I'm currently reading the source to try to understand those changes, but I
>> thought I would post in case someone is able to point me in the right
>> direction. Although these differences are unexpected to me, I doubt that
>> they are unexpected to more experienced users...!
>>
>> Apologies if I've left out any critical information (or if I've provided too
>> much!).
>>
>> Many thanks in advance,
>> Ben
>>
>> ****** Parent Commit ******
>> commit 9df6108ae0293f86b455a2dcd4b35801e4815718
>> Author: Julien Jomier<julien.jomier at kitware.com>
>> Date:   Fri Nov 30 09:30:59 2012 +0100
>>
>>      ENH: Minimum CMake version is 2.8.3
>>
>> ***Partial output***
>>
>> Reconstructing and writing... It took 44.3992 s
>> FDKConeBeamReconstructionFilter timing:
>>    Prefilter operations: 2.67915 s
>>    Ramp filter: 26.3847 s
>>    Backprojection: 13.0447 s
>>
>> ***Screenshot of CPU usage attached:
>> 9df6108ae0293f86b455a2dcd4b35801e4815718.png ***
>>
>> ****** Child Commit ******
>> commit e223a2ed2200bbd7d86966d4eb27319ed589ee00
>> Author: Simon Rit<simon.rit at creatis.insa-lyon.fr>
>> Date:   Wed Dec 5 16:22:47 2012 +0100
>>
>>      First version of Hann windowing in the second direction (perpendicular
>> to the ramp)
>>
>> ***Partial output***
>> Reconstructing and writing... It took 126.911 s
>> FDKConeBeamReconstructionFilter timing:
>>    Prefilter operations: 2.47678 s
>>    Ramp filter: 108.254 s
>>    Backprojection: 13.2973 s
>>
>> ***Screenshot of CPU usage attached:
>> e223a2ed2200bbd7d86966d4eb27319ed589ee00.png***
>>
>>
>>
>> _______________________________________________
>> Rtk-users mailing list
>> Rtk-users at openrtk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users
>>