* Performance Ada and C, was Re: Size code Ada and C [not found] ` <dewar.899298949@merv> @ 1998-07-03 0:00 ` Van Snyder 1998-07-03 0:00 ` Performance " Markus Kuhn 0 siblings, 1 reply; 23+ messages in thread From: Van Snyder @ 1998-07-03 0:00 UTC (permalink / raw) In article <dewar.899298949@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes: |> |> But to think there is a significant difference here between C, Ada or |> C++ is I think a delusion. |> Bolek Szymanski (http://www.cs.rpi.edu/szymansk) has noticed substantial performance differences between C and Fortran, and even more substantial differences between C++ and Fortran, at least in plasma particle-in-cell simulation codes. The reason that Fortran is usually faster than C is the reason that Ada ought to be faster: Pointers in Fortran are more disciplined -- no pointer arithmetic, and non-pointer thing-o's must have the TARGET attribute to get a pointer landing on them. Barbara Ryder, from AT&T Bell Labs (I don't know what fragment she's in now, if any) has shown that pointer optimization in C is NP-hard, while pointer optimization in Fortran and Ada is "only" polynomially hard. Only loosely relatedly, Les Hatton of PR-QA in Esher, Surrey, England has noticed that defect densities and lifetime costs of equivalent programs in Fortran, C and Ada are roughly the same, whereas defect densities and lifetime costs of C++ programs are roughly three times as large. One of my colleagues reminded me of a study, for which neither of us could remember the author, that observed that 3 out of 4 C++ projects that are initiated are cancelled before completion. -- What fraction of Americans believe | Van Snyder Wrestling is real and NASA is fake? | vsnyder@math.jpl.nasa.gov ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Performance Ada and C 1998-07-03 0:00 ` Performance Ada and C, was Re: Size code Ada and C Van Snyder @ 1998-07-03 0:00 ` Markus Kuhn 1998-07-03 0:00 ` Robert Dewar 0 siblings, 1 reply; 23+ messages in thread From: Markus Kuhn @ 1998-07-03 0:00 UTC (permalink / raw) Van Snyder wrote: > Bolek Szymanski (http://www.cs.rpi.edu/szymansk) has noticed substantial > performance differences between C and Fortran, and even more substantial > differences between C++ and Fortran, at least in plasma particle-in-cell > simulation codes. The reason that Fortran is usually faster than C is > the reason that Ada ought to be faster: Pointers in Fortran are more > disciplined -- no pointer arithmetic, and non-pointer thing-o's must have > the TARGET attribute to get a pointer landing on them. Barbara Ryder, from > AT&T Bell Labs (I don't know what fragment she's in now, if any) has shown > that pointer optimization in C is NP-hard, while pointer optimization in > Fortran and Ada is "only" polynomially hard. I wonder whether GNAT (using a backend that was originally designed specifically for C) can make much use of this theoretically better optimizeability of Ada. Do you know of any performance comparisons between GNAT and another Ada95 compilers that uses a code generator that was right from the beginning designed for Ada? I recently spent some time optimizing an Ada encryption routine <http://www.cl.cam.ac.uk/~mgk25/download/serpent-ada.tar.gz>, and while the best available C implementation <http://www.cl.cam.ac.uk/ftp/users/rja14/serpent.tar.gz> did 27 Mbit/s, I wasn't able to get with Ada more than 20 Mbit/s on the same processor (Pentium II, 300 MHz) using the same compiler (gnat-3.10p). > One of my colleagues reminded me of a study, for which neither of us > could remember the author, that observed that 3 out of 4 C++ projects > that are initiated are cancelled before completion. Do you know a study that using comparable methodology tries to determine such a number for both C++ and Ada95? Would be very interesting ... Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/> ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Performance Ada and C 1998-07-03 0:00 ` Performance " Markus Kuhn @ 1998-07-03 0:00 ` Robert Dewar 1998-07-03 0:00 ` Markus Kuhn 0 siblings, 1 reply; 23+ messages in thread From: Robert Dewar @ 1998-07-03 0:00 UTC (permalink / raw) Markus says <<I recently spent some time optimizing an Ada encryption routine <http://www.cl.cam.ac.uk/~mgk25/download/serpent-ada.tar.gz>, and while the best available C implementation <http://www.cl.cam.ac.uk/ftp/users/rja14/serpent.tar.gz> did 27 Mbit/s, I wasn't able to get with Ada more than 20 Mbit/s on the same processor (Pentium II, 300 MHz) using the same compiler (gnat-3.10p). >> It is always possible to duplicate the object code of any C code writing in 100% Ada using GNAT. Of course you may have to write at a lower semantic level than you would wish. But if you didn't close the gap, it just means you didn't use the right approach. Most probably you were using some Ada specific feature that you thought was equivalent to the C code when it was not, that is the most common reason for this kind of failure. Of course it is also possible to write inefficient C without being very aware of things. For exanmle, the use of strlen can be horrible compared to the direct reading of the bounds of an array in Ada. So this is not something that is asymmetrical. Whether a C program or an Ada program for the same task is faster or slower depends primarily on the programming style used by the programmer, and only secondarily on the compiler. I am always surprised how often Ada programmers have no idea of the consequences of what they write. By the way the -gnatdg switch in GNAT is a useful tool in this regard. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Performance Ada and C 1998-07-03 0:00 ` Robert Dewar @ 1998-07-03 0:00 ` Markus Kuhn 1998-07-04 0:00 ` ak 1998-07-07 0:00 ` Frank Klemm 0 siblings, 2 replies; 23+ messages in thread From: Markus Kuhn @ 1998-07-03 0:00 UTC (permalink / raw) Robert Dewar wrote: > <<I recently spent some time optimizing an Ada encryption routine > <http://www.cl.cam.ac.uk/~mgk25/download/serpent-ada.tar.gz>, > and while the best available C implementation > <http://www.cl.cam.ac.uk/ftp/users/rja14/serpent.tar.gz> > did 27 Mbit/s, I wasn't able to get with Ada more than > 20 Mbit/s on the same processor (Pentium II, 300 MHz) using > the same compiler (gnat-3.10p). > > It is always possible to duplicate the object code of any C code writing > in 100% Ada using GNAT. Of course you may have to write at a lower semantic > level than you would wish. > > But if you didn't close the gap, it just means you didn't use the right > approach. Most probably you were using some Ada specific feature that you > thought was equivalent to the C code when it was not, that is the most common > reason for this kind of failure. Basically the only difference is that I replaced the macros in the C version by inline functions. Are as far as performance and optimization are concerned, I just think of inlined functions as a sort of macros with type checking, so this should not cause the difference. In this type of encryption algorithm, some functions are called 30 times to fiddle around with 4 registers. In the C version, the functions are replaced by macros and manual loop unrolling is performed. I did the same in Ada, just that I used inline functions instead of macros. The other difference is that while in the C function there are 8 different macros S0 to S7, I have in Ada only a single function S with an integer parameter 0..7 that determines with a few ifs which of S0..S7 is executed. I had hoped (and objdump -S output suggests this) that after inline functions are textually substituted that the optimizer removes the statically unaccessible other if branches. So there would not be any difference to the C version. The time consuming part looks like pragma Inline(S, Tr, Keying); Keying(W, 0, X0, X1, X2, X3); S(0, X0, X1, X2, X3); Tr(X0, X1, X2, X3); Keying(W, 1, X0, X1, X2, X3); S(1, X0, X1, X2, X3); Tr(X0, X1, X2, X3); Keying(W, 2, X0, X1, X2, X3); S(2, X0, X1, X2, X3); Tr(X0, X1, X2, X3); ... Keying(W, 30, X0, X1, X2, X3); S(6, X0, X1, X2, X3); Tr(X0, X1, X2, X3); > I am always surprised how often Ada programmers have no idea of the > consequences of what they write. By the way the -gnatdg switch in GNAT is > a useful tool in this regard. Thanks for the hint! I guess, -gnatdg will be very helpful to get around my uncomfortable feeling that I have with Ada being a language where the compiler silently inserts a lot of code between the lines. However for this purpose, -gnatdg seems to be a dump in a too early stange. Is there also a debugging dump available for the stage where at least some of the architecture independent optimizations (function inlining, unaccessed code removal, common subexpression elimination) have already been done, but where there is still a clear relationship with the source code (e.g., where the variable names are still used where possible). The objdump -S output alone is rather difficult to read. It also seems that -gnatdg does not indicate how and where the variable length arrays that functions can return are handled and deallocated and what compiler generated runtime checks remain, such that I could check myself where there are potential memory leaks lurking. The RM says in H.3.1 that pragma Reviewable code should cause such information to be produced, but I haven't yet found out how the information that is supposed to be produced by pragma Reviewable is made available by gnat. Or is objdump -S all there is at the moment to satisfy RM H.3.1? Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/> ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Performance Ada and C 1998-07-03 0:00 ` Markus Kuhn @ 1998-07-04 0:00 ` ak 1998-07-07 0:00 ` Frank Klemm 1 sibling, 0 replies; 23+ messages in thread From: ak @ 1998-07-04 0:00 UTC (permalink / raw) Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> writes: > > Basically the only difference is that I replaced the macros in the C > version by inline functions. Are as far as performance and optimization > are concerned, I just think of inlined functions as a sort of macros > with type checking, so this should not cause the difference. At least in the C frontend inline functions are not equivalent to macros (in contrary to the documenation). The gcc backend seems to miss several optimizations that it does with C-style macros (mainly CSE). Also the register allocator (on x86) seems to have some problems with inline functions. I assume Gnat has the same problem. egcs-current has a new GCSE pass that might help a bit, but there are still other problems (e.g. if you work with objects gcc is very bad to keep small objects in registers if you use inline functions - it always flushes them at the border of the inline etc.) -Andi P.S.: Is something like the Stepanov Benchmark available for Ada95? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Performance Ada and C 1998-07-03 0:00 ` Markus Kuhn 1998-07-04 0:00 ` ak @ 1998-07-07 0:00 ` Frank Klemm 1998-07-13 0:00 ` Daren Scot Wilson 1 sibling, 1 reply; 23+ messages in thread From: Frank Klemm @ 1998-07-07 0:00 UTC (permalink / raw) On Fri, 03 Jul 1998 21:26:07 +0000, Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> wrote: > >Basically the only difference is that I replaced the macros in the C >version by inline functions. Are as far as performance and optimization >are concerned, I just think of inlined functions as a sort of macros >with type checking, so this should not cause the difference. > Sorry, Markus, but inline functions and macros are very different. Generally speaking, macros are more dangerous but faster. We have a function returning x or y whether a is equal to b or not. int inline fn1(int a, int b, long x, long y) { return a==b ? x : y; } and a macro #define fn2(a,b,c,d) ((a)==(b) ? (x) : (y)) /* brackets, it's only a text substitution */ A function call of fn1 generates the following code: c = fn1(expr1,expr2,expr3,expr4); calc expr4 and store it to a register d1 -- 1 reg in use calc expr3 and store it to a register d2 -- 2 regs in use calc expr2 and store it to a register d3 -- 3 regs in use calc expr1 and comprare it with d3 if equal goto lbl1 store d1 to the accu goto lbl2 lbl1: store d2 to the accu lbl2: store accu to c A macro call of fn2 generates the following code: calc expr2 and store it to a register d3 -- 1 reg in use calc expr1 and comprare it with d3 if equal goto lbl1 calc expr4 and store it to the accu goto lbl2 lbl1: calc expr3 and store it to the accu lbl2: store accu to c Problems of the inline version: * early evaluation of expression => needs more registers or a very heavy optimizer * evaluation of unused parameters (this is guaranteed !!!) Tested with several C/C++-Compilers (Turbo-C++, ZTC++, WC++). Another impressive example is: unsigned inline sl2(int x, unsigned t1, unsigned t2) { return x ? t1 : t2; } #define sl1(x,t1,t2) ((x)?(t1):(t2)) int main(void) { printf("Calling fn1... \n"); printf("%u\n",sl1(1,sleep(1),sleep(100))); printf("Calling fn2... \n"); printf("%u\n",sl2(1,sleep(1),sleep(100))); return 0; } -- Frank Klemm /------\ /-----------------------------------------------------\ | eMail: || pfk@uni-jena.de | home: pfk@schnecke.offl.uni-jena.de | | Tel: || | home: +49 (3641) 390545 | | sMail: || Frank Klemm, Ziegesarstr. 1, D-07747 Jena, Germany | \------/ \-----------------------------------------------------/ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Performance Ada and C 1998-07-07 0:00 ` Frank Klemm @ 1998-07-13 0:00 ` Daren Scot Wilson 0 siblings, 0 replies; 23+ messages in thread From: Daren Scot Wilson @ 1998-07-13 0:00 UTC (permalink / raw) > > Generally speaking, macros are more dangerous but faster. Amazing! And I was trying to speed up and improve some C++ programs by converting macros to inline, along with other improvements, but I could be shooting myself in the foot! -- Daren Scot Wilson Member, ACM darenw@pipeline.com www.newcolor.com --------------------------- "If we aren't supposed to eat animals, why are they made of meat?" -- unknown ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <m3zpf1tyr8.fsf@zaphod.enst.fr>]
[parent not found: <6mtiv0$9j3@gcsin3.geccs.gecm.com>]
[parent not found: <dewar.898962846@merv>]
[parent not found: <6n7jut$al0$1@nnrp1.dejanews.com>]
[parent not found: <6navqt$shc$1@goanna.cs.rmit.edu.au>]
[parent not found: <359A53E2.41C6@lanl.gov>]
[parent not found: <dewar.899334821@merv>]
[parent not found: <6nfp0v$dgl@gcsin3.geccs.gecm.com>]
* Re: Ariane 5 failure (Was: Size code Ada and C) [not found] ` <6nfp0v$dgl@gcsin3.geccs.gecm.com> @ 1998-07-02 0:00 ` Jean-Pierre Rosen 0 siblings, 0 replies; 23+ messages in thread From: Jean-Pierre Rosen @ 1998-07-02 0:00 UTC (permalink / raw) John McCabe a �crit dans le message <6nfp0v$dgl@gcsin3.geccs.gecm.com>... >dewar@merv.cs.nyu.edu (Robert Dewar) wrote: >>... it would be nice to have a clear answer. > >It certainly would. > >>Certainly my impression was that it would have been FAR less harmful >>to simply get the wrong result in this code, than to generate the >>improperly handled exception. > >Given the application and the circumstances, I can't see that it would >really have made any difference in the end. As the information produced >by the SRI was (inappropriately as it turned out) being used to direct >the launcher, the chances are that getting a wrong answer would simply >have resulted in the vehicle being directed in another wrong direction >from which there would likely have been no possible means of recovery. > Not at all ! The information produced by the SRI was *discarded* (since it should not even have been running at that point). However, when it failed, the core dump was directed to the data bus... -- ---------------------------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://perso.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ariane 5 failure (Was: Size code Ada and C) [not found] ` <359A53E2.41C6@lanl.gov> [not found] ` <dewar.899334821@merv> @ 1998-07-03 0:00 ` robin 1998-07-02 0:00 ` William Clodius 1998-07-09 0:00 ` Plenty of unnecessary contraint tests " Frank Klemm 2 siblings, 1 reply; 23+ messages in thread From: robin @ 1998-07-03 0:00 UTC (permalink / raw) William Clodius <wclodius@lanl.gov> writes: >robin wrote: >> <snip> >> It's never a good idea in a real-time system to >> avoid run-time checks. A run-time check on the magnitude >> would have caught the error and would not have caused >> the total failure of Ariane 5. >> <snip> >But an implicit runtime check on the magnitude did catch the error. You're stretching the meaning of run-time check a bit. The report called it an "unchecked conversion". By "run-time check" I mean a specific test in the code. The interrupt was trapped by the OS, which then shut down the SRI computer. > It >was the way the error was handled when caught, by turning off the >computer(s), that caused the Ariane 5 to fail so rapidly. No, it was the unchecked conversion. If the conversion had undergone a magnitude check, the OS would have never shut down the SRI. Any kind of error would cause the SRI computer to shut down. Thus, the programmer should have undertaken every proecaution to ensire that each and every possible cause of an interrupt could not occur. Nevertheless, it was foolosh not to include some fail-safe mechanism to trap any unexpected interrupts. Miss one, and it was sudden death to the mission. > It was not >clear to me that not handling the error in this case would have caused >problems, because the software where the error occurred was intended for >prelaunch (and early launch?) analysis and control and was not clearly >useful for the operation of the system at the time the error occurred >(tens of seconds into launch). >William B. Clodius Phone: (505)-665-9370 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ariane 5 failure (Was: Size code Ada and C) 1998-07-03 0:00 ` robin @ 1998-07-02 0:00 ` William Clodius 0 siblings, 0 replies; 23+ messages in thread From: William Clodius @ 1998-07-02 0:00 UTC (permalink / raw) robin wrote: > <snip> > No, it was the unchecked conversion. If the conversion > had undergone a magnitude check, the OS would have never > shut down the SRI. Any kind of error would cause the > SRI computer to shut down. Thus, the programmer should > have undertaken every proecaution to ensire that each and > every possible cause of an interrupt could not occur. > <snip> Your reasoning might be valid if the programmers were unaware that Ada's default semantics would cause an exception to be thrown and that this would shut down the computer. The papers indicate that programmers did not include an explicit check because they were aware of the semantics and its consequences and made the decision that if the "error" would occur it was cause for shutting down the computer. Quoting the report "To determine the vulnerability of unprotected code, an analysis was performed on every operation which could give rise to an exception, including an Operand Error. In particular, the conversion of floating point values to integers was analysed and operations involving seven variables were at risk of leading to an Operand Error. This led to protection being added to four of the variables, evidence of which appears in the Ada code. However, three of the variables were left unprotected. No reference to justification of this decision was found directly in the source code. Given the large amount of documentation associated with any industrial application, the assumption, although agreed, was essentially obscured, though not deliberately, from any external review. The reason for the three remaining variables, including the one denoting horizontal bias, being unprotected was that further reasoning indicated that they were either physically limited or that there was a large margin of safety, a reasoning which in the case of the variable BH turned out to be faulty. It is important to note that the decision to protect certain variables but not others was taken jointly by project partners at several contractual levels." ... "The specification of the exception-handling mechanism also contributed to the failure. In the event of any kind of exception, the system specification stated that: the failure should be indicated on the databus, the failure context should be stored in an EEPROM memory (which was recovered and read out for Ariane 501), and finally, the SRI processor should be shut down. It was the decision to cease the processor operation which finally proved fatal. Restart is not feasible since attitude is too difficult to re-calculate after a processor shutdown; therefore the Inertial Reference System becomes useless. The reason behind this drastic action lies in the culture within the Ariane programme of only addressing random hardware failures. From this point of view exception - or error - handling mechanisms are designed for a random hardware failure which can quite rationally be handled by a backup system." The assumptions given in the second paragraph were valid for Ariane 4 but not Ariane 5. The resulting turn off of the computer was not required Ada by exception handling, but an explicit decision of the Ariane team driven by the culture of the Ariane team. To emphasize, the team made an explicit decision that any unhandled exception that occurred was evidence of a hardware error and justification for turning off the computer. They examined the code for possible overflows that could trigger such exceptions, found this specific part of the code, and determined that overflows for this quantity were not physically possible and hence indicative (for the Ariane 4) of a hardware failure. They apparently made the decision several times not to handle this specific exception AND wWERE AWARE OF THE CONSEQUENCES OF NOT HANDLING AN EXCEPTION. Even in the absence of a language defined exception handling, their reasoning (culture) likely would have caused them to explicitly insert the check and have it set a flag which would turn off the computer at a lower level. -- William B. Clodius Phone: (505)-665-9370 Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815 PO Box 1663, MS-C323 Group office: (505)-667-5776 Los Alamos, NM 87545 Email: wclodius@lanl.gov ^ permalink raw reply [flat|nested] 23+ messages in thread
* Plenty of unnecessary contraint tests (Was: Size code Ada and C) [not found] ` <359A53E2.41C6@lanl.gov> [not found] ` <dewar.899334821@merv> 1998-07-03 0:00 ` robin @ 1998-07-09 0:00 ` Frank Klemm 1998-07-09 0:00 ` Robert Dewar ` (2 more replies) 2 siblings, 3 replies; 23+ messages in thread From: Frank Klemm @ 1998-07-09 0:00 UTC (permalink / raw) robin wrote: > <snip> > It's never a good idea in a real-time system to > avoid run-time checks. A run-time check on the magnitude > would have caught the error and would not have caused > the total failure of Ariane 5. > <snip> > Ada was designed to make it possible to do range checking. Array index boundary checking is always a good idea, because out-of-boundary write access is a very bad idea. Arithmetic boundary checking is problem depending, it is dangerous on arbitrary set boundaries (i.e. balance of an checking account for non commercian usage: range -99_999.99 .. 999_999.99). So on the security point of view array index checking should be always on. Now another problem. Boundary checks cost CPU time. This CPU time can be minimized. So I tested the behaviour of gnat. The main problem of gnat is, that the compiler do test the ranges of a value every time it needs this value. That's a very time consumpting behaviour. 1. problem: unneccesary tests ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Every variable need an internal boundary attribute to determine possible ranges of a variable to avoid this. ========================================================================= procedure a1 is j : integer range 1..10; s : integer; begin s := 0; for i in 0 .. 9 loop j := i + 1; ... end loop; end a1; ========================================================================== xorl %ecx,%ecx xorl %edx,%edx .align 4 .L5: incl %edx testl %edx,%edx -- perfect nonsense jle .L8 cmpl $10,%edx -- perfect nonsense jle .L6 .L8: call __gnat_raise_constraint_error -- never called at all .align 4 .L6: ... cmpl $9,%edx jle .L5 ========================================================================== Example was generated with -O2, Another example: ========================================================================== ... prim : array (0 .. 1_000_000) of boolean; begin -- Initialisierung for i in prim'range loop prim(i) := true; -- rep stosb or rep stosd is much more efficient end loop; prim(0) := false; prim(1) := false; -- Sieben for i in 0 .. 1_000 loop if prim(i) then -- really unnecessary boundary test siebe: declare k : natural; begin k := 2*i; -- k is > 0 while k <= 1_000_000 loop prim(k) := false; -- index test unneccesary, k *is* k<=1_000_000 k := k + i; -- increment end loop; end siebe; end if; end loop; -- Ausgabe for i in prim'range loop if prim(i) then -- i *is* in range of of prim'range, no test necessary Put_Int(i); Put(" "); end if; end loop; ========================================================================== I tested several examples and found out, that gnat never do such a compile time checking for unneccesary boundray tests. Removing redundant tests results in a speedup of 120% (x2.2) on my computer for some small programs. You can always disable range checking in Ada, but was this the idea of Ada ??? var'cmin is in the following notation the smallest possible value, var'cmax the largest. Possible compile time range: i : integer range a..b; -- i can only be in the range a..b; i := 12; -- i can only be in the range 12..12; j := a + b; -- j can only be in the range a'cmin+b'cmin..a'cmax+b'cmax j := c + 1; -- j can only be in the range c'cmin+1..c'cmax+1 j := nat1 * nat2; -- j can only be in the range a'cmin*b'cmin..a'cmax*b'cmax k := int1 * int2; -- if int1 and int2 can be <0 it's a little bit more difficult for i in arr'range loop -- i can only in arr'range if i < 1000 then .... end fi; -- for .... i must be <1000 j := array[i]; .... -- for .... i must be in array'range if cond then a1; else a2; end fi; .... -- for .... the variable ranges in a1 and a2 must be merged 2. problem: bad assembler code ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * test of var in 0..max It will be tested, that (signed)var < 0 and (signed)var > max, faster is a simple test (unsigned)var > max . Why build one when you can build two for twice the price? * always jump around the exception call Extremly slow on CPUs with no jump prediction or if the jump prediction buffer overflows. -- Frank Klemm /------\ /-----------------------------------------------------\ | eMail: || pfk@uni-jena.de | home: pfk@schnecke.offl.uni-jena.de | | Tel: || | home: +49 (3641) 390545 | | sMail: || Frank Klemm, Ziegesarstr. 1, D-07747 Jena, Germany | \------/ \-----------------------------------------------------/ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Plenty of unnecessary contraint tests (Was: Size code Ada and C) 1998-07-09 0:00 ` Plenty of unnecessary contraint tests " Frank Klemm @ 1998-07-09 0:00 ` Robert Dewar 1998-07-10 0:00 ` Frank Klemm 1998-07-10 0:00 ` Robert S. White 1998-07-10 0:00 ` Ariane 5 failure " Dale Stanbrough 2 siblings, 1 reply; 23+ messages in thread From: Robert Dewar @ 1998-07-09 0:00 UTC (permalink / raw) Frank said <<Array index boundary checking is always a good idea, because out-of-boundary write access is a very bad idea. >> No, that's wrong. If you are writing certified code in which deactivated code is not permitted, then it may not be feasible to add such checks, and is certainly not desirable. Incidentally, I can't begin to duplicate the assembly output you are getting from GNAT, but probably that is because you are using an obsolete version. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Plenty of unnecessary contraint tests (Was: Size code Ada and C) 1998-07-09 0:00 ` Robert Dewar @ 1998-07-10 0:00 ` Frank Klemm 0 siblings, 0 replies; 23+ messages in thread From: Frank Klemm @ 1998-07-10 0:00 UTC (permalink / raw) On 9 Jul 1998 22:05:37 -0400, Robert Dewar <dewar@merv.cs.nyu.edu> wrote: > >Incidentally, I can't begin to duplicate the assembly output you are >getting from GNAT, but probably that is because you are using an obsolete >version. > It's a new version I got 2 weeks ago from a ftp server referenced by adahome. If there is any newer in the web, inform me and I will test it again. Should I publish the full soures and the ducumented assembler output ? $ cat bin/* lib/*/*/*/gnat1 | strings GCC: (GNU) 2.7.2.1 GNAT Lib v3.10 GNAT Preprocessor Version 1.03 Copyright 1996 Free Software Foundation, Inc. XREF v3.10 c3.10p (970814)XREF v3.10 GNAT Lib v3.10 d3.10p (970814) Note, that I have added some code to prevent the optimizer from removing code. This code was written as ... in the text. Generally speaking a range tracking of every (local) variable is very exhausting, but that's no reason not to do this. Gnat seems to do nothing concerning this topic... -- Frank Klemm /------\ /-----------------------------------------------------\ | eMail: || pfk@uni-jena.de | home: pfk@schnecke.offl.uni-jena.de | | Tel: || | home: +49 (3641) 390545 | | sMail: || Frank Klemm, Ziegesarstr. 1, D-07747 Jena, Germany | \------/ \-----------------------------------------------------/ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Plenty of unnecessary contraint tests (Was: Size code Ada and C) 1998-07-09 0:00 ` Plenty of unnecessary contraint tests " Frank Klemm 1998-07-09 0:00 ` Robert Dewar @ 1998-07-10 0:00 ` Robert S. White 1998-07-10 0:00 ` Ariane 5 failure " Dale Stanbrough 2 siblings, 0 replies; 23+ messages in thread From: Robert S. White @ 1998-07-10 0:00 UTC (permalink / raw) In article <slrn6q9dnh.9o.pfk@schnecke.offl.uni-jena.de>, pfk@schnecke.offl.uni-jena.de says... >You can always disable range checking in Ada, but was this the idea of Ada ??? That is the essence of the point! Yes you can turn off _all_ of the extra checks of Ada if you want to or need to per final delivery requirements. This VIOLATES NOTHING WHATSOEVER! Ada only gives you a transparent non-obtursive capability to leave checks in if you can afford them. If you can't so what - no Ada Thought Police are going to throw you in jail! Test early and at a low level - turn off checks if you have to per the final delivery resource requirements. _____________________________________________________________________ Robert S. White -- An embedded systems software engineer e-mail reply to reverse of ( add .'s ): net mcleodusa shift2 r white ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ariane 5 failure (Was: Size code Ada and C) 1998-07-09 0:00 ` Plenty of unnecessary contraint tests " Frank Klemm 1998-07-09 0:00 ` Robert Dewar 1998-07-10 0:00 ` Robert S. White @ 1998-07-10 0:00 ` Dale Stanbrough 1998-07-10 0:00 ` John McCabe 2 siblings, 1 reply; 23+ messages in thread From: Dale Stanbrough @ 1998-07-10 0:00 UTC (permalink / raw) "You can always disable range checking in Ada, but was this the idea of Ada ???" The idea in Ada is that it gives you _more_ freedom than C. You have the freedom to check or not to check. The only option you have with C is to accept array index overflows, and try and find them in the debugger. Dale ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ariane 5 failure (Was: Size code Ada and C) 1998-07-10 0:00 ` Ariane 5 failure " Dale Stanbrough @ 1998-07-10 0:00 ` John McCabe 1998-07-10 0:00 ` Pat Rogers 1998-07-10 0:00 ` Frank Klemm 0 siblings, 2 replies; 23+ messages in thread From: John McCabe @ 1998-07-10 0:00 UTC (permalink / raw) Dale Stanbrough <dale@goanna.cs.rmit.edu.au> wrote: >"You can always disable range checking in Ada, but was this the idea of >Ada ???" >The idea in Ada is that it gives you _more_ freedom than C. You have the >freedom to check or not to check. >The only option you have with C is to accept array index overflows, and >try and find them in the debugger. And then what? Put in checks manually that you could have done in the first place? As this would be an alternative option, your suggestion being the only option is not quite true. Also you have the freedom in C to put in your own checks. Certainly Ada is easier as it puts them in automatically for you, and will leave them out for you if you ask it to, but I would not agree with the suggestion that this functionality gives you *more freedom* than C. (Not that I think C is better of course :-) -- Best Regards John McCabe ===================================================================== Not necessarily my company or service providers opinions. ===================================================================== ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ariane 5 failure (Was: Size code Ada and C) 1998-07-10 0:00 ` John McCabe @ 1998-07-10 0:00 ` Pat Rogers 1998-07-10 0:00 ` Frank Klemm 1 sibling, 0 replies; 23+ messages in thread From: Pat Rogers @ 1998-07-10 0:00 UTC (permalink / raw) John McCabe wrote in message <6o4is0$ji5@gcsin3.geccs.gecm.com>... <snip> > >Also you have the freedom in C to put in your own checks. Certainly Ada >is easier as it puts them in automatically for you, and will leave them >out for you if you ask it to, but I would not agree with the suggestion >that this functionality gives you *more freedom* than C. > >(Not that I think C is better of course :-) Certainly an advantage for language-defined checks is the potential for optimization that is not possible for hand-coded checks. For example, if we code explicit index checks in some language, say in some C++ class, the compiler cannot remove the check even when a given index value does not violate the bounds (i.e. the index value is static). No problem for an Ada compiler. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ariane 5 failure (Was: Size code Ada and C) 1998-07-10 0:00 ` John McCabe 1998-07-10 0:00 ` Pat Rogers @ 1998-07-10 0:00 ` Frank Klemm 1 sibling, 0 replies; 23+ messages in thread From: Frank Klemm @ 1998-07-10 0:00 UTC (permalink / raw) On 10 Jul 1998 08:20:16 GMT, John McCabe <john@assen.demon.co.uk> wrote: >Dale Stanbrough <dale@goanna.cs.rmit.edu.au> wrote: >>"You can always disable range checking in Ada, but was this the idea of >>Ada ???" > >>The idea in Ada is that it gives you _more_ freedom than C. You have the >>freedom to check or not to check. > >>The only option you have with C is to accept array index overflows, and >>try and find them in the debugger. > >And then what? Put in checks manually that you could have done in the >first place? As this would be an alternative option, your suggestion >being the only option is not quite true. > Manually checks are *NO* checks. For those who can read C: double x[1000]; void sinusize(double *p, size_t len) { while (len--) *p = sin (*p), p++; } main(...) { sinusize(x, sizeof(x)); return 0; } Array address and length are stored independendly, i.e. it is *very* easy to make errors in the range checking. An array must be more than a pointer to enable range checking, C can't do this. -- Frank Klemm /------\ /-----------------------------------------------------\ | eMail: || pfk@uni-jena.de | home: pfk@schnecke.offl.uni-jena.de | | Tel: || | home: +49 (3641) 390545 | | sMail: || Frank Klemm, Ziegesarstr. 1, D-07747 Jena, Germany | \------/ \-----------------------------------------------------/ ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <6n8393$hoi$2@platane.wanadoo.fr>]
[parent not found: <6n84im$79q@gcsin3.geccs.gecm.com>]
[parent not found: <m3u35470ds.fsf@zaphod.enst.fr>]
[parent not found: <6n8b7u$9hm@gcsin3.geccs.gecm.com>]
[parent not found: <m3vhpk5f0d.fsf@zaphod.enst.fr>]
[parent not found: <3597db2d.1017430@news.demon.co.uk>]
[parent not found: <EACHUS.98Jun30173656@spectre.mitre.org>]
* Re: Size code Ada and C [not found] ` <EACHUS.98Jun30173656@spectre.mitre.org> @ 1998-07-03 0:00 ` John McCabe 1998-07-03 0:00 ` Larry Elmore 0 siblings, 1 reply; 23+ messages in thread From: John McCabe @ 1998-07-03 0:00 UTC (permalink / raw) eachus@spectre.mitre.org (Robert I. Eachus) wrote: >(And milliseconds later, shut down the backup as well.) Wasn't it the hot-redundant system that actually shut down first? -- Best Regards John McCabe ===================================================================== Not necessarily my company or service providers opinions. ===================================================================== ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Size code Ada and C 1998-07-03 0:00 ` Size code Ada and C John McCabe @ 1998-07-03 0:00 ` Larry Elmore 1998-07-03 0:00 ` John McCabe 1998-07-07 0:00 ` Robert I. Eachus 0 siblings, 2 replies; 23+ messages in thread From: Larry Elmore @ 1998-07-03 0:00 UTC (permalink / raw) John McCabe wrote in message <6ni669$i6u@gcsin3.geccs.gecm.com>... >eachus@spectre.mitre.org (Robert I. Eachus) wrote: > >>(And milliseconds later, shut down the backup as well.) > >Wasn't it the hot-redundant system that actually shut down first? Yep. SRI1 (the backup) shut down 72 ms before SRI2 (why SRI1 was designated the backup and SRI2 was the primary, I don't know). Larry ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Size code Ada and C 1998-07-03 0:00 ` Larry Elmore @ 1998-07-03 0:00 ` John McCabe 1998-07-07 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 23+ messages in thread From: John McCabe @ 1998-07-03 0:00 UTC (permalink / raw) "Larry Elmore" <ljelmore@montana.campus.mci.net> wrote: >>Wasn't it the hot-redundant system that actually shut down first? >Yep. SRI1 (the backup) shut down 72 ms before SRI2 (why SRI1 was >designated the backup and SRI2 was the primary, I don't know). Typical French e.g. la plume de ma tante => my aunt's pen.:-) (Actually, even SRI is a prime example - Inertial Reference System) -- Best Regards John McCabe ===================================================================== Not necessarily my company or service providers opinions. ===================================================================== ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Size code Ada and C 1998-07-03 0:00 ` Larry Elmore 1998-07-03 0:00 ` John McCabe @ 1998-07-07 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 23+ messages in thread From: Robert I. Eachus @ 1998-07-07 0:00 UTC (permalink / raw) In article <6nik65$2e$1@news.campus.mci.net> "Larry Elmore" <ljelmore@montana.campus.mci.net> writes: > Yep. SRI1 (the backup) shut down 72 ms before SRI2 (why SRI1 was designated > the backup and SRI2 was the primary, I don't know). I don't know either. I just assumed that SRI2 was the backup. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <dewar.899298821@merv>]
* Re: Size code Ada and C [not found] ` <dewar.899298821@merv> @ 1998-07-07 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 23+ messages in thread From: Robert I. Eachus @ 1998-07-07 0:00 UTC (permalink / raw) In article <dewar.899298821@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes: > I am puzzled, I thought the problem derived from a constaint error > that was raised by a fixed point operation ... There was a floating to fixed/integer conversion instruction in hardware, that signaled a fault because the operand was out of range. This could have been handled by a local (Ada) exception handler. However, the decision was made that this situation could only occur (in the Arianne 4) in the case of a hardware failure. So the exception was allowed to propagate to an outermost handler that switched control to the backup and dumped state. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~1998-07-13 0:00 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <35921271.E51E36DF@aonix.fr> [not found] ` <3598358A.73FF35CC@pipeline.com> [not found] ` <dewar.899298949@merv> 1998-07-03 0:00 ` Performance Ada and C, was Re: Size code Ada and C Van Snyder 1998-07-03 0:00 ` Performance " Markus Kuhn 1998-07-03 0:00 ` Robert Dewar 1998-07-03 0:00 ` Markus Kuhn 1998-07-04 0:00 ` ak 1998-07-07 0:00 ` Frank Klemm 1998-07-13 0:00 ` Daren Scot Wilson [not found] ` <m3zpf1tyr8.fsf@zaphod.enst.fr> [not found] ` <6mtiv0$9j3@gcsin3.geccs.gecm.com> [not found] ` <dewar.898962846@merv> [not found] ` <6n7jut$al0$1@nnrp1.dejanews.com> [not found] ` <6navqt$shc$1@goanna.cs.rmit.edu.au> [not found] ` <359A53E2.41C6@lanl.gov> [not found] ` <dewar.899334821@merv> [not found] ` <6nfp0v$dgl@gcsin3.geccs.gecm.com> 1998-07-02 0:00 ` Ariane 5 failure (Was: Size code Ada and C) Jean-Pierre Rosen 1998-07-03 0:00 ` robin 1998-07-02 0:00 ` William Clodius 1998-07-09 0:00 ` Plenty of unnecessary contraint tests " Frank Klemm 1998-07-09 0:00 ` Robert Dewar 1998-07-10 0:00 ` Frank Klemm 1998-07-10 0:00 ` Robert S. White 1998-07-10 0:00 ` Ariane 5 failure " Dale Stanbrough 1998-07-10 0:00 ` John McCabe 1998-07-10 0:00 ` Pat Rogers 1998-07-10 0:00 ` Frank Klemm [not found] ` <6n8393$hoi$2@platane.wanadoo.fr> [not found] ` <6n84im$79q@gcsin3.geccs.gecm.com> [not found] ` <m3u35470ds.fsf@zaphod.enst.fr> [not found] ` <6n8b7u$9hm@gcsin3.geccs.gecm.com> [not found] ` <m3vhpk5f0d.fsf@zaphod.enst.fr> [not found] ` <3597db2d.1017430@news.demon.co.uk> [not found] ` <EACHUS.98Jun30173656@spectre.mitre.org> 1998-07-03 0:00 ` Size code Ada and C John McCabe 1998-07-03 0:00 ` Larry Elmore 1998-07-03 0:00 ` John McCabe 1998-07-07 0:00 ` Robert I. Eachus [not found] ` <dewar.899298821@merv> 1998-07-07 0:00 ` Robert I. Eachus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox