From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Received: by 2002:ad4:5448:: with SMTP id h8mr17793509qvt.23.1585675520173;
        Tue, 31 Mar 2020 10:25:20 -0700 (PDT)
X-Received: by 2002:aca:cf48:: with SMTP id f69mr2629983oig.122.1585675519825;
 Tue, 31 Mar 2020 10:25:19 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Tue, 31 Mar 2020 10:25:19 -0700 (PDT)
In-Reply-To: <6c2c0e35-af07-4169-8be5-464ec7fd0fd5@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: google-groups.googlegroups.com; posting-host=146.5.2.231;
 posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC
NNTP-Posting-Host: 146.5.2.231
References: <6c2c0e35-af07-4169-8be5-464ec7fd0fd5@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <cc95457e-b41c-422f-8972-a108af2204fa@googlegroups.com>
Subject: Re: GNAT vs Matlab - operation on   multidimensional complex matrices
From: Shark8 <onewingedshark@gmail.com>
Injection-Date: Tue, 31 Mar 2020 17:25:20 +0000
Content-Type: text/plain; charset="UTF-8"
Xref: reader01.eternal-september.org comp.lang.ada:58260
Date: 2020-03-31T10:25:19-07:00
List-Id: <comp.lang.ada>

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.