DJGPP producing a much slower binary than Mingw

[m35]

I'm writing a 3D voxel-based renderer. My goal is to have it run on DOS. But I have discovered that DJGPP is producing a much slower binary than Mingw (~20 frames per second versus ~176 frames per second). I'm trying to figure out why this is.

The difference is apparently in how one of my recursive functions, descend_pyramid() is compiled. Within the recursive function, I have an "if" statement which determines if the function calls itself again or if it returns. It's something like:

Code: Select all

if(A)
   return 0;
else
   return descend_pyramid(level);

With the above, both DJGPP and Mingw produce binaries that run at ~20 frames per second. But when I optimize the function to reduce the number of times descend_pyramid() needs to be called by changing the "if" statement to:

Code: Select all

if(A || B)

The DJGPP binary still runs at ~20 fps, but the Mingw binary runs at 176 FPS (I compile each with -O3).

I've been looking over the assembly produced by each compiler, but it hasn't been obvious what is causing these large differences in runtime.

Any advice?


-----
Additional information that might/might not be relevant:
B in the above "if" statement is a binary value (stored as an entry in multi-dimensional char array), ex;

Code: Select all

pyramid_base[pyramid_ind][ x*64*64 + y*64 + z]

Thanks

[Brendan]

Hi,

I've been looking over the assembly produced by each compiler, but it hasn't been obvious what is causing these large differences in runtime.

We haven't looked over the assembly produced by each compiler, so it's a lot less obvious what is causing the differences to us.

Any advice?

Which version of GCC does DJGPP use (is it an ancient version of GCC from 1998)? Which version of GCC does Mingw use (is it a version of GCC 4.x from last year)? Do you think that someone might have improved the compiler's ability to optimise code in between those versions?


Cheers,

Brendan

[turdus]

Any advice?

Don't use recursive function in a speed critical code. It's always a bad idea due to massive stack usage, also because stack size is limited, the number of recursion levels would also be limited. Instead convert your code into a loop.

[Owen]

DJGPP binary running under what? MinGW binary running under what?

[m35]

Which version of GCC does DJGPP use (is it an ancient version of GCC from 1998)? Which version of GCC does Mingw use (is it a version of GCC 4.x from last year)?

Good point, I didn't think to check. But it turns out they are both the same version (4.6.1)

Don't use recursive function in a speed critical code. It's always a bad idea due to massive stack usage, also because stack size is limited, the number of recursion levels would also be limited. Instead convert your code into a loop.

After some more thinking, it does seem like I'd be able to convert this into a loop without recursion. I'll try this next. Although this function only has one parameter (a char) and the recursion goes at most 5 deep. So I'm not sure if there's that much stack overhead because almost all my variables are globals. But maybe (hopefully) so.

DJGPP binary running under what? MinGW binary running under what?

The OS? Windows XP. The DOS code is run under ntvdm also on XP. For these tests I don't display anything to the screen except the FPS at the end of the test.

[Owen]

DJGPP binary running under what? MinGW binary running under what?

The OS? Windows XP. The DOS code is run under ntvdm also on XP. For these tests I don't display anything to the screen except the FPS at the end of the test.

So one is a native binary, while one is running under an emulation layer. For all we know NTVDM is using a non-zero segment base for your code, and all branches are now in the vertical microcode performance tarpit or something similar.

[m35]

DJGPP binary running under what? MinGW binary running under what?

The OS? Windows XP. The DOS code is run under ntvdm also on XP. For these tests I don't display anything to the screen except the FPS at the end of the test.

So one is a native binary, while one is running under an emulation layer. For all we know NTVDM is using a non-zero segment base for your code, and all branches are now in the vertical microcode performance tarpit or something similar.

On the other benchmarks I've run, the performance is identical.

On a somewhat related note, I changed this function into a loop and the performance is now somehow worse. I've decided to go back and try to improve other aspects of the algorithm.

[turdus]

On a somewhat related note, I changed this function into a loop and the performance is now somehow worse.

Hmmm, you definitely doing it wrong. I suggest to spend a little more time on the topic.

[m35]

On a somewhat related note, I changed this function into a loop and the performance is now somehow worse.

Hmmm, you definitely doing it wrong. I suggest to spend a little more time on the topic.

...that's the plan.