Degrading qemu performance in DooM Part II

ticks for demo (fewer is better)

VersionASM FixedDiv/FixedMulC
0.9.0259268
0.10.5299300
0.11.0316317
0.12.0289281
0.12.5290282
0.14.0282274
0.14.1280269
20180430192195
20190218187187

So after the last round, I went ahead and dug out my crap version, where I had just recently found a nice abs() fix for a FixedDiv issue that the old iD code suffers from, and re-built a version of DooM that both used the assembly fixed division, and another with the C version. To compile I used my old GCC 2.7.2.3 to build with the flags:

-m486 -msoft-float -ffast-math -O2 -fforce-addr -fomit-frame-pointer

So here we go using the versions of Qemu that I can build quickly with GCC 3.4.5 MinGW, along with the last two pre-built Win64 builds.

It’s kind of interesting just how close the performance is between the two versions.

Naturally the real test is to run it on actual hardware, and to try a few versions of Watcom C.

Maybe the real takeaway is that Qemu runs GCC built code better…?

4 thoughts on “Degrading qemu performance in DooM Part II

  1. How is this degrading? It has been constantly improving since 0.11.0. Also, the prebuilt ones are much faster than your own builds, for whatever reason.

    • I’m using a 13 year old machine, so I’m sure you have something faster.

      Also this is part 2, did you see part 1?

      The whole point was Watcom/C and the self-modifying code vs using a GCC build with no self modifying code, along with performance timings of an ASM version of FixedDiv/FixedMul vs using a C version.

      • Hi, nice projekt!!. Please can you describe it more? So you modified the source for Doom and compiled, or did you make some modifications to the new versions of QEMU, and that’s why it’s running well now? If you have made changes to QEMU, please describe it or post diff for version 20190218 thank you in advance

Leave a Reply