What we need:
A var or proc to access how far we are into a tick
What purpose would it serve:
On our code we are using a 'scheduler' so that the processing throughout a tick never overruns. The idea is that after using some percentage of the cpu time over the course of a tick, the scheduler will delay until the next tick so that byond's tick processes (tick based client interactions) can run without delay.
Also, since cpu heavy processes are done by the scheduler they can have different values for how late into the tick they can be processed and are otherwise made to wait until they can start early into a tick.
However world.cpu is not a 'true' per tick value of how far into the tick we have progressed, so this isn't usable on our side for this purpose.
So in essence: A way to measure how far we are into a tick so that we can code a ticker that doesn't overrun by delaying until the next tick when we are too close to end of tick. I feel this has the potential to be very useful for those who want to keep their code from overrunning and stuttering as happens when you let a cpu run for longer than a tick.
ID:1904435
 Jul 26 2015, 1:51 am (Edited on Jul 29 2015, 1:22 pm)
|
|||||||
Resolved
| |||||||
If your CPU didn't need to do what it was currently doing then it wouldn't be doing it all.
The whole concept of delaying a calculation until later.. If it could be done next tick then why did you tell the machine to do it this tick in the first place? Makes no sense. | |
Because we don't know how long a calculation needs to be done for before it occurs. At best I can only know a relative maximum length of time that it might take.
Say I need to do something with a very long proc that takes .6 server seconds and cannot be sleeped while doing so, and I have a ticklag of 1. I cannot have that calculation done after 40% of the tick time has been used otherwise my cpu will overrun its tick which is unacceptable. With this feature I could see how long this tick has been running, sleep it until nearly the beginning of the next tick and have it run then. Here's an example of practical application of this principle, say I have three schedulers running off the same ticker, each with distinct cpu usage requirements 1 always takes less than 10% cpu usage over a tick 2 takes less than 20% 3 takes less than 60% If 50% of the tick has passed I can run schedulers 1 and 2 without issue, but scheduler 3 MUST be delayed until the next tick. | |
The only thing you will succeed in doing is wasting available CPU. Let me walk you through why.
Lets Imagine Tick = 1 second Calculations available per second = 20 Process A: 5 calculations per second Process B: 20 calculations per second What will currently happen is that it will do 20 calculations per second. That is 20 calculations in 1 tick followed by 5 calculations the next tick. If we stop calculating because we 'don't want to overshoot our capacity' (which is impossible) we can only ever choose to do less than 20 calculations per second. In other words we'd be underutilizing our CPU and creating periods of lag rather than sloving any periods of lag. | |
Lets add on top of this that BYOND will probably be running on multiple cores with multiple threads and if it begins to use more than it's fair share then your operating system will throttle it back anyway.
| |
Zecronious wrote:
'don't want to overshoot our capacity' (which is impossible) oh you adorable little thing; you think CPU can't go past 100% | |
It will delay the next tick causing visible latency if you go above 100% cpu usage in a tick
| |
Yes which causes a visible hang until it is resolved
| |
Mhmmmmmmmm and guess what's going to happen if you sleep for a while?
Come on, you can do it. What's gonna happen? | |
Apparently you missed my point entirely that you CANT sleep certain procs because they rely on assumptions made earlier in the proc and which use a large portion of cpu. I'm not talking about small procs that are easy to sleep in the middle and we just ignore it until the next tick.
| |
Yes, a backlog, and it is EXTREMELY effective at fixing lag.
if a tick overruns you lag and the game becomes unresponsive. | |
You don't seem to understand that if you choose to add a delay anywhere 'ignoring' or 'sleeping' you'll only succeed in increasing the overall delay.
| |
You must have no idea how byond works with the posts you have been making, I will wait for other responders to comment before replying here again.
| |
Obvious troll is obvious.
Now please go and post to something you actually understand. | |
Yes, that's exactly what we're doing! We're increasing delay on some things based on our CPU. If we're clogged up, things tick less often, meaning the less important things don't clog shit up when we would otherwise have lag. It keeps things wonderfully smooth.
| |
world.cpu is an average over an unspecified number of ticks so it's pretty much worthless. Available time vars are too inexact to count intratick without using an external library, so there's no manual counting options either.