From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9adfbb907494972e X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,9adfbb907494972e X-Google-Attributes: gid1014db,public From: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) Subject: Re: Ada to C/C++ translator needed Date: 1996/10/01 Message-ID: <52q7lq$qqu@goanna.cs.rmit.edu.au> X-Deja-AN: 186390007 references: <32499FA0.4B5E@magic.fr> <52e5t5$m28@btmpjg.god.bel.alcatel.be> <52feul$os2@goanna.cs.rmit.edu.au> <01bbad6e$67743f20$32ee6fcf@timhome2> <52o1ve$gra@goanna.cs.rmit.edu.au> <01bbaee1$00ee1c20$87ee6fce@timpent.a-sis.com> organization: Comp Sci, RMIT, Melbourne, Australia newsgroups: comp.lang.c,comp.lang.ada nntp-posting-user: ok Date: 1996-10-01T00:00:00+00:00 List-Id: "Tim Behrendsen" writes: >I would conclude that for that *specific* problem, the C compiler >did a bad job of optimization. As I frequently point out (and >I frequently get abuse for it), optimizers are very imperfect >beasts at best. Well, it all depends on what you mean by a "bad" job of optimisation. I actually tried several compilers, and the Sun C compiler was one of the *best*. If you call being 3rd out of 10 "a bad job", if you call taken 1.2x the time of the very best but 0.2x the time of the very worst "a bad job", then you have made your point. >Do you doubt that if we brought the writers of the Sun compiler >and had them fix their optimizer, they couldn't make it produce >*exactly* the same code as the Ada compiler (or Fortran compiler, >for that matter)? Of course they could. You are wrong. Of *course* I doubt it, and so does anyone who understands how compilers work. Compilers have to respect the semantics of the languages they compile. They cannot take shortcuts that might produce incorrect results. Until the 'restrict' keyword is a standard part of C, which it soon will be, but currently isn't, a C compiler will not be *allowed* to pull the kinds of tricks that the Fortran compiler did in this example. >The real question that you refuse to come to terms with is, what >is the average case over a large set of compilers over a large set >of non-trivial programs over a large set of problem types? And >this is a very difficult question to answer. I refuse to come to terms with it, because there can be no useful or meaningful answer to it. - tests over a wide range of problem types are of absolutely no interest to the person who started this thread; that person has ONE program and was considering converting from Ada to C. Suppose your impossible average were that Ada was 1.2 times faster than C. Would that tell the person who has a specific problem whether to use Ada or C? OF COURSE IT WOULDN'T. - tests over a wide range of compilers are of absolutely no interest. I can bias the results any way I want by insisting on the inclusion of enough bad compilers. And the results are of no interest at all to the original poster who simply isn't concerned with _all_ Ada compilers or _all_ C compilers. - insisting on a wide range of compilers is a profoundly dishonest thing for you to do. My claim is that there is *one* free Ada compiler which in my admittedly limited experience routinely does as well as or better than the *best* C compiler I have available to me. (Believe me, the Sun C compiler has a *good* optimiser, and if I were trying to develop graphics code exploiting the VIS opcodes I couldn't ask for a better.) This fact *is* of interest to the poster who started the thread: there is a *free* Ada compiler which does very well; it doesn't *MATTER* what other Ada compilers do. I have been trying very hard to stick to the topic of this thread, which has nothing to do with whethere Ada is *always* better than C or not, but only with whether it would make economic sense to convert from Ada to C when there is a very good free Ada compiler. - tests over a large set of non-trivial programs would be of interest *in the general case*. But I am concerned with the person who was thinking about converting *one* program to C. Again, you can get any results you want by insisting on suitably biassed programs. There is a lot of seriously inefficient code out there. Can you not get it through your head that I was not stating any general proposition, but simply saying that I saw no obvious reason why _one_ program should be converted from Ada to C, and giving a *supporting example*? >Your suggestion that comparing compilers on one platform for >one program tells you something significant is laughable at >best. You may not think it significant that a free compiler for a robust language outperforms a non-free compiler for a less expressive and less robust but more popular one. I do. If you don't think the obvious implication (get GNAT and try it on _your_ program and see if you like the performance), then laugh away, but the laugh's on you. >Sounds like it's a crappy C optimizer to me, especially considering >the wide disparity between the C results and the other languages. What "wide" disparity? The smallest time in the set was 25 seconds. The largest time was 141 seconds. The C time was 30 seconds. (And to the best of my belief, it uses the *same* optimiser as the Fortran compiler!) The machine where I did the tests has been upgraded. gcc -O6 14 seconds Sun cc -xO4 12 seconds If you want to call the SPARCompiler optimiser "crappy", what words will you find for the GCC one? >*This* is a reasonable conclusion. Your conclusion that the SPARCompiler C optimiser is "crappy" is not a reasonable one. *You* will have to provide some data if you want to make _that_ claim. >If you have bothered to write >other programs in C and Ada, that would indicate to me that they >were trivial algorithms, and therefore your conclusions invalid. I see. If someone *does* do head to head comparisons, they are necessarily trivial and therefore invalid. >Look at it this way; if I implement an algorithm in two languages, >C and C++, and compare the results, they will probably be very >similiar (if not identical). The GCC compiler's output is as much slower on this platform as the Sun C compiler's output is slower than the Sun Fortran 77 compiler's. You called 20% a "wide disparity" and the sign of a "crappy" optimiser. But there is as much difference between compilers for the *same*' language as there is between good compilers for *different* languages. Let this stand as a generalisation I *would* be prepared to defend: if a head to head comparison between compiler A for language X and compiler B for language Y on the platform of interest to you does not find a difference in excess of 20%, it is not worth your while converting from the _apparently_ slower language to the _apparently_ faster language. (There are of course exceptions in embdedded and real-time programming.) I can see no reason to expect C++ performance to be as good as C performance in general. Compiler writers have enough on their hands trying to cope with an extremely complex language which has historically been changing faster than compilers could keep up, I count it a miracle when a C++ compiler generates _working_ code for a C++ program. Let's just get a data point: cc 12 seconds \ from Sun CC 13 seconds / from Sun (NOT cfront) This is comparable to the difference I reported between C and Ada, and it's the _same_ source file. >However, let's take a very large >project with two teams of people, and have 1 implement the project >using C, and one implement it using C++. As soon as you have a very large project, you have extremely great variations between programmers. As soon as you deal with C++, you have to cope with immature compilers, severe porting problems, and other problems. >I have no formal study for this, but speaking to many people who >have gone through the process, and reading a lot about many >manager's experiences, I have heard a common theme: Projects >implemented using OOP within the C++ language have experienced >significant performance problems because of the overhead of class >structures, heavy dependance on dynamic memory allocation, and the >difficulty in designing good object classes. I have no quarrel with this, except to note that (a) it has absolutely no relevance to the originator of this thread, who was thinking of *converting* an existing Ada program to C. What would that do to performance, portability, and price of maintenance? Those are relevant questions for this thread. (b) you have only given us half the story: Did not use OOP Did use OOP +----------------+----------------+ C | Fewer problems | ???????????? | C++ | ?????????????? | More problems | +----------------+----------------+ What about programs that used OOP in C? It's often enough done. What about programs in C++ that didn't use OOP? That's supposedly a selling point of C++, that it's a "better C". >This is not because of optimization; this is because of the >language and style in which projects are implemented. Now _there_ is a non-sequitur, if ever there was one. Can it be that you are totally unaware of the work that has been done on link-time optimisation of OOP programs to reduce the cost of dispatching? (Not only does this often eliminate dispatching, but that then enables inlining, which permits more optimisations.) As for the costs of dynamic memory allocation, that can be extremely cheap, so why do you think it might not be? Are you unaware of the work on region- based analysis? As for the difficulty of designing good classes, good design is always hard, but having conceded that, what is this supposed to tell the originator of this thread, who was concerned about converting an *EXISTING* program from Ada to C. We have not been told whether it used OOP or not, but if it did, any design has _already_ been done. >Now, this is a significant debatable question. What is? - overhead of class structures? Compared with what? One of the *achieved* design goals of C++ is that you don't have any memory overheads compared with C if you don't explicitly ask for them. Such overheads as may exist depend a great deal on compiler technology. - heavy dependence on dynamic memory allocation? But dynamic memory allocation can be very cheap. UNIX C malloc() implementations have traditionally been very expensive, unless you use mallopt(). A *lot* of work has been done on reducing the costs of dynamic memory allocation, with excellent results, but you would dismiss this as compiler optimisation, and therefore as not worth talking about when it doesn't lead to the result you want. C++ has the notational resources to admit very efficient (but still "manual" and therefore not entirely trustworthy) memory management. - difficulty of good design? What's to debate? Of course it's hard, that's why design patterns and reuse libraries are so important. >Comparing the output >of optimizers is completely worthless to the central question >of whether REAL WORLD projects can be implement efficiently in >a particular language or not. That may be *your* central question, but it was *not* the topic of this thread. Just to say it once again: the initial question was about converting Ada to C, and my question was "why bother? is there any reason to expect it to buy you anything? I don't think so." Can real world projects be implemented efficiently in Ada? Well, if you insist that anything I can write must be trivial and my conclusions invalid, I shall have to leave that to other people to answer. -- Australian citizen since 14 August 1996. *Now* I can vote the xxxs out! Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.