[vsipl++] [patch] Scalable SAR benchmark

[Don McCoy]

Jules Bergmann wrote:
> This looks good.  I have several comments below, plus some general
> comments.
>
> Since this code isn't going into the core library, and since this is
> going to be in a flux as we optimize, let's do the following:
>
>  - address the easy comments:
>     - Definitely 1, 5, 8
>     - Perhaps 4, 6, 7
>     - Later: 2, 3, 9.
>
I did 1, 5 and 8.  Also, I converted it to a template class (back to a 
template class, that is) and eliminated the passing of member views.

Ok to check in?



>  - Avoid returning views by value (both for builtin operations, like
>    Fftm, and for user defined functions, like fft_shift, load_view,
>    and ...).
>
>    Do you think the by-value notation is easier to read?  If so, let
>    me know.  I have a partially finished patch for return-block
>    optimization that can make the by-value forms as efficient as
>    by-reference.  However, this would be for builtin operations only,
>    not user defined ones.
>
I blithely followed the matlab code here.  It is easier just in the 
sense that it can be combined into expressions more easily, but passing 
(in, out) and returning 'out' will be almost as good. 


>  - Continue to move intermediate views out of Kernel1 member functions
>    and replace them with Kernel1 member variables.
>
I believe there are no more views to handle this way, specifically 
because the number of columns in the final image is not known until the 
interpolation phase (member nx_).  I have an idea for how to fix this:

If the bits to compute nx_ can be factored out, putting them into a 
separate class (sort of a SAR imaging pre-processor), it would allow the 
remaining views to be member variables, in addition to the last two 
inverse FFT's.  I'll let you know if I run into a problem doing this.  
But if you know a better way...


>  - To avoid confusion, I think it would be better to have Kernel1
>    member functions work directly on member variables, instead of
>    passing them as arguments.
>
>    For example, digital_spotlighting should just use s_filt_ instead
>    of having it passed in as a parameter.
>
I'd debated this.  I think I've changed my mind (and now agree with your 
suggestion).


Thanks for the comments!



-- 
Don McCoy
don (at) CodeSourcery 
(888) 776-0262 / (650) 331-3385, x712

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ssar3.changes
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20061030/412d5edb/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ssar3.diff
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20061030/412d5edb/attachment-0001.ksh>