Re: GNAT vs Matlab - operation on multidimensional complex matrices

[darek <darek.maksimiuk@gmail.com>]

Thanks for all your posts. At this moment I use the access types to avoid an overhead associated with allocation, and initialization of these arrays (I know that the overhead is small but later on when I move from 4 to 16 real channels every millisecond counts :)). This is a MIMO system so the number of virtual channels depends on the number of Tx's and Rx's.  Now, the data is streamed from the device  at 62Mbs (4 x Tx, 4 x Rx => 16 virtual channels) but in the future the data will arrive at ~ 250Mbs (4 x Tx, 16 x Rx => 64 virtual channels).  For each virtual channel you need to compute 2D complex FFT (so-called range-Doppler surface), and then combine them (digital beamforming).  Lots of number crunching here, and lots of fun ...
 
I will try to decompose the processing chain to handle even and odd channels separately, and try to run the computations in parallel on different CPUs (I never use these capabilities, so I am expecting some issues there). 

Regards,
  Darek



On Tuesday, 31 March 2020 19:25:22 UTC+2, Shark8  wrote:
> On Monday, March 23, 2020 at 5:16:20 PM UTC-6, darek wrote:
> > Hi Everyone, 
> >  I am working on radar signal processing algorithms that use multidimensional complex arrays. 
> 
> Ok then; the following should have convention Fortran IIRC:
> 
> type tCubeReal is array (1..NumChannels, 1..NumAngles, 1..NumRanges) of mReal
>   with Convention => Fortran;
> 
> That doesn't matter much, for a speed-test, but given that you mention RADAR data it's probably best to mention it now, before you frustrate yourself by accidentally mixing up column- and row-major formats.
> 
> > 
> > To my surprise, the performance of some Matlab functions is much better than compiled Ada code. 
> > 
> >    procedure SpeedSumRealCube (NumIteration : Integer; Mtx : in  tCubeReal;  S: out mReal) is
> 
> Don't read from S, it's an OUT parameter, and it's best to treat it that way.
> (I'm not sure that it would get in the way of optimization, but could.)
> 
> >       for k in 1..NumIteration loop
> >          for m  in Mtx'Range(1) loop
> >             for n in   Mtx'Range(2) loop
> >                for p in   Mtx'Range(3) loop
> >                   S := S + Mtx(m, n, p);
> >                end loop;
> >             end loop;
> >          end loop;
> >       end loop;
> 
> The above could be replaced, in Ada2012 with:
> 
> Function Summation( Input : in  tCubeReal ) return Complex is
> Begin
>   Return Result : Complex := (0.0 + i*0.0) do
>     For Element of Input loop
>       Result:= Result + Element;
>     End loop;
>   End return;
> End Summation;
> 
> If you turn it into a generic, you could use it for both Complex and mReal; plus it more accurately mirrors your Matlab code.
> -------------------------------------------------------------------------
> 
> Is there a reason for the access-types?
> If not, I would recommend getting rid of them.
> 
> 
> >
> > 1. Compiled with:  gcc version 9.2.0 (tdm64-1) ( and gnat community edition 2019), with the -O2 optimisation level. 
> > 2. CPU: AMD64 Family 23 Model 24 Stepping 1  CPU0      2300           AMD Ryzen 7 3750H with Radeon Vega Mobile Gfx
> > 3. Win10 64bit 
> > 
> > 
> > The results of the program execution:
> > 
> > Computation time: 0.616710300
> > Computation time per iteration: 6.16710300000000E-04
> > Sum is: 7.68000000000000E+08
> > Complex cube
> > Complex type size is: 128
> > 
> > Computation time: 3.707091000
> > Computation time per iteration: 3.70709100000000E-03
> > Sum is:( 7.68000000000000E+08, 7.68000000000000E+08)
> > 
> > 
> > The executable produced by the gcc provide with the gnat community edition gave very similar results.
> > 
> > More interesting part - the Matlab code.
> > The results of the program execution:
> > 
> > TExe:0.260718, sum real=768000000.000000
> > TExe:0.789778, sum complex= <768000000.000000,768000000.000000> 
> > Complex operations are 3.029242 times slower
> > 
> > 
> > What is wrong with my code? Is it the Ada compiler doing bad job here?
> > It seems that Matlab is performing really well here ...
> 
> IIRC Matlab has a *LOT* of optimization for Complex numbers/operations, but you're right in that these are surprising.