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=3.2 required=5.0 tests=BAYES_00,RATWARE_MS_HASH, RATWARE_OUTLOOK_NONAME autolearn=no 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: "Tim Behrendsen" Subject: Re: Ada to C/C++ translator needed Date: 1996/10/01 Message-ID: <01bbafad$cbbbb4e0$87ee6fce@timpent.a-sis.com> X-Deja-AN: 186480880 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> <52q7lq$qqu@goanna.cs.rmit.edu.au> content-type: text/plain; charset=ISO-8859-1 organization: A-SIS mime-version: 1.0 newsgroups: comp.lang.c,comp.lang.ada Date: 1996-10-01T00:00:00+00:00 List-Id: Richard A. O'Keefe wrote in article <52q7lq$qqu@goanna.cs.rmit.edu.au>... > "Tim Behrendsen" writes: > >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. Well, now you throw in new information that the problem in question was not able to be optimized due to constraints of the C language. Of course, this is still not relevent to a large project that presumably the original poster has. > >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. Exactly. So why do you think a specific case is any better? [snip] ====================================== > - 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. THANK YOU! You make my point for me. That's all I'm saying, and that's all my original point said. You can't make generalizations about the fellow's large project based on one specific example. ======================================= > 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*? The point is that the supporting example is "profoundly dishonest". What was my only criticism of your post? That you can't make generalizations based on one example. *THAT'S ALL* Just admit it was worthless, and this thread is over. > >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. It is certainly interesting for this one problem, but completely worthless to the general question of whether the fellow would gain anything from conversion of his source code. > >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. Well, perhaps crappy in this one case, unless (as you now point out) the program was written such that the optimizer could not optimize it due to constraints of the C language. > >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. No, if *you* have. Since you haven't brought up any large-scale comparisons, I have to conclude that you haven't done any. If there are any large-scale project comparisons, they may be valid. > >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). [snip long-winded criticism of this statement] You are overgeneralizing my statement. My only point is that they share enough in common that if I implement an algorithm, i.e., a small program v.s. a large project (which I admit I didn't state clearly enough), it will probably get about the same results given similiarly good compilers. This was only meant to be a lead-in into ... > >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. Well, we have to assume a staff of equal competence and equal technology in their respective languages. > >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. This is *extremely* relevent! The point is that even though C++ shares a lot of C's roots, C++ can have scaling problems on real- world projects. Does Ada have the same problems? I DON'T KNOW! All I know is that you can't prove one way or the other based on small test programs in a single environment. > (b) you have only given us half the story: > > 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". Well, what about it? You can ask "what ifs" all day long. Yes, it's possible to have efficient OOP programs, just as it's possible to have readable APL programs. The questions are, how hard is it to make an efficient OOP program, is it worth the additional design cost, and how often do you *still* get a mess even taking all that into account? My point is that based on admittedly anecdotal evidence, it is *extremely* difficult to get to a balance between good class structures and efficient class structures, and some mighty big disasters have been wrought from people who have guessed wrong. > >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? You live in the ivory tower; I live in the real world. You may want to come out and get some fresh air once in a while. If technology comes along such that these problems get solved, then I will embrace it. Until then, why destroy my products in the name of "progress"? > 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. "If you don't ask for them". "Depend a great deal on compiler technology". So, in other words, to be efficient, I have to be extremely careful about what I use and what I don't use, and my portability is limited "a great deal" by the compiler. Again, and admittedly anecdotal, real world experience does not back up your claims. Maybe it will someday. > - 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. Theoretically this may all be true. In the real world, as far as I can see, it has not happened that way. > - difficulty of good design? > What's to debate? Of course it's hard, that's why design patterns > and reuse libraries are so important. Design is always difficult, but class design appears to be particularly difficult to get right. > >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." What do you think the topic of the thread is? You tried to show that converting his Ada code was not a good idea, and gave a specific example to try and show that Ada is not always slower than C. I pointed out that you can't make generalizations based on one example. Your central point is fine; I only take exception to using one small example to make the point. If you had only said, "based on my experience, Ada has proven to be comparably efficient to C", I would not have had a problem with it. The difference is the latter statement is making an opinion based on a base of experience, but your original statement made an opinion based on a specific example, which is invalid. > 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. -SIGH- read back what I said, and don't overgeneralize. -- Tim Behrendsen (tim@a-sis.com)