[Rtk-users] Issue report regarding the recorder of Time elapsed

[Guangming Zang]

Hi Simon,
sorry for the mistake, not"the backprojection should take much longer time
than
sart algorithm" , but "the backprojection should take much longer time than
forward projection in sart algorithm".

BTW, how many cores does your computer have?? Mine is 24 cores.
is it can explain the reason why it takes much longer time on my computer
than yours?
Regards
Guangming

*Guangming Zang (Alex)*
*King Abdullah University of Science and Technology(KAUST)*
*University of Chinese Academy of Sciences(UCAS)*




2015-07-27 15:28 GMT+03:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:

> I can try. Forward and back projection have the same algorithmic
> complexity but voxel based backprojection benefits from several
> optimizations in terms of memory management and computations that
> makes it faster. The best is to look at the code for further
> details... although both have far from being optimal. And I did not
> get the sentence "the backprojection should take much longer time than
> sart algorithm." because SART contains a backprojection and other
> steps so SART is obviously longer than the bp alone.
> Your log is strange and I don't see what steps are not timed that
> would take most of the time. I did the same test on my computer and
> here is my result:
>
> OS-SR-466:tmp srit$ rtksimulatedgeometry -n 360 -o geo
> OS-SR-466:tmp srit$ rtkprojectshepploganphantom -g geo -o proj.mha
> --dimension 512
> OS-SR-466:tmp srit$ rtksart  -p . -r proj.mha  -g geo -o SART_SL3.mha
>  -f Joseph -b VoxelBasedBackProjection --newspacing 0.5  --dimension
> 128,128,128  --spacing 1,1,1  --origin -64,-64,-64 -l 0.5 -n 3  --time
> 1
> Recording elapsed time...
> SARTConeBeamReconstructionFilter timing:
>   Extraction of projection sub-stacks: 0.288571 s
>   Multiplication by zero: 0.131672 s
>   Forward projection: 34.3612 s
>   Subtraction: 0.203409 s
>   Multiplication by lambda: 0.146459 s
>   Ray box intersection: 1.30755 s
>   Division: 0.187294 s
>   Multiplication by the gating weights: 0 s
>   Displaced detector: 0.278408 s
>   Back projection: 11.8456 s
>   Volume update: 0 s
> It took...  53.2765 s
>
> Simon
>
> On Mon, Jul 27, 2015 at 10:41 AM, Guangming Zang
> <guangming.zang at kaust.edu.sa> wrote:
> > Hi Simon,
> > Thanks for your reply.
> > would you pls help and explain why backprojection is expected to take
> > shorter time than forward projection?? because i was thinking if no
> caching
> > step, the backprojection should take much longer time than sart
> algorithm.
> > yes, i run rtksart for 2 times once.it took 12xxs, similar to the time
> > consumed of 3 times's sart, which much slower than my own application.
> > BTW, D drive is local disk drive, and 360pro_SL_Vol128_512.mha are 360
> > shapp-logan projections(512*512 resolution each)
> > rtksart  -p . -r 360pro_SL_Vol128_512.mha  -g geometry.xml -o
> > ../Result_SL512/SART_SL3.mha   -f Joseph -b VoxelBasedBackProjection
> > --newspacing 0.5  --dimension 128,128,128  --spacing 1,1,1  --origin
> > -64,-64,-64 -l 0.5 -n 3  --time 1
> >
> > and i will try reader->Update() like what you said.
> > Thanks
> > Guangming
> >
> >
> >
> > Guangming Zang (Alex)
> > King Abdullah University of Science and Technology(KAUST)
> > University of Chinese Academy of Sciences(UCAS)
> >
> >
> >
> >
> > 2015-07-27 8:59 GMT+03:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
> >>
> >> Hi Guangming,
> >> It's not surprising to me that the backprojection is faster than the
> >> forward projection, that's what I expect. If the total time is longer,
> >> that's probably that some individual steps are not included in the total
> >> time. Can you try to add
> >> reader->Update();
> >> before the line
> >>
> >> itk::TimeProbe totalTimeProbe;
> >>
> >> in rtksart.cxx? It may be that all the reading operations are done but
> not
> >> timed in the sart->Update(). Why they are so long, I don't know, is
> your D:
> >> drive a network drive? Do you observe the same behavior if you do
> rtksart 2
> >> times in a row?
> >>
> >> Simon
> >>
> >>
> >>
> >> On Mon, Jul 27, 2015 at 12:30 AM, Guangming Zang
> >> <guangming.zang at kaust.edu.sa> wrote:
> >>>
> >>> Hi RTK community,
> >>> i am using SART algorithm to reconstruct an object.
> >>> But in this new RTK version, the time recording seems a little weird:
> >>>  the total time is 1219.12s , but adding the time cost in different
> >>> stages is not 1291.12 s. especially for "backprojection" part, only
> 16.6051s
> >>> to reconstruct a 128^3 volume ?? even shorter than forward projection
> part.
> >>> BTW, the -f and -b are Joseph and VoxelBasedBackProjection,
> respectively,
> >>> both multi-threading  i think.
> >>> Can anyone tell me what's going on?
> >>> Thanks
> >>> Regards
> >>> Guangming
> >>>
> >>>
> >>> Guangming Zang (Alex)
> >>> King Abdullah University of Science and Technology(KAUST)
> >>> University of Chinese Academy of Sciences(UCAS)
> >>>
> >>>
> >>>
> >>>
> >>> ________________________________
> >>> This message and its contents, including attachments are intended
> solely
> >>> for the original recipient. If you are not the intended recipient or
> have
> >>> received this message in error, please notify me immediately and
> delete this
> >>> message from your computer system. Any unauthorized use or
> distribution is
> >>> prohibited. Please consider the environment before printing this email.
> >>
> >>
> >
> >
> > ________________________________
> > This message and its contents, including attachments are intended solely
> for
> > the original recipient. If you are not the intended recipient or have
> > received this message in error, please notify me immediately and delete
> this
> > message from your computer system. Any unauthorized use or distribution
> is
> > prohibited. Please consider the environment before printing this email.
>

-- 

------------------------------
This message and its contents, including attachments are intended solely 
for the original recipient. If you are not the intended recipient or have 
received this message in error, please notify me immediately and delete 
this message from your computer system. Any unauthorized use or 
distribution is prohibited. Please consider the environment before printing 
this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20150727/8d11208e/attachment-0010.html>