www.delorie.com/djgpp/v2faq/faq113.html

search

| Previous | Next | Up | Top |

Q: I timed a test program and it seems that GCC 2.8.1 produces slower executables than GCC 2.7.2.1 was, which in turn was slower than DJGPP v1.x. Why are we giving up so much speed as we get newer versions?

Q: I installed Binutils 2.8.1, and my programs are now much slower than when they are linked with Binutils 2.7!

• Compile your code using the GCC switches -O2 -mpentium -fomit-frame-pointer -ffast-math. (For PGCC use -O6 instead of -O2.) Omit -ffast-math if you link with -lm and need the errno variable to be set or the matherr function to be called in case of errors.
• Profile your code and check which functions are "hot spots". Disassemble them, or compile with -S (see getting assembly listing), and examine the machine code.
• If the disassembly shows there aren't too many memory accesses inside the inner loops, try adding -fforce-addr option. This option helps a lot if a couple of pointers are used heavily within a single loop. If there are a lot of memory references, try adding -fno-force-mem, to prevent GCC from repeatedly copying variables from memory into registers.
• Try adding -funroll-loops and -funroll-all-loops and profile the effect.
• Try compiling with -fno-strength-reduce. In some cases where GCC is in dire need of registers, this could be a substantial win, since strength reduction typically results in using additional registers to replace multiplication with addition.
• Sometimes, -fomit-frame-pointer might make things worse, since it uses stack-relative addresses which have longer encoding and could therefore overflow the CPU cache. So try with and without this switch.
• If different time-critical functions exhibit different behavior under some of the optimization options, try compiling them with the best combination for each one of them.

Programs which manipulate multi-dimensional arrays inside their innermost loops can sometimes gain speed by switching from dynamically allocated arrays to static ones. This can speed up code because the size of a static array is known to GCC at compile time, which allows it to avoid dedicating a CPU register to computing offsets. This register is then available for general-purpose use.

Another problem that is related to C++ programs which manipulate arrays happens when you fail to qualify the methods used for array manipulation as inline. Each method or function that wasn't declared inline will not be inlined by GCC, and will incur an overhead of function call at run time.

However, inlining only helps with small functions/methods; large inlined functions will overflow the CPU cache and typically slow down the code instead of speeding it up.

A bug in the startup code distributed with DJGPP versions before v2.02 can also be a reason for slow-down. The problem is that the runtime stack of DJGPP programs is not guaranteed to be aligned on a 4-byte boundary. This usually only shows up on Windows (since CWSDPMI aligns the stack on its own), and even then only sometimes. But it has been reported that switching to Binutils 2.8.1 sometimes causes such slow-down, and switching to PGCC can reveal his problem as well. In some cases, restarting Windows would cause programs run at normal speed again. If you experience such problems too much, either upgrade to v2.02 or ask for a patch that solves it. (The patch is in the stub loader, so you will need to recompile the stubify utility and point the STUB environment variable to a program with a new stub.)

You can help support this site by visiting the advertisers that sponsor it! (only once each, though)