Weird Performance Improvement

[mh]

Quake2 keeps its time in miliseconds.
The main advantage of miliseconds is that your precision is the same at the start as it is at the end.
Progressively incrementing a timer like dwRealTime (if it were a float) would result in precision errors with higher framerates. The higher your framerate is, the worse it gets. When the frame rate reaches 2k/3k, your precision really starts to suffer.

Some timing bugs only appear when you set r_norefresh 1 (other than timerefresh reporting #inf fps, lol).

This.

It's nothing to do with math libs and nothing to do with floating point vs integer calculation performance; it's entirely due to accumulated loss of FP precision.

The 4 main areas in vanilla Quake that benefit from switching to integers are:

• Host_FilterTime, where we get time added to realtime causing precision loss to accumulate.
• CL_ReadFromServer where we have cl.time += host_frametime, more loss.
• SV_Physics; there's an sv.time += host_frametime there too.
• svc_time messages; the above 3 actually use doubles in vanilla Quake but svc_time is transmitted as a float; the combination of this with CL_LerpPoint means that all the extra precision from using doubles, at least on the client, is totally lost.

[dreadlorde]

Isn't int, at least in C, the size of a word?

Usually, yes. But there's no formal rule.

And it depends on what size a word is.

Wouldn't it make sense then though that you saw a speed up when switching to int's? Since int's are the size of a word (most of the time :p), and a word is a CPU's native data type, which it can usually deal with better than any other .

[Mexicouger]

If time got switched to an int, wouldn't that make entities in qc which use a floating point to nextthink, break them?

[mh]

If time got switched to an int, wouldn't that make entities in qc which use a floating point to nextthink, break them?

The QC interface needs to be kept at floating point, so the trick is to convert the integer millisecond time to float (multiply it by 0.001f) when passing it over to QC. I suspect though that since all QC calculations are actually done in the engine, one could potentially stash them in a union and do some trickery.

Wouldn't it make sense then though that you saw a speed up when switching to int's? Since int's are the size of a word (most of the time :p), and a word is a CPU's native data type, which it can usually deal with better than any other .

No, modern FPUs are fast. Any moden CPU architecture is going to have a whole batch of extra instructions for ultra-high-speed floating point operations, often in parallel, and this kind of thing thankfully isn't that much of a problem any more (you can still construct contrived situations to prove otherwise, of course - but then again you could construct a contrived situation to prove anything you wanted if you set your mind to it).

The days when the actual code (and the amount of code) had a direct impact on performance for this kind of application are over. Sweating the instructions is no longer a win. One needs to focus on achieving more optimal CPU/CPU and CPU/GPU parallelism, better data throughput and better cache efficiency instead. That's the road to performance, ints vs floats is talking moonshine.

Besides, the amount of calculations involved in the timer are literally tiny compared to the amount involved elsewhere in the engine. Any speed gain purely from switching this small amount of operations to integer is going to be somewhere along the line from marginal, through dubious, ending at an outright lie.

It's what Spike said (and he knows what he's talking about): accumulated loss of floating point precision leading to lag in Host_FilterTime.

Additional reading: http://assemblyrequired.crashworks.org/ ... uare-root/

(a dissection, with benchmarks, of various methods of square root calculation.)

[leileilol]

No, modern FPUs are fast.

If you need to test the inthancement through patching a winquake, I have a 486 for test comparison cases.

[dreadlorde]

No, modern FPUs are fast. Any moden CPU architecture is going to have a whole batch of extra instructions for ultra-high-speed floating point operations, often in parallel, and this kind of thing thankfully isn't that much of a problem any more (you can still construct contrived situations to prove otherwise, of course - but then again you could construct a contrived situation to prove anything you wanted if you set your mind to it).

The days when the actual code (and the amount of code) had a direct impact on performance for this kind of application are over. Sweating the instructions is no longer a win. One needs to focus on achieving more optimal CPU/CPU and CPU/GPU parallelism, better data throughput and better cache efficiency instead. That's the road to performance, ints vs floats is talking moonshine.

Besides, the amount of calculations involved in the timer are literally tiny compared to the amount involved elsewhere in the engine. Any speed gain purely from switching this small amount of operations to integer is going to be somewhere along the line from marginal, through dubious, ending at an outright lie.

Alrighty. The only 'experience' I've had with datatypes and performance would be on the Gameboy Advance, which is an Arm processor, which has to emulate floating point, &c.