setFrameLimit - curious effect

[Garwin]

I am just curious as it is nothing really important.

I have just measured in average on function that generate Voronoi diagram which is inside the main sfml event loop.

auto vorStartTime = std::chrono::steady_clock::now();
            voronoi.generate();
auto vorEndTime = std::chrono::steady_clock::now();
 

Then I print each second the average for this function. Each iteration I add vorEndTime - vorStartTime to the overall time and then divide by a number of loops for that time. Than just checking if elapsed at least 1 second from the last loop and if so print the average.

But what is really strange that it gives me 0.3 - 0.6 ms with setFrameLimit to 60.
But if I switch off any FrameLimit, i get 0.14 - 0.16 ms.

The function

voronoi.generate() is using only sf::Vector2f from the whole SFML library for points.
 

I am just curious how it can be possible that setting frame limit has effect on function with has practically nothing to do with SFML. Or it can be possible that setting the frame limit makes the processor more idle so that the max turbo frequency of processor is not used (intel i7-1265u 1.8 MHz)

[Hapax]

setFramerate() sleeps the thread.
This helps with "over-producing" with no limit and can reduce power used. However, it's not strictly set to that rate.
Once a thread is "slept", it has the possibility of "over-sleeping" as there's no real way of insisting on coming back by a specific time (accurately); this is dependent on operating system's task scheduler.

So, I'd guess that the framerate limit is sleeping during each frame and then the operating system is keeping it a little longer than your hoped-for length of time before returning it.

I would expect it to be faster (shorter frame time) without a framerate limit.

[eXpl0it3r]

The framerate limit isn't restricted to only SFML functions, but it affects the whole game loop.
Technically speaking display() will suspend the thread for a certain period of time, meaning this is a blocking operation and nothing else in the program (on the same thread) will be executed.

As such everything that is in the game loop will be limited by the set framerate limit.

[Garwin]

setFramerate() sleeps the thread.
This helps with "over-producing" with no limit and can reduce power used. However, it's not strictly set to that rate.
Once a thread is "slept", it has the possibility of "over-sleeping" as there's no real way of insisting on coming back by a specific time (accurately); this is dependent on operating system's task scheduler.

So, I'd guess that the framerate limit is sleeping during each frame and then the operating system is keeping it a little longer than your hoped-for length of time before returning it.

I would expect it to be faster (shorter frame time) without a framerate limit.

This I would understand but if the measurement of the function is just 2 time points one before that function and after that function which has no call to SFML except sf::Vector2f, that I cannot see how sleep will interfere with it. I do not measure and compare whole loop but only one function inside the loop.

[eXpl0it3r]

You said it's inside the event loop, which means it will only be called if there are events to be processed.
As such the function won't be called every iteration. Not sure that's what you're seeing.

[kojack]

I'm getting a feeling your turbo frequency idea might be what's going on.
Turbo does small increments to clock frequency when the workload is high (apparently number of cores in use too) and thermal limits haven't been hit. So a single threaded SFML app doing mostly sleeping for framerate limits with occasional spikes from generate() isn't sustaining the workload long enough for turbo to raise the clock as much.
I don't know if there's an app for intel that can show that. I've got an AMD one for my threadripper (Ryzen Master).

[Garwin]

Thanks for confirming, that I am not completely out of mind.
It should be no problem as if the application is more processor demanding, there will be less sleep, so no slow down.

[kojack]

Maybe try setting the frame limit, but calling the generate function around 20 times in a loop (should use most of the available frame time) and time each call. That might be enough to see the CPU speed up.
(Not suggesting doing that permanently, just to test the hypothesis).
Maybe try some different loop counts to see how much work it needs before it clocks up.