Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: setFrameLimit - curious effect  (Read 2851 times)

0 Members and 1 Guest are viewing this topic.

Garwin

  • Jr. Member
  • **
  • Posts: 59
    • View Profile
setFrameLimit - curious effect
« on: February 14, 2024, 05:50:43 pm »
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

  • Hero Member
  • *****
  • Posts: 3383
  • My number of posts is shown in hexadecimal.
    • View Profile
    • Links
Re: setFrameLimit - curious effect
« Reply #1 on: February 14, 2024, 08:43:23 pm »
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.
Selba Ward -SFML drawables
Cheese Map -Drawable Layered Tile Map
Kairos -Timing Library
Grambol
 *Hapaxia Links*

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11042
    • View Profile
    • development blog
    • Email
Re: setFrameLimit - curious effect
« Reply #2 on: February 15, 2024, 04:24:47 pm »
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.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Garwin

  • Jr. Member
  • **
  • Posts: 59
    • View Profile
Re: setFrameLimit - curious effect
« Reply #3 on: February 15, 2024, 07:34:04 pm »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11042
    • View Profile
    • development blog
    • Email
Re: setFrameLimit - curious effect
« Reply #4 on: February 15, 2024, 09:36:03 pm »
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.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

kojack

  • Sr. Member
  • ****
  • Posts: 345
  • C++/C# game dev teacher.
    • View Profile
Re: setFrameLimit - curious effect
« Reply #5 on: February 16, 2024, 12:23:39 am »
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

  • Jr. Member
  • **
  • Posts: 59
    • View Profile
Re: setFrameLimit - curious effect
« Reply #6 on: February 20, 2024, 09:18:26 am »


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

  • Sr. Member
  • ****
  • Posts: 345
  • C++/C# game dev teacher.
    • View Profile
Re: setFrameLimit - curious effect
« Reply #7 on: February 20, 2024, 11:56:03 am »
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.

 

anything