Very strange FPS fluctuation

Started by
17 comments, last by AndreTheGiant 9 years, 1 month ago

I like how everyone has their own, unique way of calculating FPS. Nobody wants to be a stereotype. :)

Advertisement

I like how everyone has their own, unique way of calculating FPS. Nobody wants to be a stereotype. smile.png

More like: as is the case with most things in programming, everything has a million gotchas in it that will make your code give fundamentally flawed results.


He fixed this in his “real” code: Convert.ToInt32(frameCount * 1000.0 / frameMillis);.
The result of (frameCount * 1000.0) is a double, and that causes the division to be a double, so the math will work correctly.

That's a few assumptions about the order the operations take place. It is not guaranteed with the code above.

The operations can be reordered since multiplication and division are associative and commutative and have the same precedence. Unless he adds parenthesis around a pair of them, such as the two you wrote, the C# compiler has the option to reorder them so the integer division takes place first in order to avoid a conversion.

In other words, the compiler is free to reorder that code into the ordering caused by ((double)(frameCount/frameMillis))*1000.0.

Wrapping one of them in parenthesis solves the potential problem:

Convert.ToInt32((frameCount * 1000.0) / frameMillis);.

That's a few assumptions about the order the operations take place. It is not guaranteed with the code above.

…the compiler is not allowed to make assumptions that would change the result.
The specifications clearly state the order of operations in math and also promotion priorities. While it may be allowed to do tricky business under the hood, it is not allowed to violate the assumptions the programmer can make based on these 2 things.

It is guaranteed that all operations will be of double precision.


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid


The operations can be reordered since multiplication and division are associative and commutative and have the same precedence. Unless he adds parenthesis around a pair of them, such as the two you wrote, the C# compiler has the option to reorder them so the integer division takes place first in order to avoid a conversion.

Do you have any reference to support the statement that the C# compiler will do that? I've never heard of a compiler moving operations around to avoid a cast, and then not doing because a programmer used parentheses. If it was going to optimize something a certain way, I don't see why a pair of parentheses that do not actually change the order of operations will affect anything.

The operations can be reordered since multiplication and division are associative and commutative and have the same precedence.

Nope.

"Except for the assignment operators, all binary operators are left-associative, meaning that operations are performed from left to right. For example, x + y + z is evaluated as (x + y) + z." (https://msdn.microsoft.com/en-us/library/aa691323%28v=vs.71%29.aspx)

I guess I was mistaken. Sorry about that.
Assuming all the math is right or wrong doesn't answer the question of why sometimes it launches and runs fast and sometimes slow. I had a similar issue and it turned out to be that it ran slow when my laptop wasn't plugged into the power socket! :-)

Just wanted to thank everyone for taking the time to respond. I got a lot of good information, although RobMaddison is right, nobody directly answered my exact question. I realize I had some minor math bugs but they were nothing that explained the massive variance between FPS between different launches of the game. Thats my fault for not providing the full picture though.

I did end up switching from milliseconds to microseconds which should make things smoother and more accurate (I havnt actually noticed a difference, but mathmatically I know this was a good change to make).

I believe my FPS fluctuation has to do with a separate call to Application.DoEvents() that happens elsewhere in the code. I'm not sure yet exactly how its related, but I did some profiling and the time it takes for Application.DoEvents() to run is exactly the time thats "missing" from my FPS calculation and causing the FPS to vary so wildly.

This topic is closed to new replies.

Advertisement