* WinNT ADA compilers comparison @ 2000-07-20 0:00 Nicolas Brunot 2000-07-20 0:00 ` tmoran ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Nicolas Brunot @ 2000-07-20 0:00 UTC (permalink / raw) We saw several messages from people comparing behavior of different ADA compilers But usually this concerns executable size or performance, or why one doesn't accept code accepted by the others. Have somebody made comparison between different compilers for Win NT (Gnat, Objectada, Rational, Janus, etc ...) concerning - compile time - bind and link time - accept projects of more than 500 000 lines and several hundred source files ADA code without problem The annoucement of gnat 3.13 said that it would accept Microsoft linker and objects. Does anybody know if this is an option or if gnat 3.12 linker is no longer supported in 3.13 ? (We noticed poor performance concerning link time for Microsoft linker when a great number of objects are involved, is there a regression concerning link time between 3.12 and 3.13 ?) Thank you for any information you have. Nicolas BRUNOT ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: WinNT ADA compilers comparison 2000-07-20 0:00 WinNT ADA compilers comparison Nicolas Brunot @ 2000-07-20 0:00 ` tmoran 2000-07-20 0:00 ` Stephen Leake 2000-07-20 0:00 ` Thierry Lelegard 2 siblings, 0 replies; 20+ messages in thread From: tmoran @ 2000-07-20 0:00 UTC (permalink / raw) From the old PIWG READ.ME, dated 8/31/90 "There are three (3) complete runs to be made on each computer/compiler combination. The first run makes execution performance measurements on Ada features and composite benchmarks. The second run makes a composite compile speed measurement including linking and execution. The third run compiles about 100 files from the SIGAda programming contest winner, then compiles the same source code again as one file." That might be a start. I don't know if there's a newer version somewhere. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: WinNT ADA compilers comparison 2000-07-20 0:00 WinNT ADA compilers comparison Nicolas Brunot 2000-07-20 0:00 ` tmoran @ 2000-07-20 0:00 ` Stephen Leake 2000-07-20 0:00 ` Pascal Obry 2000-07-20 0:00 ` Thierry Lelegard 2 siblings, 1 reply; 20+ messages in thread From: Stephen Leake @ 2000-07-20 0:00 UTC (permalink / raw) Nicolas Brunot <n.brunot@cadwin.com> writes: > We saw several messages from people comparing behavior of different ADA > compilers > But usually this concerns executable size or performance, or why one > doesn't accept code accepted by the others. > Have somebody made comparison between different compilers for Win NT > (Gnat, Objectada, Rational, Janus, etc ...) concerning > - compile time > - bind and link time > - accept projects of more than 500 000 lines and several hundred source > files ADA code without problem If you are seriously evaluating compilers, contact the vendors. ACT is perfectly willing to help you evaluate GNAT; no up-front charge involved. Other vendors should do the same; some come close. > The annoucement of gnat 3.13 said that it would accept Microsoft linker > and objects. > Does anybody know if this is an option or if gnat 3.12 linker is no > longer supported in 3.13 ? The default linker is the GNU linker, which now accepts MS object files. I'm not sure if GNAT can produce MS object files; if it can, than you could use the MS linker. gcc has always had the capability of substituting different tools for the different phases of compilation; preprocess, compile (to assembler), assemble, link. -- -- Stephe ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: WinNT ADA compilers comparison 2000-07-20 0:00 ` Stephen Leake @ 2000-07-20 0:00 ` Pascal Obry 0 siblings, 0 replies; 20+ messages in thread From: Pascal Obry @ 2000-07-20 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 724 bytes --] Stephen Leake a �crit dans le message ... >The default linker is the GNU linker, which now accepts MS object >files. I'm not sure if GNAT can produce MS object files; if it can, >than you could use the MS linker. Definitly. MS linker can be used to build executable from GNAT object files. But this must be done by hand. There is not automatic way to do that yet. 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] 20+ messages in thread
* Re: WinNT ADA compilers comparison 2000-07-20 0:00 WinNT ADA compilers comparison Nicolas Brunot 2000-07-20 0:00 ` tmoran 2000-07-20 0:00 ` Stephen Leake @ 2000-07-20 0:00 ` Thierry Lelegard 2000-07-20 0:00 ` Lionel Draghi 2 siblings, 1 reply; 20+ messages in thread From: Thierry Lelegard @ 2000-07-20 0:00 UTC (permalink / raw) > Have somebody made comparison between different compilers for Win NT > (Gnat, Objectada, Rational, Janus, etc ...) concerning > - compile time > - bind and link time I would think that the most important "time" point is the performance of the generated code. You compile once but you run your application many times... -Thierry ________________________________________________________ Thierry Lelegard, Paris, France E-mail: lelegard@club-internet.fr ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: WinNT ADA compilers comparison 2000-07-20 0:00 ` Thierry Lelegard @ 2000-07-20 0:00 ` Lionel Draghi 2000-07-21 0:00 ` Nicolas Brunot 0 siblings, 1 reply; 20+ messages in thread From: Lionel Draghi @ 2000-07-20 0:00 UTC (permalink / raw) Thierry Lelegard wrote: > ... > I would think that the most important "time" point is > the performance of the generated code. You compile > once but you run your application many times... A lot of software that where more compiled than used :-) ________________________________________________________________________ Lionel Draghi http://www.Ada-France.org/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: WinNT ADA compilers comparison 2000-07-20 0:00 ` Lionel Draghi @ 2000-07-21 0:00 ` Nicolas Brunot 2000-07-22 0:00 ` Thierry Lelegard 0 siblings, 1 reply; 20+ messages in thread From: Nicolas Brunot @ 2000-07-21 0:00 UTC (permalink / raw) From the user point of view, I think that reliability comes first (without it, you usually lose so much time that generated code performance is useless and means nothing) More than that, increase performance by 5 doesn't mean a lot. After a user action : he will find not acceptable the difference between 1s and 5s he will not care or even notice the difference between 1ms and 5ms (And I saw some developpers spending days for the second improvement, while not even care about the first ..., usually the user is not very happy) Even if this is the most important, that doesn't mean you don't have to care about development cost (one of the original purpose of ADA language, with reliability) As far as we are concerned, our code is far from being compile and linked just once ! During the development process, corrections, maintenance,..., and before the software can be provided to a customer, the code is compiled and linked thousands of times. I know few developpers linking just once a day. For us, the difference between 20s and 4mns for linking is more than important (we actually saw that difference between some compilers for same code and executable) Lionel Draghi a �crit : > Thierry Lelegard wrote: > > > ... > > I would think that the most important "time" point is > > the performance of the generated code. You compile > > once but you run your application many times... > A lot of software that where more compiled than used :-) > > ________________________________________________________________________ > Lionel Draghi http://www.Ada-France.org/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: WinNT ADA compilers comparison 2000-07-21 0:00 ` Nicolas Brunot @ 2000-07-22 0:00 ` Thierry Lelegard 2000-07-24 0:00 ` Nicolas Brunot 0 siblings, 1 reply; 20+ messages in thread From: Thierry Lelegard @ 2000-07-22 0:00 UTC (permalink / raw) > From the user point of view, I think that reliability comes first Sure. Performance comes after reliablity. > More than that, increase performance by 5 doesn't mean a lot. > After a user action : > he will find not acceptable the difference between 1s and 5s > he will not care or even notice the difference between 1ms and 5ms > (And I saw some developpers spending days for the second improvement, while > not even care about the first ..., usually the user is not very happy) There are two different points here: 1. The way the application (source code) is written 2. The way the compiler generates the binary code. Spending days optimizing the less relevant part of an application is the first point. I agree that this is useless. But, on a code generator point a view, there is no difference in optimizing from 5s to 1s and from 5ms to 1ms. The first case is most of the time (roughly) a loop of 1000 iterations of the second case in the source code. The quality and speed of the generated code is an instrinsic quality of a compiler. To address the full range of applications, a compiler must make it right. Let me briefly describe two cases I experienced where it made all the difference: - Years ago, I spent two days optimizing a few ms in a matrix calculation. Why? It was in a Sonar software and the extra ms missed the next hit. - Currently, we sell software products to customers. These software process huge amount of data and we must produce new versions on a regular basis. Our customers have invested a lot of money in large computers which are consequently accurately sized for our software. If the generated code becomes poor, then the customers must invest in larger systems, which is not acceptable on a commercial point of view. So, yes, the performance of the generated code is not important for hobbyists, educational institutions, GUI software, desktop tools, etc. But, for commercial industrial software products, it is essential. > I know few developpers linking just once a day. > For us, the difference between 20s and 4mns for linking is more than > important (we actually saw that difference between some compilers for > same code and executable) I agree. But it is also true that many Ada tools (including compilers) are written in Ada. So, improving the compile time is simply a nice side effect of improving the generated code performance. BTW, I also noticed the same magnitude of difference between compilers, maybe we used the same two... -Thierry ________________________________________________________ Thierry Lelegard, Paris, France E-mail: lelegard@club-internet.fr ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: WinNT ADA compilers comparison 2000-07-22 0:00 ` Thierry Lelegard @ 2000-07-24 0:00 ` Nicolas Brunot 2000-07-25 0:00 ` G. de Montmollin 2000-07-26 0:00 ` Laurent Guerby 0 siblings, 2 replies; 20+ messages in thread From: Nicolas Brunot @ 2000-07-24 0:00 UTC (permalink / raw) > >But, on a code generator point a view, there is no difference > >in optimizing from 5s to 1s and from 5ms to 1ms. The first case > >is most of the time (roughly) a loop of 1000 iterations of the > >second case in the source code. I don't completely agree on that. when I talk about optimizing from 5s to 1s, or from 5ms to 1 ms, this usually concerns completely different code part, and of course, this optimization must concern the total amount of time that the user is waiting after his command (and I was talking about software with important GUI where ease of use of GUI is much more important than time computation to get the result expected) > >The quality and speed of the generated code is an instrinsic > >quality of a compiler. To address the full range of applications, > >a compiler must make it right. Let me briefly describe two cases > >I experienced where it made all the difference: I think that quality and speed of the same compiler can change a lot depending on the kind of ADA feature and syntax you use. (simple ADA83 compatible syntax, tasks, tagged type etc ...) One very good compiler for one purpose can be very bad for another. We unfortunately had to deal with compiler trying to be excellent in one field (float computation) and by consequence being very poor in reliability when interfering with others libraries. If you are concerned by executable size for example, even with optimization and strip, for example, we get gnat executable size incredibly huge in comparison even with old ADA83 compiler (40 Mo instead of 8 Mo !!!) > >So, yes, the performance of the generated code is not > >important for hobbyists, educational institutions, GUI > >software, desktop tools, etc. But, for commercial > >industrial software products, it is essential. I don't know what you mean by commercial industrial software, but we develop CAD and database Oracle application we call commercial (because we sell them) and industrial (because we try to have an industrial approach of software developping). We talked with some people developping in ADA, and obviously we don't have at all the same needs concerning compiler feature and reliability than people developping embedded system for example. For us, the speed of the application (not of code executable ..., that's not always the same thing) depends much more on the way you write the application, than on the code speed generated by the compiler. Especally in CAD, a good and well thought GUI can help the user win 1000 more time than a compiler generating 10 times faster code. What we expect from the compiler is to be reliable, fast to link (more than fast to compile) and above all, be reliable enough so we don't need support or patches (We still use an ADA83 compiler and we never had to call suppor not even once in 6 years for about 1 million lines ADA code, and today no ADA95 compiler is good enough to replace it) For our applications we absolutely don't care about a compiler generating float operation twice faster, that would be of absolutely no use for our customers. But a compiler simple robust with no problem (even if it's not the best generated code) and fast link, allows us to develop much faster and provide really useful improvement for the customer. Nicolas BRUNOT ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: WinNT ADA compilers comparison 2000-07-24 0:00 ` Nicolas Brunot @ 2000-07-25 0:00 ` G. de Montmollin 2000-08-02 0:00 ` n_brunot 2000-07-26 0:00 ` Laurent Guerby 1 sibling, 1 reply; 20+ messages in thread From: G. de Montmollin @ 2000-07-25 0:00 UTC (permalink / raw) Nicolas Brunot wrote: > If you are concerned by executable size for example, even with optimization and > strip, for example, we get gnat executable size incredibly huge in comparison > even with old ADA83 compiler (40 Mo instead of 8 Mo !!!) Strange - it ressembles to the GNAT / Alsys ratio on large projects... But: did you apply the -gnatp option ? The mass of code generated by GNAT (an generally by GCC), even with effective optimisations, stripping etc., still intrigues me. Of course, basically GCC was surely developed in a protected world with Unix stations having "unlimited" storage, and without commercial worries, but does anyone know what is all that stuffing ?... ______________________________________________________ Gautier -- http://members.xoom.com/gdemont/gsoft.htm ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: WinNT ADA compilers comparison 2000-07-25 0:00 ` G. de Montmollin @ 2000-08-02 0:00 ` n_brunot 0 siblings, 0 replies; 20+ messages in thread From: n_brunot @ 2000-08-02 0:00 UTC (permalink / raw) Storage start to be not so unlimited when you reach sizes of more than 40 or 50 Mo ... In article <397DC549.250331FF@maths.unine.ch>, "G. de Montmollin" <gautier.demontmollin@maths.unine.ch> wrote: > Nicolas Brunot wrote: > > > If you are concerned by executable size for example, even with optimization and > > strip, for example, we get gnat executable size incredibly huge in comparison > > even with old ADA83 compiler (40 Mo instead of 8 Mo !!!) > > Strange - it ressembles to the GNAT / Alsys ratio on large projects... > But: did you apply the -gnatp option ? > > The mass of code generated by GNAT (an generally by GCC), even with > effective optimisations, stripping etc., still intrigues me. > Of course, basically GCC was surely developed in a protected world > with Unix stations having "unlimited" storage, and without commercial > worries, but does anyone know what is all that stuffing ?... > > ______________________________________________________ > Gautier -- http://members.xoom.com/gdemont/gsoft.htm > Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: WinNT ADA compilers comparison 2000-07-24 0:00 ` Nicolas Brunot 2000-07-25 0:00 ` G. de Montmollin @ 2000-07-26 0:00 ` Laurent Guerby 2000-08-02 0:00 ` n_brunot 1 sibling, 1 reply; 20+ messages in thread From: Laurent Guerby @ 2000-07-26 0:00 UTC (permalink / raw) Nicolas Brunot <n.brunot@cadwin.com> writes: > [...] If you are concerned by executable size for example, even with > optimization and strip, for example, we get gnat executable size > incredibly huge in comparison even with old ADA83 compiler (40 Mo > instead of 8 Mo !!!) [...] Hmmm, do you have lots of generics? If the old compiler implements shared generics and given that GNAT doesn't, that could be a reason for the size difference. BTW, did you try "-Os"? It asks GCC to try to avoid optimizations that increase code size. Also, what is the platform here? -- Laurent Guerby <guerby@acm.org> ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: WinNT ADA compilers comparison 2000-07-26 0:00 ` Laurent Guerby @ 2000-08-02 0:00 ` n_brunot 2000-08-02 0:00 ` gdemont 2000-08-15 4:56 ` Robert I. Eachus 0 siblings, 2 replies; 20+ messages in thread From: n_brunot @ 2000-08-02 0:00 UTC (permalink / raw) I use deja.com since I'm currently in Japan and have problems accessing newsgroup from my usual account. Platform is WinNT 4 with Gnat 3.12p we tried a lot of optimisation, strip etc ... In comparison to others compilers (not only Alsys ADA83) Gnat produces incredibly huge executables when you make intensive use of generics (using a lot of generics is a quite normal and desirable thing in ADA according to us) We of course use generics (and generics of generics ....) which is may be one of the most important and powerful ADA features, allowing you not spending your time writing more or less the same code, and keep strong compiler check. reaching sizes of more than 40 or 50 Mo start to be a real inconvenient when others compilers are 4 or 5 times smaller Nicolas BRUNOT In article <86zon5aio7.fsf@acm.org>, Laurent Guerby <guerby@acm.org> wrote: > Nicolas Brunot <n.brunot@cadwin.com> writes: > > [...] If you are concerned by executable size for example, even with > > optimization and strip, for example, we get gnat executable size > > incredibly huge in comparison even with old ADA83 compiler (40 Mo > > instead of 8 Mo !!!) [...] > > Hmmm, do you have lots of generics? If the old compiler implements > shared generics and given that GNAT doesn't, that could be a reason > for the size difference. BTW, did you try "-Os"? It asks GCC to try to > avoid optimizations that increase code size. > > Also, what is the platform here? > > -- > Laurent Guerby <guerby@acm.org> > Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: WinNT ADA compilers comparison 2000-08-02 0:00 ` n_brunot @ 2000-08-02 0:00 ` gdemont 2000-08-03 0:00 ` n_brunot 2000-08-15 4:56 ` Robert I. Eachus 1 sibling, 1 reply; 20+ messages in thread From: gdemont @ 2000-08-02 0:00 UTC (permalink / raw) Nicolas BRUNOT: > Platform is WinNT 4 with Gnat 3.12p > we tried a lot of optimisation, strip etc ... Did you avoid inlining (-gnatn or -gnatN) too ? A solution would be to share more instanciations of generics e.g. having common subtypes. Create 1-line packages for those generic ones used many times: "with such_generic; package such_inst is new such_generic(x,y,z);" If there are many main procedures p1, p2,... (-> several linked executables p1.exe, p2.exe) using almost the same packages, shell them through a common one "with p1,p2,...; procedure p is..." > In comparison to others compilers (not only Alsys ADA83) Gnat produces > incredibly huge executables when you make intensive use of generics > (using a lot of generics is a quite normal and desirable thing in ADA > according to us) > > We of course use generics (and generics of generics ....) which is may > be one of the most important and powerful ADA features, allowing you > not spending your time writing more or less the same code, and keep > strong compiler check. > > reaching sizes of more than 40 or 50 Mo start to be a real inconvenient > when others compilers are 4 or 5 times smaller And what makes you unhappy with the Ada95 compilers other than GNAT ? G. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: WinNT ADA compilers comparison 2000-08-02 0:00 ` gdemont @ 2000-08-03 0:00 ` n_brunot 2000-08-03 0:00 ` Brian Rogoff 0 siblings, 1 reply; 20+ messages in thread From: n_brunot @ 2000-08-03 0:00 UTC (permalink / raw) In article <8m9a08$pu7$1@nnrp1.deja.com>, gdemont@my-deja.com wrote: > Did you avoid inlining (-gnatn or -gnatN) too ? > A solution would be to share more instanciations of generics > e.g. having common subtypes. Create 1-line packages for those > generic ones used many times: > "with such_generic; package such_inst is new such_generic(x,y,z);" > If there are many main procedures p1, p2,... > (-> several linked executables p1.exe, p2.exe) > using almost the same packages, shell them through a common one > "with p1,p2,...; procedure p is..." We try not introducing any changes in our specifications and tools just to satisfy one compiler if all others are happy with a perfectly satisfying code (especially a compiler we don't use for release version) We prefer to wait that the compiler works fine with code ok for all others compilers. We always check our code with several compilers in order to keep our code as much independant as possible from the compiler, even for one single platform. Some compilers don't have the same behavior, and a perfectly bad code can work very well on a very good compiler. It's a very good way to chase bad or non portable code with this method, and it's doesn't make you lose a lot of time (and you win a lot) gnat 3.12p is one we use to check our code, but anyway it is unusable for our applications due to its very poor reliability when components of foreign code are called under WinNT, (see discussion for float_io.put on gnat chat july archives www.gnat.com) Gnat works in a very different way than others compilers which makes it a good check tool even if we don't use it for release versions. Of course a (very expensive) supported version exists, and bugs could be quickly solved, but we think it's not a good thing that support is needed for basic reliability problems . Compiler vendor often forget than even if their support answers and provides a patch in less than 1 hour, the time to detect the problem (especially hardly noticeable ill behavior without warning or crash, and especially if it's detected after official release), isolate it, contact support, get the patch, make a new version of your application, providing it to your customers, is of incredibly high cost. It's much better to have a not so good support you need once every two years, than an excellent support you need every 3 monthes. > > And what makes you unhappy with the Ada95 compilers other than GNAT ? > > G. Currently we have more than 1 million ADA lines code compiled with an ADA 83 compiler. We never need any support in 5 or 6 years. We test several compilers to switch to ADA95 (our code is designed so we have very few specific units requiring different code for ADA83 and ADA95) and we are not in a hurry. Nothing makes us unhappy with others ADA95 compilers We just take the time to check internally our softs compiled with others compilers, and compare the easy of use, time required to compile, link etc ... Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: WinNT ADA compilers comparison 2000-08-03 0:00 ` n_brunot @ 2000-08-03 0:00 ` Brian Rogoff 2000-08-03 0:00 ` tmoran 2000-08-04 0:00 ` Robert A Duff 0 siblings, 2 replies; 20+ messages in thread From: Brian Rogoff @ 2000-08-03 0:00 UTC (permalink / raw) On Thu, 3 Aug 2000 n_brunot@my-deja.com wrote: > In article <8m9a08$pu7$1@nnrp1.deja.com>, > gdemont@my-deja.com wrote: > > > Did you avoid inlining (-gnatn or -gnatN) too ? > > A solution would be to share more instanciations of generics > > e.g. having common subtypes. Create 1-line packages for those > > generic ones used many times: > > "with such_generic; package such_inst is new such_generic(x,y,z);" > > If there are many main procedures p1, p2,... > > (-> several linked executables p1.exe, p2.exe) > > using almost the same packages, shell them through a common one > > "with p1,p2,...; procedure p is..." > > We try not introducing any changes in our specifications and tools just > to satisfy one compiler if all others are happy with a perfectly > satisfying code (especially a compiler we don't use for release version) To be clear here, it isn't that GNAT is unhappy (i.e., doesn't work) with your code, it is that you are unhappy with the code size because your original code uses a style suitable with a generic sharing implementation and GNAT implements generics with macro expansion, like C++ compilers, right? I guess I always code to a macro expanding implementation in Ada since I was raised on GNAT, but I see that this is a real issue if you are used to something else. I don't know if GNAT is going to change anytime soon; Robert Dewar mentioned that there is a DEC patent on generic sharing which implementors had to be cautious of. Find the date it was issued, and add 17 to get an idea of when we might hear talk of a generic sharing GNAT ;-) > gnat 3.12p is one we use to check our code, but anyway it is unusable > for our applications due to its very poor reliability when components > of foreign code are called under WinNT, (see discussion for > float_io.put on gnat chat july archives www.gnat.com) OK, that's a different issue. -- Brian ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: WinNT ADA compilers comparison 2000-08-03 0:00 ` Brian Rogoff @ 2000-08-03 0:00 ` tmoran 2000-08-04 0:00 ` Robert A Duff 1 sibling, 0 replies; 20+ messages in thread From: tmoran @ 2000-08-03 0:00 UTC (permalink / raw) >I don't know if GNAT is going to change anytime soon; >Robert Dewar mentioned that there is a DEC patent on generic sharing which >implementors had to be cautious of. Find the date it was issued, and add >17 to get an idea of when we might hear talk of a generic sharing GNAT ;-) Janus Ada was using code sharing generics when I first used it about a dozen years ago (they targetted PCs, which then had small RAM). ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: WinNT ADA compilers comparison 2000-08-03 0:00 ` Brian Rogoff 2000-08-03 0:00 ` tmoran @ 2000-08-04 0:00 ` Robert A Duff 1 sibling, 0 replies; 20+ messages in thread From: Robert A Duff @ 2000-08-04 0:00 UTC (permalink / raw) Brian Rogoff <bpr@shell5.ba.best.com> writes: > Robert Dewar mentioned that there is a DEC patent on generic sharing which > implementors had to be cautious of. Find the date it was issued, and add > 17 to get an idea of when we might hear talk of a generic sharing GNAT ;-) First of all, the DEC patent covers just one method of generic code sharing. Second of all, there is prior art on that particular method. - Bob ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: WinNT ADA compilers comparison 2000-08-02 0:00 ` n_brunot 2000-08-02 0:00 ` gdemont @ 2000-08-15 4:56 ` Robert I. Eachus 2000-08-16 0:00 ` n_brunot 1 sibling, 1 reply; 20+ messages in thread From: Robert I. Eachus @ 2000-08-15 4:56 UTC (permalink / raw) n_brunot@my-deja.com wrote: > In comparison to others compilers (not only Alsys ADA83) Gnat produces > incredibly huge executables when you make intensive use of generics > (using a lot of generics is a quite normal and desirable thing in ADA > according to us) > We of course use generics (and generics of generics ....) which is may > be one of the most important and powerful ADA features, allowing you > not spending your time writing more or less the same code, and keep > strong compiler check. During the Ada 9X Requirements process, those of us at MITRE who were involved with supervision of government contracts had very few corporate, as opposed to individual comments, on the proposed requirements. The one thing that we all felt strongly about was that there were "shortcomings" in the Ada language that should not be fixed. Why? Because when a project ran into one of these "major problems" with Ada, they would complain about the language, we would get called in, and in most cases a design fix that was very inexpensive AT THAT POINT IN THE PROJECT would eliminate both the major design problem and the problems that the contractor was attributing to the language or the compiler. One simple example is "slow compilation times." If your project is making changes every day that require recompiling a substantial fraction (or all!) of the source code, then the problem is not that Ada has these nasty recompilation rules, it is that your design is not using information hiding correctly, and that the final code will almost certainly be unmaintainable. Another example, and the one that you seem to be tripping over, is proper use of generics. There is noting wrong with generics nested in generics, and generic instantiations that instantiate other generics, etc. But you need to know for each generic and each instantiation whether or not the compiler should do inlining, and where. But isn't that an implementation detail you say? Sure it is, and it is nice that the Ada language is designed so that changing those decisions can be done by changing a couple of pragmas in the source code. But the decisions that can and should be delayed until later in the project do not include code size limitations and timing of key threads. Those issues need to be thought out during the preliminary design process and communicated to all members of the team, not just to the design team. If those broad brush decisions are made correctly, and communicated to the team, you won't have either code bloat or slow execution surprises. But no matter how intelligent the compiler is on the issue of inlining and generics, the compiler doesn't know what the intent of the design team is. Pragmas and compiler switches can communicate that information to the compiler, but if the design team hasn't considered those issues, how can the compiler be expected to make those decisions correctly. (Also there are cases where what you really want to do is to use generics to express templates, and the body of the generic template needs to be written as a template. The generic subprogram, or more usually, the subprograms in a generic package, will be designed to be inlined, but most or all of the actual code will be in subprograms that are non-generic, and not inlined. The Gnat Text_IO library has some good examples of this.) So if your compiler is making incorrect implementation decisions, the fault is usually not in the compiler, but in the directions that it is given. And even when the compiler is guessing right, you should still tell the compiler what to do, and document it carefully, if the decision is a key part of the overall design. This is why the usual advice is to use pragmas, often with very restricted scopes, rather than compile-time switches. The pragma puts the documentation where it belongs--and will be seen by maintainers. This is one reason why pragmaa Unsuppress is being standardized. It allows the programmer to document that a particular exception is an expected part of this piece of code, and any necessary checks should made here, even if the check is turned off globally by a pragma or by a compile-time switch. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: WinNT ADA compilers comparison 2000-08-15 4:56 ` Robert I. Eachus @ 2000-08-16 0:00 ` n_brunot 0 siblings, 0 replies; 20+ messages in thread From: n_brunot @ 2000-08-16 0:00 UTC (permalink / raw) "Robert I. Eachus" <rieachus@earthlink.net> wrote: > One simple example is "slow compilation times." If your project is > making changes every day that require recompiling a substantial fraction > (or all!) of the source code, then the problem is not that Ada has these > nasty recompilation rules, it is that your design is not using > information hiding correctly, and that the final code will almost > certainly be unmaintainable. In a software development company, making code changes is your dayly job. I talked about compiling, but above all, binding and linking time, because as far as I know, we have to bind and link after the slightest code change ... I don't know if our code design is good, but we've been very successfully maintaining it for more than 10 years, and hope to continue ... > Another example, and the one that you seem to be tripping over, is > proper use of generics. There is noting wrong with generics nested in > generics, and generic instantiations that instantiate other generics, > etc. But you need to know for each generic and each instantiation > whether or not the compiler should do inlining, and where. > I wasn't talking about proper or improper use of generics in ADA, but just noticing that Gnat executables are incredibly huge in comparison with others compilers when you use generics. We don't develop compilers and don't intend to do it, we just compare available ones, and choose the one which best meet our needs ... From the compiler user point of view, If everything else is equal, providing 8 Mo executable is of course better than providing 40 Mo executable > But isn't that an implementation detail you say? Sure it is, and > it is nice that the Ada language is designed so that changing those > decisions can be done by changing a couple of pragmas in the source > code. But the decisions that can and should be delayed until later in > the project do not include code size limitations and timing of key > threads. Those issues need to be thought out during the preliminary > design process and communicated to all members of the team, not just to > the design team. > About preliminary design process, I think that everybody agree on what should be done, and what anybody writing software must try to reach. But unfortunately, theory is sometime not applicable in the real world. I know some (a lot ?, all ?) cases where perfect theory would indefinitely command to start again the project which therefore would never get out the development team. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2000-08-16 0:00 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-07-20 0:00 WinNT ADA compilers comparison Nicolas Brunot 2000-07-20 0:00 ` tmoran 2000-07-20 0:00 ` Stephen Leake 2000-07-20 0:00 ` Pascal Obry 2000-07-20 0:00 ` Thierry Lelegard 2000-07-20 0:00 ` Lionel Draghi 2000-07-21 0:00 ` Nicolas Brunot 2000-07-22 0:00 ` Thierry Lelegard 2000-07-24 0:00 ` Nicolas Brunot 2000-07-25 0:00 ` G. de Montmollin 2000-08-02 0:00 ` n_brunot 2000-07-26 0:00 ` Laurent Guerby 2000-08-02 0:00 ` n_brunot 2000-08-02 0:00 ` gdemont 2000-08-03 0:00 ` n_brunot 2000-08-03 0:00 ` Brian Rogoff 2000-08-03 0:00 ` tmoran 2000-08-04 0:00 ` Robert A Duff 2000-08-15 4:56 ` Robert I. Eachus 2000-08-16 0:00 ` n_brunot
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox