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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,cf34599caf2fa938
X-Google-Attributes: gid103376,public
From: ka@socrates.hr.att.com (Kenneth Almquist)
Subject: Re: GNAT function calling overhead
Date: 1995/04/07
Message-ID: <D6nA9u.Hq7@nntpa.cb.att.com>#1/1
X-Deja-AN: 100939431
sender: news@nntpa.cb.att.com (Netnews Administration)
references: <3m0nv1$pv2@nef.ens.fr>
organization: AT&T
newsgroups: comp.lang.ada
Date: 1995-04-07T00:00:00+00:00
List-Id: <comp.lang.ada>

(Duncan Sands wants to know why matrix multiplication is slow using:
   type Matrix is array(Positive range <>, Positive range <>) of Float;
   function  "*"(Left : in Matrix; Right : in Matrix) return Matrix;
He observes that he gets about a 20% speedup if he manually inlines the
matrix multiplication and wants to know why the calling overhead is so
high.)

This has little to do with function call overhead per se.  The problem
is that GNAT produces ineffient code for subscripting operations on
Matrix variables when the bounds of the matrix are not known at compile
time.  GNAT does somewhat better when the matrix is not passed as an
argument; hence the performance improvement from inlining.

I hope that GNAT funding will cover a bunch of performance tuning, but
unimplemented features and bug fixing presumably have higher priority
right now.  Of course one of the advantages that GNAT gains from using
the GCC back end is that even if nobody on the GNAT project gets around
to looking at this particular performance problem, somebody from another
project, such as GNU Fortran, might fix it.
				Kenneth Almquist