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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,7767a311e01e1cd
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Date: Sun, 22 Oct 2006 14:31:05 +0200
From: Gautier <gautier@fakeaddress.nil>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: GNAT compiler switches and optimization
References: <1161341264.471057.252750@h48g2000cwc.googlegroups.com>
 <9Qb_g.111857$aJ.65708@attbi_s21> <434o04-7g7.ln1@newserver.thecreems.com>
 <4539ce34$1_2@news.bluewin.ch> <nrup04-5hj.ln1@newserver.thecreems.com>
 <453A532F.2070709@obry.net> <9kfq04-sgm.ln1@newserver.thecreems.com>
 <sj3r04-rlv.ln1@newserver.thecreems.com> <OeF_g.1031657$084.91539@attbi_s22>
In-Reply-To: <OeF_g.1031657$084.91539@attbi_s22>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 81.62.180.109
X-Original-NNTP-Posting-Host: 81.62.180.109
Message-ID: <453b649e_4@news.bluewin.ch>
X-Trace: news.bluewin.ch 1161520286 81.62.180.109 (22 Oct 2006 14:31:26 +0200)
Organization: Bluewin AG
Complaints-To: abuse@bluewin.ch
X-Original-NNTP-Posting-Host: 127.0.0.1
Path: 
 g2news2.google.com!news4.google.com!news.glorb.com!wns14feed!worldnet.att.net!164.128.36.58!news.ip-plus.net!newsfeed.ip-plus.net!news.bluewin.ch!not-for-mail
Xref: g2news2.google.com comp.lang.ada:7130
Date: 2006-10-22T14:31:05+02:00
List-Id: <comp.lang.ada>

Jeffrey R. Carter:

> Adding the Sum variable makes an important difference, as others have 
> reported, in my case from 5.82 to 4.38 s. Hoisting the indexing 
> calculation for the result (C) matrix location is a basic optimization, 
> and I would be surprised if it isn't done. The only thing I can think of 
> is that it's a cache issue: that all 3 matrices can't be kept in cache 
> at once. Perhaps compiler writers would be able to make sense of this.

The Sum variable was *removed* by someone at some point of the discussion in 
order to challenge a bit more the Ada compiler's optimizer.
If you replace a good algorithm by a bad one, don't be surprised that the 
program is slow. At some point of bad coding the best code optimizer won't be 
able to help you.
Eventually the optimizer will transform this:
          for R in A'range (2) loop
             C (I, J) := C (I, J) + A (I, R) * B (R, J);
          end loop;
into something like:
          Sum:= C (I, J); -- hopefully a Sum is mapped to a register
          for R in A'range (2) loop
             Sum := Sum + A (I, R) * B (R, J);
          end loop;
          C (I, J):= Sum;
but in that case it probably won't be able to guess that the C(I,J) was zeroed 
before and replace the first line by:
          Sum:= 0.0;
sparing the reading of C(I,J) (must cost much time...).
If you are luckier, the optimizer will do
          Sum:= 0.0;
          for R in A'range (2) loop
             Sum := Sum + A (I, R) * B (R, J);
          end loop;
          C (I, J):= C (I, J) + Sum;
But still, it won't spare the time lost to fill the C matrix with zeros.
If you want to do a benchmark with Fortran, it's really not a good idea to 
begin with "pessimizing" the Ada code.

Cheers

Gautier