grunwald@uiucdcsm.cs.uiuc.edu (05/14/88)
I've (finally) gotten my simulation environment to run under both C++ and G++ and measure the performance of those systems. I think that this is a more ``realistic'' measure of compiler performance than using dhrystones. The program simulates a certain form of circuit switching hardware for a hypercube computer. There are 32 nodes in the simulated system. Each node has 1 CPU, 1 IOP, 5 RECV and 5 XMIT processes, meaning a total of 384 simulated processes. The simulation library (not the application), tries to make heavy use of ``inline'' facility for key data types, in particular the Heap & Fifo data types. When I switched from using the OOPS 'fifo' to less general FIFO, I got a 20% speed up. When I switched from the OOPS 'heap', I got a 30% speed up (over the 20% already gained). This isn't to impress you, it's only to show that some care was taken to use C++ features to speed up the total simulation time. There are 4100 lines of code in the simulation library and about 5300 in the particuar application. The application makes extensive (although not excessive) use of virtual functions. It's uses a fair amount of floating point because time is being measured in fractions of microseconds, and the Pairing Heap used in the event list does floating point comparisons. The time to run the simulation on a Sun 3/260 was: Compiler Time (CPU seconds) ---------------------------------- CC w/gcc 549 G++ 579 CC w/cc -F68881 629 CC w/cc -Fswitch 689 I was using GCC V 1.21, G++ V 1.21.1, CC V 1.2. All compiles used '-O' as the only optimization switch. Now to be fair, it was more fun to use G++. It catches many more bugs than CC does. I did encounter two bugs in G++ which crashed the compiler, but they're being fixed. So, why is G++ slower than CC w/gcc? Good question. I'm going to try to enable various optional optimizations and see what I can find. I don't have any clues yet. If anyone has clues, please reply. The biggest single difference is between using GCC or PCC, with the second major difference being using the -f68881 flag. Dirk Grunwald Univ. of Illinois grunwald@m.cs.uiuc.edu
jima@hplsla.HP.COM ( Jim Adcock) (05/17/88)
Choice of compiler options seems to have a moderate effect on the generated g++ code. Also the local g++ "guru" [whoever made g++ for your system] can choose what compiler options are in or not in "-O", so "-O" may or may not be a particularly "good" choice for your system and your particular application. The g++ options are worth playing with for awhile, in order to get a feel for how they affect a particular application on a particular machine. You can ultimately turn on a lot of optimizations that would affect debugging during code development.
grunwald@uiucdcsm.cs.uiuc.edu (05/17/88)
Here's some more figures on that simulation program. All of these programs were compiled using G++ V 1.21.1. The only difference is the command line options Options Time (seconds) ---------------------------------------------------------------------------- (i) -O 579 (ii) -O -finline-functions 554 (iii) -O -finline-functions -fomit-frame-pointer 546 (iv) -O -finline-functions -fomit-frame-pointer -fcombine-regs 569 So, if you've got production code which you don't intend to debug, G++ using (iii) looks like a good deal. Perhaps the difference between G++ and C++ is that C++ tends to auto inline more functions? It's curious that combine-regs slows things down. That would take some playing around to determine that the problem is. Dirk Grunwald Univ. of Illinois grunwald@m.cs.uiuc.edu
grunwald@uiucdcsm.cs.uiuc.edu (05/20/88)
I installed the stuff as it came out of the box, so to speak. The -finline-functions appears to be worth the effort; the omitting the link frames is definitly something I'd do only after debugging the rest of the program.
jima@hplsla.HP.COM ( Jim Adcock) (05/23/88)
I presume you're running with -m68020 and -m68881 on?