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

[Simon Rit]

No I expect forward projection to be longer than backprojection
although with optimal implementations, it should take about the same
time since they have the same complexity.
I have 4 cores on my laptop. I don't see how it explains it, try to
find out where does SART spend the time.
Simon

On Mon, Jul 27, 2015 at 2:50 PM, Guangming Zang
<guangming.zang at kaust.edu.sa> wrote:
> 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.