5 ms·

Sleep, at least on Windows, is allowed to have +/- 15 ms (default system heartbeat interval) of accuracy, which I don't think would work for this case. https:/

Sleep, at least on Windows, is allowed to have +/- 15 ms (default system heartbeat interval) of accuracy, which I don't think would work for this case. https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-sleep https://docs.microsoft.com/en-us/windows/desktop/api/synchap... I could mess around with the Win32 API or the NT API or something to make the heartbeat rate more granular, but according to the docs that kills battery, so I'm guessing it's going to be doing pretty much the same thing as what I'm doing manually.

asveikau 8y ago
Yeah I am well aware. I faced issues that reminded me of this when doing some audio stuff. Including on Windows.
morcheeba 8y ago
... that can still work. Measure how much time it actually slept and adjust accordingly. Or, is there some timer that runs at a reasonable rate (100Hz) where you csn yield once you've done 10msec worth of emulation? (I don't know the windows API, so just spitballing from the embedded world here)
- nothanksmydude 8y ago
  You seem like you appreciate good timers. If you ever want to revolt in horror/have a few hearty belly laughs, look into how windows has and does handle various granularities of timing
hrydgard 8y ago
Raising the timer interrupt to 1ms with timeBeginPeriod should still be less costly (with regards to power consumption) than a spin loop. But yeah it's all tradeoffs..
gambiting 8y ago
Yep, we had this exact issue on our live servers deployed to Windows Server 2016 in a VM - essentially I would do: 1) post tasks to process some data 2) while(tasksNotFinished) Sleep(1); Well, very quickly found out that the Sleep(1) was always a minimum of 16ms(or a multiple of 16ms), which made the whole thing stupidly slow. We fixed it by running timeBeginPeriod(1) which overrides the system timer resolution to 1ms. Yes it would kill the battery on laptops, but on a server this is not an issue.
- asveikau 8y ago
  The way I would solve that is an event and a count of tasks. When the last thread to complete its job sees InterlockedDecrement(&ntasks) == 0, call SetEvent to wake up the waiting thread.
  - gambiting 8y ago
    Yes, that was another solution we considered but we needed to deploy a patch quickly and setting the timer resolution was considered less risky and faster to do. But it would have worked as well as it should wake up the waiting thread immediately when used with WaitForMultipleObjectsEx.

asveikau 8y ago

Yeah I am well aware. I faced issues that reminded me of this when doing some audio stuff. Including on Windows.

morcheeba 8y ago

... that can still work. Measure how much time it actually slept and adjust accordingly. Or, is there some timer that runs at a reasonable rate (100Hz) where you csn yield once you've done 10msec worth of emulation? (I don't know the windows API, so just spitballing from the embedded world here)

nothanksmydude 8y ago
You seem like you appreciate good timers. If you ever want to revolt in horror/have a few hearty belly laughs, look into how windows has and does handle various granularities of timing

hrydgard 8y ago

Raising the timer interrupt to 1ms with timeBeginPeriod should still be less costly (with regards to power consumption) than a spin loop. But yeah it's all tradeoffs..

gambiting 8y ago

Yep, we had this exact issue on our live servers deployed to Windows Server 2016 in a VM - essentially I would do: 1) post tasks to process some data 2) while(tasksNotFinished) Sleep(1); Well, very quickly found out that the Sleep(1) was always a minimum of 16ms(or a multiple of 16ms), which made the whole thing stupidly slow. We fixed it by running timeBeginPeriod(1) which overrides the system timer resolution to 1ms. Yes it would kill the battery on laptops, but on a server this is not an issue.

asveikau 8y ago
The way I would solve that is an event and a count of tasks. When the last thread to complete its job sees InterlockedDecrement(&ntasks) == 0, call SetEvent to wake up the waiting thread.
- gambiting 8y ago
  Yes, that was another solution we considered but we needed to deploy a patch quickly and setting the timer resolution was considered less risky and faster to do. But it would have worked as well as it should wake up the waiting thread immediately when used with WaitForMultipleObjectsEx.