* Re: naval systems [not found] ` <20020221205157.05542.00000012@mb-cm.news.cs.com> @ 2002-02-22 12:19 ` David Gillon 2002-02-22 14:55 ` Marin David Condic 2002-02-28 16:33 ` tony gair 0 siblings, 2 replies; 52+ messages in thread From: David Gillon @ 2002-02-22 12:19 UTC (permalink / raw) Andrew Swallow wrote: > ADA, officially, did not have any Input/Output statements. So Chapter 14, Input-Output, of Mil-Std 1815A is a figment of my imagination? > ADA compilers were very large, which made them very slow. Early Ada compilers, maybe (a lot depended on how good a job you did of designing your code). Later ones, definitely not. > The runtime support code > needed more memory than most embedded computers had. Only if you didn't tailor it. And how has the embedded market reacted to this supposed limitation? Gone all out for run-time operating systems..... > ADA is only used where cost and time scales are > unimportant - such as cost plus contracts. Nonsense. Boeing _chose_ to use Ada for it's development of the 777, which had extremely tight schedules and where contracts were risk-sharing, not cost-plus. The FAA couldn't have cared less what language they used, so they gained nothing there, but Boeing saw enough gains in the language to pursue it for its own sake. > ADA is a bureaucrat, the only things that ADA does not double > check are those it triple checks. Pragma Suppress etc..... Ada checking is configurable and quite capable of being turned off entirely. > Hence, ADA is unsafe in any application that requires fast reaction > times like missile guidance systems, airborne radars or nuclear > reactor shut down systems. This would be why it is the language of choice for nuclear reactor safety systems and fly by wire, then? Ada is quite capable of generating precisely the same machine code as C for the identical task, so statements it is inherently slow fly in the face of reality. What it is is markedly more maintainable and inherently safer to code. -- David Gillon ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-22 12:19 ` naval systems David Gillon @ 2002-02-22 14:55 ` Marin David Condic 2002-02-23 5:54 ` David Starner 2002-02-23 19:18 ` John R. Strohm 2002-02-28 16:33 ` tony gair 1 sibling, 2 replies; 52+ messages in thread From: Marin David Condic @ 2002-02-22 14:55 UTC (permalink / raw) "David Gillon" <david.gillon@baesystems.com> wrote in message news:3C763746.CC8B2965@baesystems.com... > > > Andrew Swallow wrote: > > > > ADA compilers were very large, which made them very slow. > > Early Ada compilers, maybe (a lot depended on how good a job you did of > designing your code). Later ones, definitely not. > Try one today. Most are as good or better than C compilers. Both in terms of how fast they can compile code and how fast the code is that they compile. This accusation may have at one time been true, but it is very, very, very badly outdated. > > The runtime support code > > needed more memory than most embedded computers had. > > Only if you didn't tailor it. And how has the embedded market reacted to > this supposed limitation? Gone all out for run-time operating > systems..... > Good point. I've built embedded systems with Ada that had nice, small RTKs that could be cut down to just what you needed and no more. For very tiny computers, you probably couldn't get the whole of Ada into them, but if you made intelligent choices about what you needed, you could get all the way down to *NO* RTK if necessary. And compare that to the massive use of "Real Time" Linux systems for embedded computers that are all the rage. Its a heck of a lot bigger and not deterministic to boot. In many apps, it would be much more efficient to use Ada with an appropriate RTK and maybe some I/O libraries than to try to write C/C++ code running on top of Linux or other popular RTOS's. > > ADA is only used where cost and time scales are > > unimportant - such as cost plus contracts. > > Nonsense. Boeing _chose_ to use Ada for it's development of the 777, > which had extremely tight schedules and where contracts were > risk-sharing, not cost-plus. The FAA couldn't have cared less what > language they used, so they gained nothing there, but Boeing saw enough > gains in the language to pursue it for its own sake. > Absolutely. When I used to work at Pratt & Whitney, we used Ada to develop real time engine controls - a *very* demanding application for real time performance & reliability. We used Ada on the military side of the shop and got to the point where we had metrics demonstrating that we doubled productivity and cut defects by a factor of four. The evidence was so indisputable that the commercial side of the shop adopted Ada and our software development processes. They would not have done that if we didn't *demonstrate* that we had cut costs, reduced defects and met schedules. > > ADA is a bureaucrat, the only things that ADA does not double > > check are those it triple checks. > > Pragma Suppress etc..... Ada checking is configurable and quite capable > of being turned off entirely. > Checking things is a *bad* thing? Software should blithely run off into illegal memory references, illegal instructions, overflows, etc? I suppose we should all devoutly desire to never check anything - and while we're at it throw away all those useless spelling and grammar checkers we attach to word processors? As you observe, the checks can - and frequently are- turned off whenever the performance gets critical. Most of the time, they don't need to be disabled and they help catch problems before things get fielded. Its often good to leave the checks in on speed/size critical apps for initial testing and then take it out once you've caught the problems. > > Hence, ADA is unsafe in any application that requires fast reaction > > times like missile guidance systems, airborne radars or nuclear > > reactor shut down systems. > > This would be why it is the language of choice for nuclear reactor > safety systems and fly by wire, then? Ada is quite capable of generating > precisely the same machine code as C for the identical task, so > statements it is inherently slow fly in the face of reality. What it is > is markedly more maintainable and inherently safer to code. > I built a rocket engine control using a Mil-Std-1750a processor that was slower than molassas in January. I had 64kwords of memory in which to work. I had a 1.024mSec interrupt driving the whole thing with 5mSec, 10mSec and 20mSec outer loops. Failure was absolutely not an option. Not with a billion dollar payload. Missed deadlines would be fatal. The delivery schedule was extremely compressed. We did this control in Ada (With Tasking!!!) and it performed flawlessly. The word "Flawlessly" was not applied just by me - but by our customers. The only reason Ada isn't used more in important, safety critical, high performance real time and embedded systems is because there are too many people out there who firmly believe with every fibre of their existence all of the misinformation, rumor, hearsay, fabrication, slander, fear, uncertainty and doubt that gets circulated about it. It pays to look at the facts. It pays to investigate and experiment with Ada - and I mean it *pays* in the pocketbook. Ada is a technology that when applied properly will result in faster development time, lower costs, fewer defects and higher customer satisfaction. It can't cure all your problems - no technology can. But it *can* do a better job when you understand it and use it properly. It *won't* do a better job for you if you approach it from a negative attitude believing it must fail because that's all you've ever been told. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-22 14:55 ` Marin David Condic @ 2002-02-23 5:54 ` David Starner 2002-02-25 15:05 ` Marin David Condic 2002-02-23 19:18 ` John R. Strohm 1 sibling, 1 reply; 52+ messages in thread From: David Starner @ 2002-02-23 5:54 UTC (permalink / raw) On Fri, 22 Feb 2002 09:55:35 -0500, Marin David Condic wrote: > Try one today. Most are as good or better than C compilers. Both in terms of > how fast they can compile code and how fast the code is that they compile. > This accusation may have at one time been true, but it is very, very, very > badly outdated. Really? At least in a comparison between GNAT and gcc on similar, small pieces of code (< 2000 lines), I've found gcc to be virtually instanteous, whereas GNAT took a number of seconds to process the code. -- David Starner - starner@okstate.edu What we've got is a blue-light special on truth. It's the hottest thing with the youth. -- Information Society, "Peace and Love, Inc." ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-23 5:54 ` David Starner @ 2002-02-25 15:05 ` Marin David Condic 2002-02-26 2:34 ` Larry Kilgallen 2002-02-26 17:44 ` David Starner 0 siblings, 2 replies; 52+ messages in thread From: Marin David Condic @ 2002-02-25 15:05 UTC (permalink / raw) In the days when the first validated Ada compiler was running at speeds that compiled code in the single-digits-of-lines-per-second, you might make compilation speed an issue. But if you're looking at one compiler that takes a half a second and another that takes two seconds for a similar program, is that really something that anyone wants to care about? Besides, I'd suggest that in real applications that typically involve hundereds of source files, Ada is likely to *buy* you time over something like C because it can tell what needs to be recompiled and what doesn't. It works faster by not working at all. :-) In general, I just don't see compilation speed as a big deal these days and Ada is competitively fast when compared to C. More important is the quality of the resultant code (and even this is not a big deal in most applications) and there I think Ada does as well or better than C in producing highly efficient code. Or at least it can - compiler implementations do vary. :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message news:a57ar5$aai1@news.cis.okstate.edu... > > Really? At least in a comparison between GNAT and gcc on similar, small > pieces of code (< 2000 lines), I've found gcc to be virtually > instanteous, whereas GNAT took a number of seconds to process the code. > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-25 15:05 ` Marin David Condic @ 2002-02-26 2:34 ` Larry Kilgallen 2002-02-26 17:44 ` David Starner 1 sibling, 0 replies; 52+ messages in thread From: Larry Kilgallen @ 2002-02-26 2:34 UTC (permalink / raw) In article <a5djrr$m65$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes: > Besides, I'd suggest that in real applications that typically involve > hundereds of source files, Ada is likely to *buy* you time over something > like C because it can tell what needs to be recompiled and what doesn't. It > works faster by not working at all. :-) C compilers do this in conjunction with external tools. On VMS the CC command qualifier /MMS_DEPENDENCIES creates (in addition to any output specified by other qualifiers) an MMS description file suitable for describing the conditions under which this file should be compiled again (based on modification dates of included files as well as the mail file). C compilers are likely not so equal to each other as Ada compilers in this regard, but I think that at decision-points regarding ease of use, comparisons will be made between a particular Ada compiler and a particular C compiler, rather than the field in general. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-25 15:05 ` Marin David Condic 2002-02-26 2:34 ` Larry Kilgallen @ 2002-02-26 17:44 ` David Starner 2002-02-26 19:49 ` Pat Rogers 1 sibling, 1 reply; 52+ messages in thread From: David Starner @ 2002-02-26 17:44 UTC (permalink / raw) On Mon, 25 Feb 2002 10:05:30 -0500, Marin David Condic <dont.bother.mcondic.auntie.spam@[> wrote: > Besides, I'd suggest that in real applications that typically involve > hundereds of source files, Ada is likely to *buy* you time over something > like C because it can tell what needs to be recompiled and what doesn't. It > works faster by not working at all. :-) I don't think it makes much difference when comparing make-driven C code base and gnatmake-driven Ada. You should get the same results either way, except the first is much more work and much more powerful - any sufficently large project will need a makefile, to build docs if for nothing else. > In general, I just don't see compilation speed as a big deal these days and > Ada is competitively fast when compared to C.i But GNAT is noticably slower than gcc, and you can't claim that Ada compilers are as fast as C compilers, and then argue that it doesn't matter when someone pushes the point. Be honest; point out that Ada compilers are fast enough, instead. -- David Starner - starner@okstate.edu What we've got is a blue-light special on truth. It's the hottest thing with the youth. -- Information Society, "Peace and Love, Inc." ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-26 17:44 ` David Starner @ 2002-02-26 19:49 ` Pat Rogers 2002-02-26 19:55 ` Ray Blaak 2002-02-27 0:42 ` David Starner 0 siblings, 2 replies; 52+ messages in thread From: Pat Rogers @ 2002-02-26 19:49 UTC (permalink / raw) "David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message news:a5ghiq$9281@news.cis.okstate.edu... > On Mon, 25 Feb 2002 10:05:30 -0500, Marin David Condic <dont.bother.mcondic.auntie.spam@[> wrote: <snip> > > In general, I just don't see compilation speed as a big deal these days and > > Ada is competitively fast when compared to C. > > But GNAT is noticably slower than gcc, and you can't claim that Ada > compilers are as fast as C compilers, and then argue that it doesn't > matter when someone pushes the point. Be honest; point out that Ada > compilers are fast enough, instead. I don't understand this. GNAT *is* gcc. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-26 19:49 ` Pat Rogers @ 2002-02-26 19:55 ` Ray Blaak 2002-02-26 20:46 ` Pat Rogers 2002-02-26 22:40 ` Pascal Obry 2002-02-27 0:42 ` David Starner 1 sibling, 2 replies; 52+ messages in thread From: Ray Blaak @ 2002-02-26 19:55 UTC (permalink / raw) "Pat Rogers" <progers@classwide.com> writes: > "David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message > news:a5ghiq$9281@news.cis.okstate.edu... > > But GNAT is noticably slower than gcc, and you can't claim that Ada > > compilers are as fast as C compilers, and then argue that it doesn't > > matter when someone pushes the point. Be honest; point out that Ada > > compilers are fast enough, instead. > > I don't understand this. GNAT *is* gcc. Well no. The machinery that reads in Ada sources and performs the static analysis is (often) included in the gcc suite and invokes the common gcc code generation abilities. It is not gcc itself, it is GNAT. If one means gcc to mean the suite of language specific compilers using a common code generation backend, then GNAT is a part of gcc. If one means gcc to mean the C/C++ compiler only, then of course it is not the same -- they compile different languages. At any rate, it should come as no surprise that an Ada compiler is slower than a C compiler -- an Ada compiler is doing far more work, plain and simple. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@telus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-26 19:55 ` Ray Blaak @ 2002-02-26 20:46 ` Pat Rogers 2002-02-26 22:41 ` Ray Blaak 2002-02-27 2:28 ` naval systems David Starner 2002-02-26 22:40 ` Pascal Obry 1 sibling, 2 replies; 52+ messages in thread From: Pat Rogers @ 2002-02-26 20:46 UTC (permalink / raw) "Ray Blaak" <blaak@telus.net> wrote in message news:u3czoxbjm.fsf@telus.net... > "Pat Rogers" <progers@classwide.com> writes: > > "David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message > > news:a5ghiq$9281@news.cis.okstate.edu... > > > But GNAT is noticably slower than gcc, and you can't claim that Ada > > > compilers are as fast as C compilers, and then argue that it doesn't > > > matter when someone pushes the point. Be honest; point out that Ada > > > compilers are fast enough, instead. > > > > I don't understand this. GNAT *is* gcc. > > Well no. The machinery that reads in Ada sources and performs the static > analysis is (often) included in the gcc suite and invokes the common gcc code > generation abilities. > > It is not gcc itself, it is GNAT. > > If one means gcc to mean the suite of language specific compilers using a > common code generation backend, then GNAT is a part of gcc. Of course that is what I mean. Therefore, the stand-alone assertion that "GNAT is noticably slower than gcc" is confusing. Does he mean that the front-end for GNAT is slower than the front-end for C? Does he mean that the end-to-end performance of any Ada compiler is slower than any C compiler, as supported by a comparison of supplying C code and Ada code to gcc? Did this Ada code and C code do the same thing? What switches did he use for both? One can just as easily assert that -- with comparable (not identical) switches and with the code doing the same thing -- most of the time there won't be a significant difference in either compile-time or run-time. Pathological cases in either direction can no doubt be constructed. So what? > If one means gcc to mean the C/C++ compiler only, then of course it is not the > same -- they compile different languages. Clearly. However, that is an obsolete definition, given that GCC is now the "GNU Compiler Collection". ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-26 20:46 ` Pat Rogers @ 2002-02-26 22:41 ` Ray Blaak 2002-02-27 0:02 ` Pat Rogers 2002-02-27 2:28 ` naval systems David Starner 1 sibling, 1 reply; 52+ messages in thread From: Ray Blaak @ 2002-02-26 22:41 UTC (permalink / raw) "Pat Rogers" <progers@classwide.com> writes: > "Ray Blaak" <blaak@telus.net> wrote in message news:u3czoxbjm.fsf@telus.net... > > If one means gcc to mean the suite of language specific compilers using a > > common code generation backend, then GNAT is a part of gcc. > > Of course that is what I mean. Therefore, the stand-alone assertion that > "GNAT is noticably slower than gcc" is confusing. Does he mean that the > front-end for GNAT is slower than the front-end for C? Does he mean that the > end-to-end performance of any Ada compiler is slower than any C compiler, as > supported by a comparison of supplying C code and Ada code to gcc? Did this > Ada code and C code do the same thing? What switches did he use for both? Hmm. I am not sure what was meant by the other poster, but my observation is that an Ada compiler would be inherently slower, almost by definition, since it does fundamentally more work than a C compiler. Even given similar source inputs and compiler settings, there will be more verification happening for the Ada source, and that extra work has a time cost. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@telus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-26 22:41 ` Ray Blaak @ 2002-02-27 0:02 ` Pat Rogers 2002-02-27 5:01 ` David Starner 0 siblings, 1 reply; 52+ messages in thread From: Pat Rogers @ 2002-02-27 0:02 UTC (permalink / raw) "Ray Blaak" <blaak@telus.net> wrote in message news:uzo1vx3w2.fsf@telus.net... > "Pat Rogers" <progers@classwide.com> writes: > > "Ray Blaak" <blaak@telus.net> wrote in message news:u3czoxbjm.fsf@telus.net... > > > If one means gcc to mean the suite of language specific compilers using a > > > common code generation backend, then GNAT is a part of gcc. > > > > Of course that is what I mean. Therefore, the stand-alone assertion that > > "GNAT is noticably slower than gcc" is confusing. Does he mean that the > > front-end for GNAT is slower than the front-end for C? Does he mean that the > > end-to-end performance of any Ada compiler is slower than any C compiler, as > > supported by a comparison of supplying C code and Ada code to gcc? Did this > > Ada code and C code do the same thing? What switches did he use for both? > > Hmm. I am not sure what was meant by the other poster, but my observation is > that an Ada compiler would be inherently slower, almost by definition, since > it does fundamentally more work than a C compiler. Even given similar source > inputs and compiler settings, there will be more verification happening for > the Ada source, and that extra work has a time cost. Then let's look at it this way -- the OP asserted that all Ada compiler are slower than all C compilers, on the evidence garnered from submitting "similar" programs to a single compiler. I'm saying that isn't enough. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-27 0:02 ` Pat Rogers @ 2002-02-27 5:01 ` David Starner 2002-02-27 9:38 ` Jean-Pierre Rosen 2002-02-27 19:48 ` compiler benchmark comparisons (was: naval systems) Wes Groleau 0 siblings, 2 replies; 52+ messages in thread From: David Starner @ 2002-02-27 5:01 UTC (permalink / raw) On Wed, 27 Feb 2002 00:02:49 GMT, Pat Rogers <progers@classwide.com> wrote: > Then let's look at it this way -- the OP asserted that all Ada compiler are > slower than all C compilers, on the evidence garnered from submitting "similar" > programs to a single compiler. I'm saying that isn't enough. The person to whom I was responding claimed that most Ada compilers were as fast as, or faster than most C compilers. I merely pointed out that this wasn't true for a common Ada compiler and the associated C compiler, and expressed skepticism in the general case. I _never_ said anything about all Ada compilers or all C compilers. I have provided test data supporting my conclusion, with programs that for the most part have correspond on a line to line level. If you wish to claim that most Ada compilers compile as fast as, or faster than, most C compilers (in comparable conditions), you're welcome to write your own testcases and run them through your compilers and come back with the results, and I will be interested in hearing the answers. But please stop the fact-free rhetoric. -- David Starner - starner@okstate.edu What we've got is a blue-light special on truth. It's the hottest thing with the youth. -- Information Society, "Peace and Love, Inc." ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-27 5:01 ` David Starner @ 2002-02-27 9:38 ` Jean-Pierre Rosen 2002-02-27 19:48 ` compiler benchmark comparisons (was: naval systems) Wes Groleau 1 sibling, 0 replies; 52+ messages in thread From: Jean-Pierre Rosen @ 2002-02-27 9:38 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 896 bytes --] "David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> a �crit dans le message news: a5hp7k$8q61@news.cis.okstate.edu... > The person to whom I was responding claimed that most Ada compilers were > as fast as, or faster than most C compilers. I merely pointed out that > this wasn't true for a common Ada compiler and the associated C > compiler, and expressed skepticism in the general case. I _never_ said > anything about all Ada compilers or all C compilers. > Everybody is right here. If you just compare compilation time, C is certainly faster. If you consider the time between the first submission to the compiler and when your program is working correctly (which IMHO is what really matters), then I take the bets that Ada is faster! -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons (was: naval systems) 2002-02-27 5:01 ` David Starner 2002-02-27 9:38 ` Jean-Pierre Rosen @ 2002-02-27 19:48 ` Wes Groleau 2002-02-27 21:51 ` Pat Rogers 2002-02-27 23:53 ` Gary Barnes 1 sibling, 2 replies; 52+ messages in thread From: Wes Groleau @ 2002-02-27 19:48 UTC (permalink / raw) It would not surprise me if the _average_ C compiler is faster than the _average_ Ada compiler. The Ada compiler - must generate machine code for constraint checks, elaboration checks, and stack checks - must check for initialization and finalization and the need for exception handlers. - will do a lot more type checking (if the program was not poorly designed) - may do a lot more optimization - and (to exaggerate for effect) the Ada compiler will pedantically examine your syntax and semantics with the proverbial fine-toothed comb and harass you unmercifully for the smallest pecadillo, while the C compiler will happily generate code for almost anything produce by leaning on the keyboard. It would not surprise me, either, if the range of speeds for C compilers in general and for Ada compilers in general is far wider than the average difference. This depends more on the algorithms used for parsing, analyzing, code generation, and optimizing than it does on the language. -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons (was: naval systems) 2002-02-27 19:48 ` compiler benchmark comparisons (was: naval systems) Wes Groleau @ 2002-02-27 21:51 ` Pat Rogers 2002-03-01 2:04 ` David Starner 2002-02-27 23:53 ` Gary Barnes 1 sibling, 1 reply; 52+ messages in thread From: Pat Rogers @ 2002-02-27 21:51 UTC (permalink / raw) "Wes Groleau" <wesgroleau@despammed.com> wrote in message news:3C7D37FD.F67F7067@despammed.com... > > It would not surprise me if the _average_ C compiler > is faster than the _average_ Ada compiler. The Ada > compiler > > - must generate machine code for constraint checks, > elaboration checks, and stack checks > - must check for initialization and finalization > and the need for exception handlers. > - will do a lot more type checking (if the program > was not poorly designed) > - may do a lot more optimization > - and (to exaggerate for effect) the Ada compiler > will pedantically examine your syntax and semantics > with the proverbial fine-toothed comb and harass > you unmercifully for the smallest pecadillo, while > the C compiler will happily generate code for almost > anything produce by leaning on the keyboard. What I'm trying to get to is what the OP thought was inherent in the language, such that compile-time (not total time to produce the executable) would always be different, and by "different", I believe it is clear he meant "slower". Meaningful comparison requires that we have comparable language semantics and comparable compiler behavior (as determined by the switch settings). That means the list of differences you cite above -- good ones in general -- would not be in play for the code in question. I'm not arguing that Ada compilers are faster in the general case, I'm looking for the OP's language-oriented reasons that would apply to any compiler. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons (was: naval systems) 2002-02-27 21:51 ` Pat Rogers @ 2002-03-01 2:04 ` David Starner 2002-03-01 4:06 ` Pat Rogers 0 siblings, 1 reply; 52+ messages in thread From: David Starner @ 2002-03-01 2:04 UTC (permalink / raw) On Wed, 27 Feb 2002 21:51:48 GMT, Pat Rogers <progers@classwide.com> wrote: > What I'm trying to get to is what the OP thought was inherent in the language, How about you stop assuming that you know what I think? -- David Starner - starner@okstate.edu What we've got is a blue-light special on truth. It's the hottest thing with the youth. -- Information Society, "Peace and Love, Inc." ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons (was: naval systems) 2002-03-01 2:04 ` David Starner @ 2002-03-01 4:06 ` Pat Rogers 0 siblings, 0 replies; 52+ messages in thread From: Pat Rogers @ 2002-03-01 4:06 UTC (permalink / raw) "David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message news:a5mnim$9281@news.cis.okstate.edu... > On Wed, 27 Feb 2002 21:51:48 GMT, Pat Rogers <progers@classwide.com> wrote: > > What I'm trying to get to is what the OP thought was inherent in the language, > > How about you stop assuming that you know what I think? That I am assuming I know what you think does not follow from what you quoted. Please address the issues I brought up if you want to continue. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons (was: naval systems) 2002-02-27 19:48 ` compiler benchmark comparisons (was: naval systems) Wes Groleau 2002-02-27 21:51 ` Pat Rogers @ 2002-02-27 23:53 ` Gary Barnes 2002-02-28 2:19 ` Dan Andreatta ` (3 more replies) 1 sibling, 4 replies; 52+ messages in thread From: Gary Barnes @ 2002-02-27 23:53 UTC (permalink / raw) Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3C7D37FD.F67F7067@despammed.com>... > It would not surprise me if the _average_ C compiler > is faster than the _average_ Ada compiler. The Ada > compiler > > - must generate machine code for constraint checks, > elaboration checks, and stack checks Most compilers are limited by the I/O speed of the machine rather than by what they have to do to compile the language or by the machine code they have to generate. In the case of a C module, the compiler has to open/read/close numerous .h files. The number of .h files that are read simply by doing an include on something "simple" like stdio.h can be amazing on some systems; measuring in the dozens, on others it may be a handful. In the case of an Ada module, the compiler has to open/read/close some number of files (GNU => every spec in the WITH closure of the module, Rational => every directly WITH'ed spec of the module). The number varies depending on the compiler. This is the reason that C compiler for older "slow" machines, such as the Amiga or the M68000 had options for creating pre-digested collections of .h files. It reduced the number of opens and reads and greatly increased the perceived performance of the compiler. If you strip away the open/read times for the source code, and the open/write times for the output, there isn't a great deal of reason for an optimizing C compiler and and optimizing Ada compiler to be greatly different in the time they take for comparable source code. The open/write time will be dominated by the open. If "average" compilation times for Ada compilers is larger than that for "average" C compilers, it more likely because Ada compiler writers spend a great deal of time worrying about "correct" and less time worrying about "fast". As a conjecture, the average Ada compiler also tends to have a "large" number of targets (for cross compilation) whereas the average C compiler may not (GCC is a noted exception!). As a user of both GCC and GNAT, they seem to be comparably fast. That is strictly a "How long do I seem to have to wait and do I get impatient." comparison. Also, as a user of both Rational Apex Ada and the C compilers from many Unix vendors, Rational's Ada would seem to compile similar numbers of units per unit of time. At least, I don't get any more impatient compiling a mound of Ada than I do a mound of C. If anything, compiling a large Ada program seems to be faster; which is again a seat-of-the-pants impression rather than formal results of some sort of benchmark. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons (was: naval systems) 2002-02-27 23:53 ` Gary Barnes @ 2002-02-28 2:19 ` Dan Andreatta 2002-02-28 10:04 ` Jerry van Dijk ` (3 more replies) 2002-02-28 14:01 ` Wes Groleau ` (2 subsequent siblings) 3 siblings, 4 replies; 52+ messages in thread From: Dan Andreatta @ 2002-02-28 2:19 UTC (permalink / raw) OK, just to be into this benchmarck craze, I did a few tests w/ gcc and family. These are the results, using GCC 2.95 (mingw) and gnat 3.13p on a PII 666MHz w/ NT 4.0: GNAT 11.0 sec g77 4.0 gcc 1.4 g++ 3.3 obj-c 2.6 (writing a "cout" class) gcc 2.8 1.0 (gnat gcc) gpc 2.8 1.1 The programs are 1000 loops like: for i in 1..100 loop ada.text_io.put_line( Integer'Image(i) ); end loop; for i in 1..100 loop ada.text_io.put_line( Integer'Image(i) ); end loop; .... or for (int i=0; i<100; ++i) cout << i << endl; and so on... OK, GNAT is slower... and so? Anybody cares? Daniele Andreatta ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons (was: naval systems) 2002-02-28 2:19 ` Dan Andreatta @ 2002-02-28 10:04 ` Jerry van Dijk 2002-02-28 13:35 ` compiler benchmark comparisons Georg Bauhaus ` (2 subsequent siblings) 3 siblings, 0 replies; 52+ messages in thread From: Jerry van Dijk @ 2002-02-28 10:04 UTC (permalink / raw) > and so on... > OK, GNAT is slower... and so? Anybody cares? Well, I checked all my sources carefully, and none of them write out a million integers in a tight loop, so no, I do not care. Benchmarking compilers is very useful but also very difficult to do right, especially if you want to compare different languages with different compilers. To get an idea you can find on my homepage a package that contains a number of small "standard" benchmarks such as dhrystone, whetstone, etc. in both their C and Ada incarnations. Notice here the attempt to make sure that the compiler switches for the different languages are as equivalent as possible. -- -- Jerry van Dijk | email: jvandyk@attglobal.net -- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons 2002-02-28 2:19 ` Dan Andreatta 2002-02-28 10:04 ` Jerry van Dijk @ 2002-02-28 13:35 ` Georg Bauhaus 2002-02-28 18:12 ` Dan Andreatta 2002-02-28 14:18 ` compiler benchmark comparisons (was: naval systems) Wes Groleau 2002-02-28 14:31 ` Ted Dennison 3 siblings, 1 reply; 52+ messages in thread From: Georg Bauhaus @ 2002-02-28 13:35 UTC (permalink / raw) Dan Andreatta <andreatta@mail.chem.sc.edu> wrote: I'm not sure whether I understand this comment. Is it about runtime performance of generated code using some specific library functions? I thought this was about the time it takes to compile a program? (Incidentally, a similar test revealed that GNAT produced x86 fpt code is surprinsingly fast, when tested against similar attempts in C using the same backend. ) : ada.text_io.put_line( Integer'Image(i) ); : cout << i << endl; ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons 2002-02-28 13:35 ` compiler benchmark comparisons Georg Bauhaus @ 2002-02-28 18:12 ` Dan Andreatta 2002-03-01 5:07 ` Robert Dewar 0 siblings, 1 reply; 52+ messages in thread From: Dan Andreatta @ 2002-02-28 18:12 UTC (permalink / raw) Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<a5lbnd$jsn$6@a1-hrz.uni-duisburg.de>... > Dan Andreatta <andreatta@mail.chem.sc.edu> wrote: > > I'm not sure whether I understand this comment. > Is it about runtime performance of generated code > using some specific library functions? I thought this was > about the time it takes to compile a program? Compile time, indeed. Yesterday I was running late, and missed some explanations. I took the idea from the other thread, where this issue was introduced. There a guy tried with random gotos, but it is easier and faster to build a program with repeated blocks. The times reported are without switches. I tried also some combination of options, such as -gnatp, but the time was almost identical. The main change in timing was due to optimizations. In that case, with -O2, the gap between Ada and the rest widens, yelding these times to compile the same code: GNAT 250 sec g77 13 gcc 5 The run times were around 0.2 sec for gcc and 0.5 sec for GNAT (dumping the output). Dan ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons 2002-02-28 18:12 ` Dan Andreatta @ 2002-03-01 5:07 ` Robert Dewar 2002-03-01 16:43 ` Dan Andreatta 2002-03-01 23:17 ` Dan Andreatta 0 siblings, 2 replies; 52+ messages in thread From: Robert Dewar @ 2002-03-01 5:07 UTC (permalink / raw) andreatta@mail.chem.sc.edu (Dan Andreatta) wrote in message news:<338040f8.0202281012.31593a2@posting.google.com>... > In that case, with -O2, the gap between Ada and the rest > widens, yelding these times to > compile the same code: > > GNAT 250 sec > g77 13 > gcc 5 > > The run times were around 0.2 sec for gcc and 0.5 sec for > GNAT (dumping the output). First of all I think you mean gnu-c here (or you can just say c in this context if you like), gcc is the GNU compiler collection, and includes all three of these languages as well as many others. Second, if the gnu-c code runs 2-3 times as fast as the C code it is simply NOT the same code. Usually when we look at examples like this in detail, we discover that what people think are "identical" programs are in fact totally different and apples and oranges are being compared (*) An odd phrase, what's so wrong about comparing oranges on apples. I think I prefer oranges in general :-) : ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons 2002-03-01 5:07 ` Robert Dewar @ 2002-03-01 16:43 ` Dan Andreatta 2002-03-01 23:17 ` Dan Andreatta 1 sibling, 0 replies; 52+ messages in thread From: Dan Andreatta @ 2002-03-01 16:43 UTC (permalink / raw) > First of all I think you mean gnu-c here (or you can just Yes. My apologies. > Second, if the gnu-c code runs 2-3 times as fast as the > C code it is simply NOT the same code. Yes and no. In this particular example the execution time is determined mainly by performance of the I/O library. And the GNU/Ada I/O library is slower than the GNU/C library. For fun I wrote some of the "shootout" programs in Ada and the result was that the execution times were comparable, except the ones that used heavily text I/O, where the Ada times were 2-3 times higher. I admit I am a newby, so my code was not so good, but, as I said, where the I/O wasn't the main part of the program, I wrote pretty fast code. > examples like this in detail, we discover that what > people think are "identical" programs are in fact totally Well, the core of the code was a repeated series of for loops: for i in 1..100 loop ada.text_io.put_line( Integer'Image(i) ) end loop; for Ada and for C: for (i=0; i<100 : ++i) printf("%d\n",i); What are the differences between the two? BTW, the test was ment to test the compiler speed, not the quality of the produced code. Maybe it wasn't clear in my previous posts. Dan ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons 2002-03-01 5:07 ` Robert Dewar 2002-03-01 16:43 ` Dan Andreatta @ 2002-03-01 23:17 ` Dan Andreatta 2002-03-01 23:40 ` tmoran 1 sibling, 1 reply; 52+ messages in thread From: Dan Andreatta @ 2002-03-01 23:17 UTC (permalink / raw) > examples like this in detail, we discover that what > people think are "identical" programs are in fact totally different Er... you are right. (At this time Google hasn't reported any reply). I did some more experiments, and the bottleneck for the compiler was in the genration of the code for Integer'Image(). I modified the loop, and now it look more like the C version, relying on the I/O library (using Ada.Integer_Text_IO). Amazingly, now it compiles in about 2 seconds. Summarizing, these are the data (below are the fragments of the codes used): GNU/C GNU/Ada (1) GNU/Ada (2) GNU/Ada (3) Source size (kB) 45 82 103 97 Object size (kB) 63 503 503 109 time to compile (s) 1.4 11.0 8.0 2.2 compiled with gcc -c file.adb (no switches) In conclusion... draw your own conclusion. Memo for me: next time don't spare resources, use at lest 2 neurons :-) The codes for the loops (repeated 1000 times) were: GNU/C for (i=0; i<100; ++i) printf("%d\n",i); GNU/Ada (1) for i in 1..100 loop ada.text_io.put_line( Integer'Image(i) ); end loop; GNU/Ada (2) i := 0; while i<100 loop ada.text_io.put_line( Integer'Image(i) ); end loop; GNU/Ada (3) for i in 1..100 loop ada.integer_text_io.put( i ); ada.text_io.new_line; end loop; ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons 2002-03-01 23:17 ` Dan Andreatta @ 2002-03-01 23:40 ` tmoran 0 siblings, 0 replies; 52+ messages in thread From: tmoran @ 2002-03-01 23:40 UTC (permalink / raw) > and now it look more like the C version > ... > for (i=0; i<100; ++i) > printf("%d\n",i); Seems to me a closer approximation to the C would be procedure printf(s : in string; i : in integer) is begin null;end printf; -- then lots of copies of for i in 1..100 loop printf("%d\n", i); end loop; Making two function calls, whether they are in separate statements, or, worse, one is a variable length string-returning parameter to the other, likely takes the compiler more time than just one call, and, if IO time is a consideration, then having a source file that is twice as large is also a disadvantage. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons (was: naval systems) 2002-02-28 2:19 ` Dan Andreatta 2002-02-28 10:04 ` Jerry van Dijk 2002-02-28 13:35 ` compiler benchmark comparisons Georg Bauhaus @ 2002-02-28 14:18 ` Wes Groleau 2002-02-28 14:31 ` Ted Dennison 3 siblings, 0 replies; 52+ messages in thread From: Wes Groleau @ 2002-02-28 14:18 UTC (permalink / raw) > GNAT 11.0 sec > g77 4.0 > gcc 1.4 > g++ 3.3 > obj-c 2.6 (writing a "cout" class) > gcc 2.8 1.0 (gnat gcc) > gpc 2.8 1.1 > > OK, GNAT is slower... and so? Anybody cares? Hmmm. Hit return, take a slow sip of coffee, and start typing the next command. I guess I don't really care. :-) Actually, it does matter when you have 20,000 Ada files to compile. Which is why my point about distributed compilation. But it also reminds me of another point. With large C collections, to avoid unnecessary recompilations, one generally runs a tool to generate Makefiles (or painstakingly does it by hand). With Ada, part of this job is done by writing with clauses in the code, and the rest of this job is part of the compile. -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons (was: naval systems) 2002-02-28 2:19 ` Dan Andreatta ` (2 preceding siblings ...) 2002-02-28 14:18 ` compiler benchmark comparisons (was: naval systems) Wes Groleau @ 2002-02-28 14:31 ` Ted Dennison 2002-02-28 18:33 ` Dan Andreatta 2002-02-28 21:14 ` Wes Groleau 3 siblings, 2 replies; 52+ messages in thread From: Ted Dennison @ 2002-02-28 14:31 UTC (permalink / raw) andreatta@mail.chem.sc.edu (Dan Andreatta) wrote in message news:<338040f8.0202271819.373f733a@posting.google.com>... > OK, just to be into this benchmarck craze, I did a few tests w/ gcc > and family. > These are the results, using GCC 2.95 (mingw) and gnat 3.13p on a PII > 666MHz w/ NT 4.0: ... > The programs are 1000 loops like: > > for i in 1..100 loop > ada.text_io.put_line( Integer'Image(i) ); > end loop; > for i in 1..100 loop > ada.text_io.put_line( Integer'Image(i) ); > end loop; > .... So basicly you are testing the speed of the program's I/O facility? I suppose someone somewhere might care about that, but I/O is already so slow compared to everything else that it doesn't really make much difference to anyone. Add to that the fact that Ada has many other options when it comes to I/O (including using C's I/O), and it means less than nothing. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons (was: naval systems) 2002-02-28 14:31 ` Ted Dennison @ 2002-02-28 18:33 ` Dan Andreatta 2002-02-28 21:14 ` Wes Groleau 1 sibling, 0 replies; 52+ messages in thread From: Dan Andreatta @ 2002-02-28 18:33 UTC (permalink / raw) Those are the times to compile the source code. The execution times were much closer (0.2 sec gcc vs. 0.5 sec gnat, dumping the output). If you meant the compiler I/O, the sizes of the source files were around 45kb for C and 82 kb for Ada. So if the I/O is the limiting factor, I would expect gnat to be slower by only a factor of 2, not 10, provided that the parsing routines have similar efficiency. The bottleneck is not in the checkings, since the use of -gnatp does not modify the times. I don't pretend this is a good test, after all I did it in 10 minutes yesterday night. Dan ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons (was: naval systems) 2002-02-28 14:31 ` Ted Dennison 2002-02-28 18:33 ` Dan Andreatta @ 2002-02-28 21:14 ` Wes Groleau 1 sibling, 0 replies; 52+ messages in thread From: Wes Groleau @ 2002-02-28 21:14 UTC (permalink / raw) > So basicly you are testing the speed of the program's I/O facility? I No, she's testing code to compile IO calls. Or compile and link. I think. Maybe. It's starting to get confusing.... -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons (was: naval systems) 2002-02-27 23:53 ` Gary Barnes 2002-02-28 2:19 ` Dan Andreatta @ 2002-02-28 14:01 ` Wes Groleau 2002-03-01 22:01 ` Randy Brukardt 2002-02-28 15:58 ` Larry Kilgallen [not found] ` <338040f8.0202271819.373f733a@Organization: LJK Software <TgAW8WWqYgP5@eisner.encompasserve.org> 3 siblings, 1 reply; 52+ messages in thread From: Wes Groleau @ 2002-02-28 14:01 UTC (permalink / raw) Distributed compilation is another point. Most C compilers and GNAT can compile multiple source files simultaneously in separate processes. Apex can do that with limitations. Can any other Ada compilers do it? I would think that the library model used by some would prevent it. -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons (was: naval systems) 2002-02-28 14:01 ` Wes Groleau @ 2002-03-01 22:01 ` Randy Brukardt 0 siblings, 0 replies; 52+ messages in thread From: Randy Brukardt @ 2002-03-01 22:01 UTC (permalink / raw) Wes Groleau wrote in message <3C7E384C.A19AC609@despammed.com>... > >Distributed compilation is another point. > >Most C compilers and GNAT can compile multiple >source files simultaneously in separate processes. >Apex can do that with limitations. Can any other >Ada compilers do it? I would think that the >library model used by some would prevent it. Janus/Ada can do it. It does use a project manager, but the projects are locked only about 15% of the compilation time. And the compiler retries to get a locked project for 30 seconds before giving up. But the facility wasn't really intended to run multiple compilations on the same project; it really was designed to allow network users to work on separate projects with shared subsystems (like Claw). Before we had the project manager, you could run as many compiles as you wanted at once; but there was no protection against problems. Thus, if two compiles chose the same output file name (which depended on the unit name and a hash value), things could have gotten pretty messed up. [Output files were limited to 8.3 names because that was the limit on MS-DOS.] Which is why we introduced the project manager, so that file name choices couldn't conflict. Randy. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons (was: naval systems) 2002-02-27 23:53 ` Gary Barnes 2002-02-28 2:19 ` Dan Andreatta 2002-02-28 14:01 ` Wes Groleau @ 2002-02-28 15:58 ` Larry Kilgallen [not found] ` <338040f8.0202271819.373f733a@Organization: LJK Software <TgAW8WWqYgP5@eisner.encompasserve.org> 3 siblings, 0 replies; 52+ messages in thread From: Larry Kilgallen @ 2002-02-28 15:58 UTC (permalink / raw) In article <3C7E3C33.17E60A7D@despammed.com>, Wes Groleau <wesgroleau@despammed.com> writes: > With large C collections, to avoid unnecessary > recompilations, one generally runs a tool to > generate Makefiles (or painstakingly does it by > hand). With Ada, part of this job is done by > writing with clauses in the code, and the rest > of this job is part of the compile. When the tool that generates the makefiles is the previous run of the C compiler itself, the difference from Ada seems quite small. ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <338040f8.0202271819.373f733a@Organization: LJK Software <TgAW8WWqYgP5@eisner.encompasserve.org>]
* Re: compiler benchmark comparisons (was: naval systems) [not found] ` <338040f8.0202271819.373f733a@Organization: LJK Software <TgAW8WWqYgP5@eisner.encompasserve.org> @ 2002-03-01 19:29 ` Robert Dewar 2002-03-02 11:12 ` Pascal Obry [not found] ` <5ee5b646.0203011129.1bdbac56@po <ug03ji5ow.fsf@wanadoo.fr> 1 sibling, 1 reply; 52+ messages in thread From: Robert Dewar @ 2002-03-01 19:29 UTC (permalink / raw) Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<TgAW8WWqYgP5@eisner.encompasserve.org>... > When the tool that generates the makefiles is the > previous run of the C compiler itself, the difference > from Ada seems quite small. Well it is in practice quite large in most environments. Very few C environments update the makefile on every compilation (using tools like make depend), and one of the most important differences is that it is perfectly possible to link an inconsistent C program if your hand crafted procedures to prevent this go astray. So in practice, most Ada programmers find this a significant advantage of Ada over C, but of course your mileage may vary (after all there is nothing that requires an Ada environment to have decent tools, although there is still something that requires it to check for inconsistencies, unlike the case with Ada). Actually in most Ada compilers, it is hard to make the automatic recompilation 100% accurate anyway, e.g. many Ada systems end up with the amount of inlining depending on the order of compilation. So there is no magical guarantee here (one of the advantages of the source based approach to compilation is that in fact it is feasible to give a 100% guarantee on dependencies and recompilation, since you can compile clients before you compile the packages they need, so you do know what's needed before compiling it. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons (was: naval systems) 2002-03-01 19:29 ` Robert Dewar @ 2002-03-02 11:12 ` Pascal Obry 2002-03-02 19:49 ` Richard Riehle 0 siblings, 1 reply; 52+ messages in thread From: Pascal Obry @ 2002-03-02 11:12 UTC (permalink / raw) dewar@gnat.com (Robert Dewar) writes: > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<TgAW8WWqYgP5@eisner.encompasserve.org>... > > > When the tool that generates the makefiles is the > > previous run of the C compiler itself, the difference > > from Ada seems quite small. > > Well it is in practice quite large in most environments. > Very few C environments update the makefile on every And this can be said for many points. In almost all discussions I have with co-workers about programing languages features, each time I show on advantage in Ada I got something like "but this is also possible with XYZ language" ! And of course it is possible, everything is possible with every programing language... The fact is completly different. If the language does not have a built-in tools to support the feature then it is not addressed. Because the dead-line is comming, because money, because time... everything that require some more work to setup the environment, tools is most of the time skipped. To goes even farther I find the GNAT -gnaty option very nice. You can write on paper rules about laying out of code and syntax but if the compiler does not check that who will ???? > So in practice, most Ada programmers find this a significant advantage > of Ada over C, but of course > your mileage may vary (after all there is nothing > that requires an Ada environment to have decent tools, ^^^^ C here I think > although there is still something that requires it to > check for inconsistencies, unlike the case with Ada). In theory there is no difference in theory and practice... in practice there are :) Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://perso.wanadoo.fr/pascal.obry --| --| "The best way to travel is by means of imagination" ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: compiler benchmark comparisons (was: naval systems) 2002-03-02 11:12 ` Pascal Obry @ 2002-03-02 19:49 ` Richard Riehle 0 siblings, 0 replies; 52+ messages in thread From: Richard Riehle @ 2002-03-02 19:49 UTC (permalink / raw) Pascal Obry wrote: > And this can be said for many points. In almost all discussions I have with > co-workers about programing languages features, each time I show on advantage > in Ada I got something like "but this is also possible with XYZ language" ! The first time I encountered this argument, circa 1969, we were a Fortran shop with a new contract from the Navy for a specialized inventory control system. I was assigned project leader, and I suggested we do the project in COBOL instead of Fortran. There was no end of grumbling from the Fortranners who, every time I would identify a key benefit of COBOL for this project, would exclaim, "I can do that in Fortran." Nearly any problem that can be solved in one programming language can also be solved in any other language. That is, the solution for every programming problem is ultimately expressible in every other language. To defend one's choice of programming language using this rationale simply overlooks the more important question. Is language K more expressive of the problem to solution mapping than language P? Expressiveness is a far more important criterion than expressibility. In Ledgard's little diagram of soution-space mapped to problem-space, we see this issue in broad relief. There are, of course, trade-offs. One language may be more expressive than another, but may have insufficient built-in safeguards; or it may not have the critical mass in usage (e.g. Erlang), or it may have some other drawback. However, to say, "I can do that in my favorite language too," simply fails to recognize the deeper issues one must consider in selecting a programming language for a given project. Richard Riehle ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <5ee5b646.0203011129.1bdbac56@po <ug03ji5ow.fsf@wanadoo.fr>]
* Re: compiler benchmark comparisons (was: naval systems) [not found] ` <5ee5b646.0203011129.1bdbac56@po <ug03ji5ow.fsf@wanadoo.fr> @ 2002-03-02 18:20 ` Simon Wright 0 siblings, 0 replies; 52+ messages in thread From: Simon Wright @ 2002-03-02 18:20 UTC (permalink / raw) Pascal Obry <p.obry@wanadoo.fr> writes: > To goes even farther I find the GNAT -gnaty option very nice. You > can write on paper rules about laying out of code and syntax but if > the compiler does not check that who will ???? I quite agree, it saves endless disagreement about style. Our project has accepted my recommendation that we use it (plain -gnaty, no fancy messing, why write -gnaty3abcefhiklmprst !!) ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-26 20:46 ` Pat Rogers 2002-02-26 22:41 ` Ray Blaak @ 2002-02-27 2:28 ` David Starner 2002-02-27 21:44 ` Pat Rogers 1 sibling, 1 reply; 52+ messages in thread From: David Starner @ 2002-02-27 2:28 UTC (permalink / raw) On Tue, 26 Feb 2002 20:46:45 GMT, Pat Rogers <progers@classwide.com> wrote: > Of course that is what I mean. Therefore, the stand-alone assertion that "GNAT > is noticably slower than gcc" is confusing. Does he mean that the front-end > for GNAT is slower than the front-end for C? I mean that compiling a program with gnat takes longer than a comparable program with the C compiler. Both in uncontrolled experiance and tests. > Does he mean that the end-to-end > performance of any Ada compiler is slower than any C compiler, as supported by a > comparison of supplying C code and Ada code to gcc? Of course not. That's absurd. Nice strawman, though. > Did this Ada code and C > code do the same thing? Of course. >What switches did he use for both? None, for the tests. > One can just as easily assert that -- with comparable (not identical) switches > and with the code doing the same thing -- most of the time there won't be a > significant difference in either compile-time or run-time. Pathological cases > in either direction can no doubt be constructed. So what? One can easily assert that. One can easily assert pretty much anything. But if it's to believed, it should be backed up by evidence or it's just noise. Given both the null program and Hello, World!, the C compiler took about 1/3 of the time that GNAT did, with no options and with -O2 -g. I generated a 32,002 line program that had 32,000 randomly pointing (but the same for the C and Ada program) goto statements in it, and told it to write to assembly only, with no optimization. The C compiler took 4 seconds. GNAT took 7 minutes to tell me I was missing a semicolon. After fixing that semicolon, it took 6 minutes 59 seconds to produce assembly with no significant difference. The last case is a bit pathological, but it is a data point. In all cases I tried the C compiler was significantly faster than GNAT. If you want to argue that there won't be a significant difference, please show test cases and numbers, instead of just making assertions. I argue not that the speed matters, merely that there is a difference in speed. (BTW: The example solution in Graphics was in C++, and I hand converted it to Ada. Compiling it with G++ took about 40% longer than with GNAT. I converted nested vector classes to arrays of pointers, though, which probably made a difference.) >> If one means gcc to mean the C/C++ compiler only, then of course it is not the >> same -- they compile different languages. > > Clearly. However, that is an obsolete definition, given that GCC is now the "GNU > Compiler Collection". Ah, but you're assuming that Unix acronyms are case-insensitive. They aren't - GCC is unambigiously the "GNU Compiler Collection", but gcc may be "GNU C Compiler", or the driver program that merely runs the compilers, or occasionally the same as GCC. -- David Starner - starner@okstate.edu What we've got is a blue-light special on truth. It's the hottest thing with the youth. -- Information Society, "Peace and Love, Inc." ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-27 2:28 ` naval systems David Starner @ 2002-02-27 21:44 ` Pat Rogers 2002-03-01 2:59 ` David Starner 2002-03-01 17:22 ` Jeffrey Carter 0 siblings, 2 replies; 52+ messages in thread From: Pat Rogers @ 2002-02-27 21:44 UTC (permalink / raw) "David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message news:a5hg80$8a22@news.cis.okstate.edu... > On Tue, 26 Feb 2002 20:46:45 GMT, Pat Rogers <progers@classwide.com> wrote: > > Of course that is what I mean. Therefore, the stand-alone assertion that "GNAT > > is noticably slower than gcc" is confusing. Does he mean that the front-end > > for GNAT is slower than the front-end for C? > > I mean that compiling a program with gnat takes longer than a comparable > program with the C compiler. Both in uncontrolled experiance and tests. > > > Does he mean that the end-to-end > > performance of any Ada compiler is slower than any C compiler, as supported by a > > comparison of supplying C code and Ada code to gcc? > > Of course not. That's absurd. Nice strawman, though. I think that is a fair description, actually, although I can see you may not have meant the earlier post the way I took it. > > Did this Ada code and C > > code do the same thing? > > Of course. > > >What switches did he use for both? > > None, for the tests. Ah, this is what I'm trying to get to. Taking the defaults for the two compilers/languages is *not* comparable. You need to at least turn of run-time checking for the Ada program. That's enough to invalidate the test by itself. > > One can just as easily assert that -- with comparable (not identical) switches > > and with the code doing the same thing -- most of the time there won't be a > > significant difference in either compile-time or run-time. Pathological cases > > in either direction can no doubt be constructed. So what? > > One can easily assert that. One can easily assert pretty much anything. > But if it's to believed, it should be backed up by evidence or it's just > noise. Precisely -- evidence that will stand up to scrutiny, however. > Given both the null program and Hello, World!, the C compiler took about > 1/3 of the time that GNAT did, with no options and with -O2 -g. That isn't as meaningful as one might think, although it is not an uncommon test. I assume you used Text_IO? The compile times were hugely overshadowed by handling of the I/O libraries. That is not a comparable program to one in C that uses the much simpler I/O library. > I generated a 32,002 line program that had 32,000 randomly pointing (but > the same for the C and Ada program) goto statements in it, and told it > to write to assembly only, with no optimization. The C compiler took 4 > seconds. GNAT took 7 minutes to tell me I was missing a semicolon. After > fixing that semicolon, it took 6 minutes 59 seconds to produce assembly > with no significant difference. > > The last case is a bit pathological, but it is a data point. So pathological, in fact, that I don't believe they were the "same" program. I'm surprised anyone would! It is extremely easy to get this kind of thing wrong -- thinking that the semantics are the same when they aren't. I've done it before and no doubt will do it again. It is trivially easy to drive an Ada compiler to its knees -- over a period of several grinding minutes in some compilers -- by declaring a series of named numbers that look like regular old C constants. > In all > cases I tried the C compiler was significantly faster than GNAT. If you > want to argue that there won't be a significant difference, please show > test cases and numbers, instead of just making assertions. That's exactly what I wanted you to do. I wanted to hear the basis for your assertion. > I argue not that the speed matters, merely that there is a difference in > speed. And I'm trying to get to why you think that, above and beyond scant empirical -- and perhaps questionable -- data. In particular, I want to know why **in terms of the languages' definitions.** What are the semantics that affect the compiler itself, after the switches are set appropriately and the code is truely comparable, such that, as you say, "there is a difference". Otherwise we are only comparing implementations and cannot generalize the result. Again, we are talking about compile time, not the time it takes to build the executable, because indeed the Ada binder/linker implements requirements that the C tools do not bother with, like interface consistency. And again, we are talking about compiling the same way -- with the switches set so that the compilers behave comparably. Turning of the checking is the obvious example. > (BTW: The example solution in Graphics was in C++, and I hand converted > it to Ada. Compiling it with G++ took about 40% longer than with GNAT. I > converted nested vector classes to arrays of pointers, though, which > probably made a difference.) Interesting. At the end of the day, we are in agreement that in practice the time it takes to produce an executable image from an Ada toolchain is typically slightly longer. What we're arguing is whether the compilation phase itself is inherently slower, which is I hope an accurate interpretation of the prior posts, as illustrated by the one above: "> I argue not that the speed matters, merely that there is a difference in speed." ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-27 21:44 ` Pat Rogers @ 2002-03-01 2:59 ` David Starner 2002-03-01 15:33 ` Pat Rogers 2002-03-01 17:22 ` Jeffrey Carter 1 sibling, 1 reply; 52+ messages in thread From: David Starner @ 2002-03-01 2:59 UTC (permalink / raw) On Wed, 27 Feb 2002 21:44:32 GMT, Pat Rogers <progers@classwide.com> wrote: > Ah, this is what I'm trying to get to. Taking the defaults for the two > compilers/languages is *not* comparable. You need to at least turn of run-time > checking for the Ada program. That's enough to invalidate the test by itself. > >> Given both the null program and Hello, World!, the C compiler took about >> 1/3 of the time that GNAT did, with no options and with -O2 -g. > > That isn't as meaningful as one might think, although it is not an uncommon > test. I assume you used Text_IO? The compile times were hugely overshadowed by > handling of the I/O libraries. That is not a comparable program to one in C > that uses the much simpler I/O library. > >> I generated a 32,002 line program that had 32,000 randomly pointing (but >> the same for the C and Ada program) goto statements in it, and told it >> to write to assembly only, with no optimization. The C compiler took 4 >> seconds. GNAT took 7 minutes to tell me I was missing a semicolon. After >> fixing that semicolon, it took 6 minutes 59 seconds to produce assembly >> with no significant difference. >> >> The last case is a bit pathological, but it is a data point. > > So pathological, in fact, that I don't believe they were the "same" program. > I'm surprised anyone would! You mean, besides the fact that GNAT and GNU C produced the exact same assembly, except for four instructions (apparently GNU C felt the need to align the stack, where GNAT didn't). You mean besides the fact the fact the two programs have the exact same semantics - emit no output and never exit except on a signal. > It is extremely easy to get this kind of thing wrong -- thinking that the > semantics are the same when they aren't. I've done it before and no doubt will > do it again. It is trivially easy to drive an Ada compiler to its knees -- over > a period of several grinding minutes in some compilers -- by declaring a series > of named numbers that look like regular old C constants. All nice advocate answers. Now back to real life, if I write several programs simple enough that the semantics are exactly the same for each language, and each one is slower to compile with GNAT than GNU C, then I will come to the conclusion that GNAT is slower than GNU C. You seem to be interested in some idealized "fair" compairson. But that's not what matters - what matters is how long it takes on real life programs. > Otherwise we are > only comparing implementations and cannot generalize the result. Um, of course we can generalize the result. That's science - you take sample data points and see if you can draw a conclusion. How an idealized optimal Ada compiler performs is of little interest; how the Ada compiler that's on their desk or will be on their desk performs is of interest. > Again, we are talking about compile time, not the time it takes to build the > executable, because indeed the Ada binder/linker implements requirements that > the C tools do not bother with, like interface consistency. And again, we are > talking about compiling the same way -- with the switches set so that the > compilers behave comparably. Turning of the checking is the obvious example. You keep trying to add a handicap. The interesting question is time from submitting the sources to getting a binary; any features is a whole different question. What switches should be added is a complex question, but the answer should have to do with what will be normally used, and not what would make it more theoratically "fair". > At the end of the day, we are in agreement that in practice the time it takes to > produce an executable image from an Ada toolchain is typically slightly longer. > What we're arguing is whether the compilation phase itself is inherently slower, What does "inherently slower" mean? If you go back to the original post to which I responded, he was talking about most implementations being as fast as most C implementations; that was what I was responding to; I never said anything about all Ada implementations being inherently slower. -- David Starner - starner@okstate.edu What we've got is a blue-light special on truth. It's the hottest thing with the youth. -- Information Society, "Peace and Love, Inc." ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-03-01 2:59 ` David Starner @ 2002-03-01 15:33 ` Pat Rogers 0 siblings, 0 replies; 52+ messages in thread From: Pat Rogers @ 2002-03-01 15:33 UTC (permalink / raw) "David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message news:a5mqqo$9283@news.cis.okstate.edu... > On Wed, 27 Feb 2002 21:44:32 GMT, Pat Rogers <progers@classwide.com> wrote: <snip> This is going nowhere. Let's put it to bed. I have no interest in generating ill-will over something we apparently cannot communicate usefully about. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-27 21:44 ` Pat Rogers 2002-03-01 2:59 ` David Starner @ 2002-03-01 17:22 ` Jeffrey Carter 2002-03-03 5:21 ` David Starner 1 sibling, 1 reply; 52+ messages in thread From: Jeffrey Carter @ 2002-03-01 17:22 UTC (permalink / raw) David Starner wrote: > > You seem to be interested in some idealized "fair" compairson. But > that's not what matters - what matters is how long it takes on real life > programs. No, a few seconds difference in compiling large source files does not matter. > > You keep trying to add a handicap. The interesting question is time from > submitting the sources to getting a binary; any features is a whole > different question. No, the interesting question is the confidence you have in the resulting executable. Ada is optimized for large systems with multiple modules. Ada does type checking across separately compiled modules and handles tasking, exceptions, and generics. To get the same level of confidence in a large, multiple module system is faster in Ada than C since Ada automates so much of what must be done manually in C. If you're only interested in toy, single module systems, or you're willing to accept the behavior your typos produce, then C is faster. -- Jeffrey Carter ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-03-01 17:22 ` Jeffrey Carter @ 2002-03-03 5:21 ` David Starner 0 siblings, 0 replies; 52+ messages in thread From: David Starner @ 2002-03-03 5:21 UTC (permalink / raw) On Fri, 1 Mar 2002 17:22:08 GMT, Jeffrey Carter <jeffrey.carter@boeing.com> wrote: > David Starner wrote: > [...] > > No, a few seconds difference in compiling large source files does not > matter. > >> >> You keep trying to add a handicap. The interesting question is time from >> submitting the sources to getting a binary; any features is a whole >> different question. > > No, the interesting question is the confidence you have in the resulting > executable. An answer of a sophist. The few seconds difference was on compiling the null program; the large source file took 6 minutes longer. And while the reliability of the program is important, it's not the only question, or Dewar wouldn't still be telling us how fast his COBOL compiler was. -- David Starner - starner@okstate.edu What we've got is a blue-light special on truth. It's the hottest thing with the youth. -- Information Society, "Peace and Love, Inc." ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-26 19:55 ` Ray Blaak 2002-02-26 20:46 ` Pat Rogers @ 2002-02-26 22:40 ` Pascal Obry 1 sibling, 0 replies; 52+ messages in thread From: Pascal Obry @ 2002-02-26 22:40 UTC (permalink / raw) Ray Blaak <blaak@telus.net> writes: > If one means gcc to mean the suite of language specific compilers using a > common code generation backend, then GNAT is a part of gcc. GCC means "GNU Compiler Collection" now, the C compiler is GNU/C the Ada compiler is GNU/Ada (aka GNAT). > If one means gcc to mean the C/C++ compiler only, then of course it is not > the same -- they compile different languages. GCC should not be used for GNU/C compiler these days. > At any rate, it should come as no surprise that an Ada compiler is slower > than a C compiler -- an Ada compiler is doing far more work, plain and > simple. Indeed. I see nothing really surprising. Marin point was just that with today computer speed (we all have a mainframe on our desk these days) it is not an issue as important as 20 years ago. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://perso.wanadoo.fr/pascal.obry --| --| "The best way to travel is by means of imagination" ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-26 19:49 ` Pat Rogers 2002-02-26 19:55 ` Ray Blaak @ 2002-02-27 0:42 ` David Starner 1 sibling, 0 replies; 52+ messages in thread From: David Starner @ 2002-02-27 0:42 UTC (permalink / raw) On Tue, 26 Feb 2002 19:49:42 GMT, Pat Rogers <progers@classwide.com> wrote: > I don't understand this. GNAT *is* gcc. Technically, GNAT is the Ada compiler in GCC (the GNU Compiler Collection.) gcc is the C compiler in GCC. I wasn't try to be technical, though. I just assumed everyone would understand what I meant. -- David Starner - starner@okstate.edu What we've got is a blue-light special on truth. It's the hottest thing with the youth. -- Information Society, "Peace and Love, Inc." ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-22 14:55 ` Marin David Condic 2002-02-23 5:54 ` David Starner @ 2002-02-23 19:18 ` John R. Strohm 2002-02-23 18:36 ` martin.m.dowie 2002-02-25 15:10 ` Marin David Condic 1 sibling, 2 replies; 52+ messages in thread From: John R. Strohm @ 2002-02-23 19:18 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:a55m56$6mk$1@nh.pace.co.uk... > "David Gillon" <david.gillon@baesystems.com> wrote in message > news:3C763746.CC8B2965@baesystems.com... > > > > > > Andrew Swallow wrote: > > > The runtime support code > > > needed more memory than most embedded computers had. > > > > Only if you didn't tailor it. And how has the embedded market reacted to > > this supposed limitation? Gone all out for run-time operating > > systems..... > > > Good point. I've built embedded systems with Ada that had nice, small RTKs > that could be cut down to just what you needed and no more. For very tiny > computers, you probably couldn't get the whole of Ada into them, but if you > made intelligent choices about what you needed, you could get all the way > down to *NO* RTK if necessary. Something over ten years ago, I took an Ada training class at Texas Instruments. (It was really a review for me, but I needed the review.) One of the features of the class was a videotape of a Q&A session with Jean Ichbiah and two other Ada luminaries. Ichbiah was asked that precise question, about the size of the runtime, and how it seemed that it would be too big for anything practical. His answer was that a just-about-fully-compliant Ada runtime module had been written in 4K words. Note well his choice of words: not "could be" but "HAD BEEN" (emphasis added). Not long after that, I had occasion to check that answer, for the Tartan Labs toolset for the TI 320C30 32-bit floating point digital signal processor. The Ada runtime module for that processor was, indeed, about 4K words. This rather shocked my supervisor at the time; he'd just assumed it would be prohibitively big and NEVER LOOKED. I don't know very many embedded systems that can't scratch up 4K words of code space for a runtime kernel. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-23 19:18 ` John R. Strohm @ 2002-02-23 18:36 ` martin.m.dowie 2002-02-25 15:10 ` Marin David Condic 1 sibling, 0 replies; 52+ messages in thread From: martin.m.dowie @ 2002-02-23 18:36 UTC (permalink / raw) > Something over ten years ago, I took an Ada training class at Texas > Instruments. (It was really a review for me, but I needed the review.) One > of the features of the class was a videotape of a Q&A session with Jean > Ichbiah and two other Ada luminaries. > > Ichbiah was asked that precise question, about the size of the runtime, and > how it seemed that it would be too big for anything practical. > > His answer was that a just-about-fully-compliant Ada runtime module had been > written in 4K words. Note well his choice of words: not "could be" but > "HAD BEEN" (emphasis added). > > Not long after that, I had occasion to check that answer, for the Tartan > Labs toolset for the TI 320C30 32-bit floating point digital signal > processor. The Ada runtime module for that processor was, indeed, about 4K > words. This rather shocked my supervisor at the time; he'd just assumed it > would be prohibitively big and NEVER LOOKED. > > I don't know very many embedded systems that can't scratch up 4K words of > code space for a runtime kernel. From what I can gather this is the same size a non-tasking Ravenscar-profile RTK - for tasking add another 9 or 10K, but still not exactly huge is it? ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-23 19:18 ` John R. Strohm 2002-02-23 18:36 ` martin.m.dowie @ 2002-02-25 15:10 ` Marin David Condic 1 sibling, 0 replies; 52+ messages in thread From: Marin David Condic @ 2002-02-25 15:10 UTC (permalink / raw) And, typically, you can pare it down as needed. If you've got a really small box and don't need tasking & want to stick to some subset of the language in your coding practices, you can get the runtime down to nothing at all. Of course, one then needs to be careful that after having removed many of the language's services that one doesn't just turn around and reproduce them in some other way in the code. I've seen this done often - especially with respect to tasking. Someone will get rid of tasking because its "too inefficient" then just inefficiently juggle code all over the place to fill up idle time or reinvent tasking in some other form. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "John R. Strohm" <strohm@airmail.net> wrote in message news:CB534AA00A46FA5E.AAAB490398694730.BDDDDEA65B01C997@lp.airnews.net... > > I don't know very many embedded systems that can't scratch up 4K words of > code space for a runtime kernel. > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-22 12:19 ` naval systems David Gillon 2002-02-22 14:55 ` Marin David Condic @ 2002-02-28 16:33 ` tony gair 2002-02-28 17:33 ` David Gillon ` (2 more replies) 1 sibling, 3 replies; 52+ messages in thread From: tony gair @ 2002-02-28 16:33 UTC (permalink / raw) > > Nonsense. Boeing _chose_ to use Ada for it's development of the 777, > which had extremely tight schedules and where contracts were > risk-sharing, not cost-plus. The FAA couldn't have cared less what > language they used, so they gained nothing there, but Boeing saw enough > gains in the language to pursue it for its own sake. > I was present on the project testing phase of the 777 ada fly by wire system, and my understanding of Boeings choice for Ada was the following 1) The systems functions and procedures needed testing at a component level, Most Ada programmers I've met have experience of rigourous testing. 2) The contract for the fly by wire system was completed by Marconi Avionics in Elstree, UK, who are mainly Ada programmers and normally do Big Guns projects. This probably decided the project language. The ready availability of design, and test tools used on Big Guns projects was possibly also a deciding factor. There were initially three different languages that were going to be used for the project, but this idea was scrapped in favour of exclusively using Ada. Incidently the growling red faced project testing manager was rumoured to whilst in work time regularly partake in the abuse of certain columbian exports. Would you fly on this aircraft? ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-28 16:33 ` tony gair @ 2002-02-28 17:33 ` David Gillon 2002-02-28 21:18 ` Wes Groleau 2002-03-01 17:31 ` Boeing 777 (WAS: naval systems) Simon Pilgrim 2 siblings, 0 replies; 52+ messages in thread From: David Gillon @ 2002-02-28 17:33 UTC (permalink / raw) tony gair wrote: > I was present on the project testing phase of the 777 ada fly by wire > system, and my understanding of Boeings choice for Ada was the following > > 1) The systems functions and procedures needed testing at a component level, > Most Ada programmers I've met have experience of rigourous testing. > > 2) The contract for the fly by wire system was completed by Marconi Avionics > in Elstree, UK, who are mainly Ada programmers and normally do Big Guns > projects. This probably decided the project language. The ready availability > of design, and test tools used on Big Guns projects was possibly also a > deciding factor. This is almost completely inaccurate. The only thing you have right is that the contract was to MAv/GMAv, but even here it was in fact at Rochester. On the initial prototype development two out of three teams were non-Ada and the engineers reflected that. The decision to focus on Ada across the entire aircraft, not simply the FCS, was Boeing's. Their decision to go for single design/common code on the production FCS was driven by certain decisions out of the FAA and came very late in the day. MAv were only the sub-contractor on the FCS, and couldn't, for instance, drive the choice of language on the AIMS which was being written by Honeywell, or on any of the other systems. For the Boeing perspective on their adoption of Ada for 777 there's a rather good article in the Crosstalk archives. > Would you fly on this aircraft? In an instant. And I was on the project from before formal launch of the 777 to entry into service so I know precisely what went on during development. -- David Gillon ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: naval systems 2002-02-28 16:33 ` tony gair 2002-02-28 17:33 ` David Gillon @ 2002-02-28 21:18 ` Wes Groleau 2002-03-01 17:31 ` Boeing 777 (WAS: naval systems) Simon Pilgrim 2 siblings, 0 replies; 52+ messages in thread From: Wes Groleau @ 2002-02-28 21:18 UTC (permalink / raw) > Incidently the growling red faced project testing manager was rumoured to > whilst in work time regularly partake in the abuse of certain columbian > exports. I partake of certain Colombian exports on work time. My doctor might call it abuse. But my coffee _is_ legal--I suspect you refer to a different Colombian export. ?? -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 52+ messages in thread
* Boeing 777 (WAS: naval systems) 2002-02-28 16:33 ` tony gair 2002-02-28 17:33 ` David Gillon 2002-02-28 21:18 ` Wes Groleau @ 2002-03-01 17:31 ` Simon Pilgrim 2 siblings, 0 replies; 52+ messages in thread From: Simon Pilgrim @ 2002-03-01 17:31 UTC (permalink / raw) tony gair wrote: > 2) The contract for the fly by wire system was completed by Marconi Avionics > in Elstree, UK, who are mainly Ada programmers and normally do Big Guns > projects. This probably decided the project language. The ready availability > of design, and test tools used on Big Guns projects was possibly also a > deciding factor. As Dave stated in another reply, you are a bit wide of the mark there. Marconi Avionics has been through a few name changes and a merger, but the flight controls has always been based in Rochester, Kent, UK. We are now part of BAE SYSTEMS, Avionic Systems Division. We have been making civil and military flight control systems for many years for aircraft such as Concorde, Eurofighter, Canadair RJ, Airbus A320, UAVs and many more. I believe it was this system knowledge and our well-established relationship with Boeing, rather than any specific language experience that influenced Boeing to select us. > There were initially three different languages that were going to be used > for the project, but this idea was scrapped in favour of exclusively using > Ada. The three languages were originally: C, Ada and PLM. We now use a subset of Ada, running on three different targets. > Would you fly on this aircraft? I have and I loved it. I even stood under the flight path at the airfield perimeter when the 777-200 took off for first flight (along with several hundred other proud people). The Boeing 777 was probably tested more than any other previous aircraft before it left the ground, thanks to the enormous amount of simulation work done. You say you were present on the project testing phase, so must have seen the huge investment Boeing made in the IASL (Integrated Avionics Systems Laboratory?). Also the huge amount of dedication and professionalism from those involved. If you wouldn't fly on the 777 because of safety concerns, you must live in a bunker with a tin-foil beanie hat ;-) -- Regards, Simon Pilgrim Civil Flight Controls, Rochester, UK All views expressed are my own and not necessarily those of my employer. ^ permalink raw reply [flat|nested] 52+ messages in thread
end of thread, other threads:[~2002-03-03 5:21 UTC | newest] Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <3C74E519.3F5349C4@baesystems.com> [not found] ` <20020221205157.05542.00000012@mb-cm.news.cs.com> 2002-02-22 12:19 ` naval systems David Gillon 2002-02-22 14:55 ` Marin David Condic 2002-02-23 5:54 ` David Starner 2002-02-25 15:05 ` Marin David Condic 2002-02-26 2:34 ` Larry Kilgallen 2002-02-26 17:44 ` David Starner 2002-02-26 19:49 ` Pat Rogers 2002-02-26 19:55 ` Ray Blaak 2002-02-26 20:46 ` Pat Rogers 2002-02-26 22:41 ` Ray Blaak 2002-02-27 0:02 ` Pat Rogers 2002-02-27 5:01 ` David Starner 2002-02-27 9:38 ` Jean-Pierre Rosen 2002-02-27 19:48 ` compiler benchmark comparisons (was: naval systems) Wes Groleau 2002-02-27 21:51 ` Pat Rogers 2002-03-01 2:04 ` David Starner 2002-03-01 4:06 ` Pat Rogers 2002-02-27 23:53 ` Gary Barnes 2002-02-28 2:19 ` Dan Andreatta 2002-02-28 10:04 ` Jerry van Dijk 2002-02-28 13:35 ` compiler benchmark comparisons Georg Bauhaus 2002-02-28 18:12 ` Dan Andreatta 2002-03-01 5:07 ` Robert Dewar 2002-03-01 16:43 ` Dan Andreatta 2002-03-01 23:17 ` Dan Andreatta 2002-03-01 23:40 ` tmoran 2002-02-28 14:18 ` compiler benchmark comparisons (was: naval systems) Wes Groleau 2002-02-28 14:31 ` Ted Dennison 2002-02-28 18:33 ` Dan Andreatta 2002-02-28 21:14 ` Wes Groleau 2002-02-28 14:01 ` Wes Groleau 2002-03-01 22:01 ` Randy Brukardt 2002-02-28 15:58 ` Larry Kilgallen [not found] ` <338040f8.0202271819.373f733a@Organization: LJK Software <TgAW8WWqYgP5@eisner.encompasserve.org> 2002-03-01 19:29 ` Robert Dewar 2002-03-02 11:12 ` Pascal Obry 2002-03-02 19:49 ` Richard Riehle [not found] ` <5ee5b646.0203011129.1bdbac56@po <ug03ji5ow.fsf@wanadoo.fr> 2002-03-02 18:20 ` Simon Wright 2002-02-27 2:28 ` naval systems David Starner 2002-02-27 21:44 ` Pat Rogers 2002-03-01 2:59 ` David Starner 2002-03-01 15:33 ` Pat Rogers 2002-03-01 17:22 ` Jeffrey Carter 2002-03-03 5:21 ` David Starner 2002-02-26 22:40 ` Pascal Obry 2002-02-27 0:42 ` David Starner 2002-02-23 19:18 ` John R. Strohm 2002-02-23 18:36 ` martin.m.dowie 2002-02-25 15:10 ` Marin David Condic 2002-02-28 16:33 ` tony gair 2002-02-28 17:33 ` David Gillon 2002-02-28 21:18 ` Wes Groleau 2002-03-01 17:31 ` Boeing 777 (WAS: naval systems) Simon Pilgrim
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox