paulb@kulcs.uucp (Paul Busse) (10/25/88)
Hello, We are fairly new users of C++ and are wondering what the run time costs are of using C++ instead of C. - Are their any reports on this item ? - Have you got test results you want to share ? Any pointers ? I've heard that Apollo is (going to have) having a C++ compiler and source code debugger. Is their somebody who has used this or knows something about it ? Please answer by mail. Don't post follow ups. I'll summarize. If there is enough interest, of course. Paul. -------- paulb@kulcs.UUCP |'I don't believe in knights ! That's for ... mcvax!prlb2!kulcs!paulb | fairy tails !' the young dragon said. paulb@blekul60.BITNET | J.R.R. Tolkien -- -------- paulb@kulcs.UUCP |'I don't believe in knights ! That's for ... mcvax!prlb2!kulcs!paulb | fairy tails !' the young dragon said. paulb@blekul60.BITNET | J.R.R. Tolkien
shap@polya.Stanford.EDU (Jonathan S. Shapiro) (10/26/88)
In article <133@icarus.kulcs.uucp> paulb@kulcs.UUCP () writes: > >We are fairly new users of C++ and are wondering what the run time >costs are of using C++ instead of C. > C++ generates C. A properly written program will run in equivalent time. Often better, because the abstraction mechanisms of C++ lend themselves to better structured design.
johnson@p.cs.uiuc.edu (10/26/88)
C++ is just as fast as C (within + or - 2%). We have written an operating system (Choices) in C++ and are getting very good performance figures from it. There is essentially no performance overhead in using C++.
exodus@cheers.uucp (Greg Onufer) (10/27/88)
From article <4675@polya.Stanford.EDU>, by shap@polya.Stanford.EDU (Jonathan S. Shapiro):
> C++ generates C. ......
Wow. What a _broad_ generalization.... But speak for yourself.
My C++ compiler generates native code. I'll assume that you are
speaking about your C++ "compiler" and not of the language in general.
Oh... Gnu C++ is my compiler.
--greg
--
Greg Onufer .. University of the Pacific .. Focus Semiconductor
.. exodus@cheers.uucp .. sun!daver!cheers!exodus .. 415-965-0604snm@horus.gatech.edu (Sathis Menon) (10/28/88)
In article <77300014@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes: > >C++ is just as fast as C (within + or - 2%). We have written an >operating system (Choices) in C++ and are getting very good performance >figures from it. There is essentially no performance overhead in >using C++. OK., you are getting good performance figures from your OS using C++, but did you have a parallel implementation in C to compare it?. Are you implying that the "very good performance figures" that you mention are attibuted to C++ (at least partly)? The distributed OS project that I am working on (Clouds Project at Georgia Tech) is using g++ (GNU C++) to implement the kernel and system objects (essential system services). Unfortunately, the optimizer that we got from GNU folks assumed a little too much, which doesn't go hand in hand with low level coding. Hence, we don't optimize the code right now and the code generated is worse than C code (by checking the assembler listing, of course). One of these days, we have to muster up the courage to give it another shot ... Sathis Menon snm@gatech.edu
jans@tekgvs.GVS.TEK.COM (Jan Steinman) (10/28/88)
<<We are fairly new users of C++ and are wondering what the run time costs are of using C++ instead of C.>> <C++ generates C. A properly written program will run in equivalent time.> This is typical of those who think of C++ merely as a subset of C, however, in order to make best use of its object-oriented features you should count on the run-time overhead that virtual functions, constructors, and destructors impose. If you aren't going to write object-oriented code, stick to C -- it's much simpler. :::::: Software Productivity Technologies -- Experiment Manager Project :::::: :::::: Jan Steinman N7JDB Box 500, MS 50-383 (w)503/627-5881 :::::: :::::: jans@tekcrl.TEK.COM Beaverton, OR 97077 (h)503/657-7703 ::::::
jans@tekgvs.GVS.TEK.COM (Jan Steinman) (10/28/88)
<<We are fairly new users of C++ and are wondering what the run time costs are of using C++ instead of C.>> <C++ generates C. A properly written program will run in equivalent time.> This is typical of those who think of C++ merely as a superset of C, however, in order to make best use of its object-oriented features you should count on the run-time overhead that virtual functions, constructors, and destructors impose. If you aren't going to write object-oriented code, stick to C -- it's much simpler. :::::: Software Productivity Technologies -- Experiment Manager Project :::::: :::::: Jan Steinman N7JDB Box 500, MS 50-383 (w)503/627-5881 :::::: :::::: jans@tekcrl.TEK.COM Beaverton, OR 97077 (h)503/657-7703 ::::::
lean@munmurra.mu.oz (Giles Lean) (10/29/88)
Continuing the C++ efficiency debate, in article <17558@gatech.edu>, snm@horus.gatech.edu (Sathis Menon) says: >In article <77300014@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes: >> >>C++ is just as fast as C (within + or - 2%). We have written an >>operating system (Choices) in C++ and are getting very good performance >>figures from it. There is essentially no performance overhead in >>using C++. > The distributed OS project that I am working on (Clouds Project at > Georgia Tech) is using g++ (GNU C++) to implement the kernel and > system objects (essential system services). Unfortunately, the > optimizer that we got from GNU folks assumed a little too much, > which doesn't go hand in hand with low level coding. Hence, we don't > optimize the code right now and the code generated is worse than C code > (by checking the assembler listing, of course). Firstly, judging the quality of code output by an optimising compiler before the optimising pass is not sensible for assessing the efficiency of a language. The compiler may have offloaded even basic optimisations onto the optimiser. Further, comparing the output from two compilers as a language comparison only makes sense if the compilers are somehow "equivalent" - i.e. both generating the "best" code possible. (Both being very basic generating naive code is not appropriate for an efficiency comparison.) What was the C compiler you compared g++ with? > OK., you are getting good performance figures from your OS using C++, but > did you have a parallel implementation in C to compare it?. Are you > implying that the "very good performance figures" that you mention > are attibuted to C++ (at least partly)? The question is still open - I can't see that you can claim that your g++ code is worse than C code, but only that in this instance the g++ optimiser prevents you using C++ to its fullest. Vote (1) for disableable features in optimisers! Giles Lean My own opinions, which have been wrong before, lean@munnari.oz and I don't have an employer until February! University of Melbourne
shap@polya.Stanford.EDU (Jonathan S. Shapiro) (10/29/88)
In article <4165@tekgvs.GVS.TEK.COM> jans@tekgvs.GVS.TEK.COM (Jan Steinman) writes: ><C++ generates C. A properly written program will run in equivalent time.> > >This is typical of those who think of C++ merely as a superset of > C.. I was involved in writing one of the early major applications at AT&T in C++. I know, better than most C++ programmers, just how and where and *why* C++ is different from C. Your points about virtual functions are valid, but it is worth noting that the same functionality in C requires the same mechanism that C++ uses. If you didn't have constructors, you would do the initialization yourself. Similarly for destructors, but you would have poorer locality of control for optimizing that action. If you don't need to use object oriented programming, it makes sense to stick to C - it is at this point more portable (though it doesn't look as though that will be true long). If you do need object oriented programming, the tradeoff between C++ and SmallTalk/Lisp/Eiffel is control versus garbage collection. I can get a lot of performance out of C that I could never get out of any of the others (and I am a more than competent LISP and SmallTalk hacker - that's not the source of the breakdown). On the other hand, there are some times when you really want garbage collection and the ability to be faster and looser about storage management, or you want to let the reachability (i.e. GC) algorithm decide for you when to free storage. C++ is just as fast as C. Anything you want to do in C++ generates code that is no more complicated than the equivalent C code would need to be to do the same job. Griping that virtual functions have run time overhead is irrelevant - so do pointers to functions in C. In fact, as native code compilers become available for C++, it is reasonable to expect that C++ will outperform C because the compiler can take advantage of the "tricks" that are enabled by knowing the differences in semantics and usage between C and C++. Jonathan S. Shapiro AT&T Bell Laboratories
bs@alice.UUCP (Bjarne Stroustrup) (10/29/88)
tekcrl.TEK.COM writes > in order to make best use of its object-oriented features you should count on > the run-time overhead that virtual functions, constructors, and destructors > impose. However, this ``overhead'' may actually not be ``overhead'' compared with the code you have to write in a traditional C program doing a similar job: See Vince Russo's paper about a Scheme interpreter written in C and then rewritten in C++ using a basic object-oriented style. The rewrite was done because of a bet that ``C++ with an OO style isn't much slower than C''. Russo won: the C++ program consistently ran faster. I especially enjoyed Russo's comments that ``it was easy to see how to improve the algorithms to make the progem run MUCH faster, but we didn't do that because that would have been cheating'' (or words to that effect). The paper can be found in the proceedings of the Denver USENIX C++ conference.
jss@hector.UUCP (Jerry Schwarz) (10/30/88)
In article <4164@tekgvs.GVS.TEK.COM> jans@tekgvs.GVS.TEK.COM (Jan Steinman) writes: > If you aren't going to write object-oriented code, stick to C -- it's much >simpler. > I completely disagree with this advice. There are many ways in which C++ makes writing programs easier even if you don't use virtual functions, or only use them sparingly. (And virtuals can be used for styles other than object-oriented). Jerry Schwarz AT&T Bell Labs, Murray Hill
newsuser@LTH.Se (LTH network news server) (10/31/88)
In article <4762@polya.Stanford.EDU> shap@polya.Stanford.EDU (Jonathan S. Shapiro) writes: >I am a more than competent LISP and SmallTalk hacker Furthermore, Jonathan Shapiro is probably a more than competent C++ hacker. Unless you know perfectly what you are doing, you may for example initialize variables twice. The ``error'' I typically do is as follows: In a class constructor I initialize members by assigning values to them. The problem is that some members are class objects with constructors; these objects are first automatically initialized with default values, which are then thrown away because I make the assignments. >C++ is just as fast as C. Anything you want to do in C++ generates >code that is no more complicated than the equivalent C code would need >to be to do the same job. My C++ generates a fair number of temporary variables in the C code it produces. I understand that these temps are required to guarantee the semantics of C++, but unfortunately, my C compiler on the Sun can't eliminate the redundant assignments. I also suffer some space overhead. Looking at the generated assembler code, I believe it would be safe to remove some instructions, but I don't bother. My general, unscientific, impression is that you may loose about 5% in execution speed when you make a quick port from C to C++. Dag Bruck -- Department of Automatic Control Internet: dag@control.lth.se Lund Institute of Technology UUCP: ...!enea!control.lth.se!dag P. O. Box 118 S-221 00 Lund, SWEDEN Phone: +46 46-108779
english@panarea.usc.edu (Joe English) (11/01/88)
In article <4164@tekgvs.GVS.TEK.COM> jans@tekgvs.GVS.TEK.COM (Jan Steinman) writes: >[...] however, in >order to make best use of its object-oriented features you should count on the >run-time overhead that virtual functions, constructors, and destructors impose. > If you aren't going to write object-oriented code, stick to C -- it's much >simpler. Why do constructors and destructors impose run-time overhead? It doesn't matter whether or not your code is "object-oriented," (whatever that might mean) you still have to initialize, and you still have to clean up. Either you do it by hand or the compiler does it for you, but it still has to be done. True, a virtual function call has more overhead than a standard call, but you can only make a standard function call when you know what type of object you're operating on. In many case where virtual functions would be appropriate, that overhead must appear many times over in determining the type of the object. (For example, a graphics device driver which supports multiple devices, and every function begins with a big switch() statement to determine which device is selected. Or it could use a function table, which amounts to virtual functions anyway, and is still less efficient.) C was designed to do low-level programming very efficiently. C++ was designed to do high-level programming very efficiently, and the overheads it imposes are minimal. /|/| "If you think this is bad, you should see what it looks like -----< | | Joe English in *here*!" O \|\| english%lipari@oberon.usc.edu
fischer@iesd.uucp (Lars P. Fischer) (11/10/88)
In article <4675@polya.Stanford.EDU> shap@polya.Stanford.EDU (Jonathan S. Shapiro) writes: >C++ generates C. No. C++ is a programming language and programming languages does not generate anything. An *implementation* of C++ might generate C, or Ada, or even machine code (wow :-). Don't confuse language and implementation. -- Lars Fischer, fischer@iesd.dk, {...}!mcvax!diku!iesd!fischer We must remove the TV-induced stupor that lies like a fog across the land. - T. H. Nelson