comp.lang.ada
 help / color / mirror / Atom feed
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: 'size attribute inheritance
Date: 1997/09/08
Date: 1997-09-08T00:00:00+00:00	[thread overview]
Message-ID: <EG7Jn4.Aot@world.std.com> (raw)
In-Reply-To: dewar.873602116@merv


In article <dewar.873602116@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>But just think about a bit, and I think you will see why it is a significant
>extra hit. Consider a loop
>
>   for J in ....
>     S := S + A(J)*B(J);
>   end loop;

Can you please clarify this example?  Which of S, or A's or B's
components are you assuming are, or might be, uninitialized?
And is the subtype constrained or not?

>Now on a typical high performance RISC machine, with a multiply add
>instruction, we are seeing in the loop
>
>two loads -- which can be scheduled if the loop is unrolled
>one fused-multiply-add
>one increment-and-loop operation
>
>Now on many modern RISC machines with super scalar capability, we can
>approach 1 clock to issue all these instructions, and certainly 2 clocks
>is achievable on a number of architectures.
>
>But Bob wants to add two comparison instructions (yes, you need them, 
>because the uninitialized value may look like a Nan or infinity).

I must admit I was thinking about integer operations, not floating
point.  I'm not an expert in floating point.  What will NaN's do in this
case?  Trap?  Or simply proagate through?

>This can easily double the number of instructions in the loop, and on
>some architectures, would triple the number of instructions in the loop.
>
>Note that the requirement for checking that actually is *in* the RM adds
>virtually no overhead to this loop, but Bob's wished for change in the RM
>could double or triple the execution time of this very typical fpt inner
>loop.

Perhaps our philosophical difference is that I'm perfectly happy to have
2X or 3X efficiency hit on *some* operations, so long as I have the
ability to suppress checks when these operations happen to be in an
inner loop (or whatever), and therefore affect the efficiency of the
application in an important way.  I'm perfectly happy to test my code
twice (once with checks on, once with checks off).

Would you be happy with my "wished-for" rules if applied only to
non-floats?

Please don't confuse my position with those who say, "what the heck?
computers are fast, and getting faster, so efficiency doesn't matter
(much)".  Efficiency *does* matter.  It matters a lot.  It matters as
much as correctness.

- Bob




      reply	other threads:[~1997-09-08  0:00 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-08-09  0:00 'size attribute inheritance Carlos Palenzuela
1997-08-10  0:00 ` Robert Dewar
1997-08-11  0:00   ` Ken Garlington
1997-08-11  0:00   ` Matthew Heaney
1997-08-10  0:00 ` Robert A Duff
1997-08-10  0:00 ` Matthew Heaney
1997-08-11  0:00   ` Robert Dewar
1997-08-12  0:00     ` Matthew Heaney
1997-08-13  0:00       ` Ken Garlington
1997-08-13  0:00         ` Matthew Heaney
1997-08-13  0:00       ` Robert A Duff
1997-08-13  0:00         ` Matthew Heaney
1997-08-14  0:00           ` Robert A Duff
1997-08-14  0:00             ` Dale Stanbrough
1997-08-16  0:00           ` Robert Dewar
1997-08-16  0:00             ` Ken Garlington
1997-08-17  0:00               ` Robert A Duff
1997-08-17  0:00               ` Robert Dewar
1997-08-18  0:00                 ` Robert A Duff
     [not found]                   ` <dewar.872433846@merv>
1997-09-03  0:00                     ` Robert A Duff
1997-09-06  0:00                       ` Robert Dewar
1997-09-08  0:00                         ` Robert A Duff [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox