doelz@urz.unibas.ch (Reinhard Doelz) (02/24/90)
Hi , we are about rewriting our graphics application in order to tune code. We have some own object-oriented modules which would fit pretty nicely in C++ structures. However, as tuning is the ultimate target, does anyone know about * C++ performance in comparison to 'plain' C modular structures * possibility to complile/link/debug/pixie C++/C mixed code * Optimizer issues: problems with O3? * System resources: more than 'usual' - ? (We got only 16 megs on a 120). * C++ and power vision calls I'd appreciate any hints. Regards, Reinhard
ciemo@bananapc.wpd.sgi.com (Dave Ciemiewicz) (02/26/90)
In article <205*doelz@urz.unibas.ch>, doelz@urz.unibas.ch (Reinhard Doelz) writes: > Hi , > we are about rewriting our graphics application in order to tune code. > We have some own object-oriented modules which would fit > pretty nicely in C++ structures. However, as tuning is the > ultimate target, does anyone know about > > * C++ performance in comparison to 'plain' C modular structures It really does depend on your application and how you implement your C++ classes and how you previously implemented the same data abstractions in 'plain' C. For instance, the use of C++ derived classes and virtual member functions can produce faster code than might be equivalently implemented using a data type tag and switch statement in C. Judicious use of C++ inline functions can also speedup some code. Unfortunately, no one can give you a pat answer one way or another. There have been some claims made on comp.lang.c++ though I haven't followed those discussions in awhile. > > * possibility to complile/link/debug/pixie C++/C mixed code > > * C++ and power vision calls C++ was designed to be fairly compatible with existing C++ code. C++ code can directly call the C-GL routines for instance, including the new POWERVision calls. The IRIX dbx has been extended to provide help in debugging C++ code. For instance, it does name-demangling of member variables. It doesn't do name demangling of function names though for SGI's C++ 1.0 (AT&T v1.2.1). We have used pixie extensively in-house in conjunction with in-house developed C++ applications like the IRIS WorkSpace(TM) and wsh, the window shell. > > * Optimizer issues: problems with O3? The AT&T C++ Translator from SGI just produces C code. There should not be any problems with using -O3 optimization. > > * System resources: more than 'usual' - ? (We got only 16 megs on a 120). C++ tends to be very data intensive. Experience with C++ shows that sometimes people over develop classes and throw unnecessary information into the classes. After a couple of levels of derivation, an instance of a class can be larger than you would expect. This requires the programmer to think about their data abstractions a little more than they might of in the past. Another area to be aware of is text space locality. C++ derived classes are typically implemented in there own files. After a couple layers of derivation, a call to a member function of a derived might be implemented to make references to base class functions. This is usually true of class constructors and destructors. This can sometimes result in less than optimal VM paging performance. Of course, this is true of any application which calls functions in many different modules. Some performance gains can be made by using pixie(1) and cord(1) to rearrange the functions in text space so that functions which call each other a lot are next to (or close to) each other. This can reduce the VM resident set size requirements of any application, not just applications written in C++. > > I'd appreciate any hints. > Regards, > Reinhard I'm personally involved in a development project here at SGI using C++. I also have friends at other companies who are doing development in C++. All of them agree that you don't just learn C++ overnite, even with an extensive background in C. There is a learning curve associated with the transition to C++. This includes understanding efficiency design considerations. However, almost all of them prefer working in C++ versus 'plain' for object-oriented development. Good luck! --- Ciemo
ciemo@bananapc.wpd.sgi.com (Dave Ciemiewicz) (02/26/90)
After some sanity checking by a fellow engineer, I must clarify a few points. In article <4534@odin.SGI.COM>, ciemo@bananapc.wpd.sgi.com (Dave Ciemiewicz) writes: > In article <205*doelz@urz.unibas.ch>, doelz@urz.unibas.ch (Reinhard > Doelz) writes: > > Hi , > > we are about rewriting our graphics application in order to tune code. > > We have some own object-oriented modules which would fit > > pretty nicely in C++ structures. However, as tuning is the > > ultimate target, does anyone know about > > > > * C++ performance in comparison to 'plain' C modular structures > > It really does depend on your application and how you implement your C++ > classes and how you previously implemented the same data abstractions in > 'plain' C. For instance, the use of C++ derived classes and virtual member > functions can produce faster code than might be equivalently implemented > using a data type tag and switch statement in C. Judicious use of C++ inline > functions can also speedup some code. > > Unfortunately, no one can give you a pat answer one way or another. There > have been some claims made on comp.lang.c++ though I haven't followed those > discussions in awhile. Including me. The sanity check of a test program definitely showed me that switch statements can produce faster code than using virtual functions and not as I claimed in the prior message. However, maintaining the code which uses the virtual functions is easier. By-the-by, I just proved this to myself using C++ and pixie. Sigh. More proof you can't rely on hearsay to see that one thing is faster than another. The proof is in the profile. > > > > * Optimizer issues: problems with O3? > > The AT&T C++ Translator from SGI just produces C code. There should not be > any problems with using -O3 optimization. > There is an issue concerning -O3 optimization. -O3 and -c are mutually exclusive with the MIPS cc. The C++ translator uses the -c flag in the creation of object code. Hence, you will need to have C++ generate the intermediate ..c files and then manually compile them together using cc -O3. Ugly, but it will still provides the -O3 optimization. --- Ciemo
kipp@warp.esd.sgi.com (Kipp Hickman) (02/27/90)
We did some performance tests with C++, running the most recent version of the dhyrstone tests through the C++ compiler. The results were identical to the standard C numbers. We even tweaked the tests to use C++ language features and were able to improve the numbers. The trick with C++ is to use it "effectively". There are pieces of your code that aren't performance critical - you can use C++ fully here, without worry. Other sections of your code will be highly critical - use C++, but use it carefully, so that it is generating the same old fast C code. A good thing to avoid if you have a performance critical section is subroutines. (this is true for C too) The mips compilers will optimize the #@$(&#@&$ out of the code, as long as a subroutine isn't called (that way it knows it can safely put memory cells into registers, etc.). Hope this helps. kipp hickman silicon graphics inc.