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,ad4aec717fd8556e X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: 'size attribute inheritance Date: 1997/09/08 Message-ID: #1/1 X-Deja-AN: 270786918 References: <33ECF679.4B5D@lmco.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-09-08T00:00:00+00:00 List-Id: In article , Robert Dewar 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