we're not running anything asychnronously.
also, you said that BYOND is multithreaded, which is false.
I believe that the misunderstanding here is that Zecro is relying on system cpu utilization as a metric. However, how byond measures and meters cpu percentages is a hack and based on its own internal functions, so it appears to go over 100%
This simply means that due to byond's synchronous nature, the things being activated have overflowed their time period and are now taking up parts of the next time period. What this suggestion wants is a more granular and more accurate/measurable world.cpu metric so that they can fine tune *WHEN* to sleep subprocesses. For simple byond games, sure you can just sleep whatever, but they're talking about a complex game with multiple monolithic subprocesses going on at once. Anyways, this is all moot because I believe that Lummox is already working on something like this, or at least I was lead to believe so by Volundr. Ps: It's hard to believe that Zecronious is the #9 top helper when he's so childish. | |
Amidaychi wrote:
I believe that the misunderstanding here is that Zecro is relying on system cpu utilization as a metric. However, how byond measures and meters cpu percentages is a hack and based on its own internal functions, so it appears to go over 100% I think you need to look up what world.cpu actually represents, if that's your opinion toward it. There's a perfectly good reason why it exceeds 100. edit: just read the rest of this thread, it was mentioned already | |
I think this feature makes sense. When a tick starts, your "theoretical instantaneous world.cpu", aka your "sub-tick time" would be zero. As you perform more calculations within the same tick, your sub-tick time increases. If your sub-tick time exceeds world.tick_lag, you can expect "actual world.cpu" to exceed 100.
What you want is to detect sub-tick time and maybe use a sleep to skip to the next tick when it gets dangerously close to exceeding tick_lag (tick_lag being the maximum sub-tick time allowed before apparent server lag occurs), rather than sprinkling in more sleeps than necessary. I wonder if that is what the "background" proc setting does. | |
Now, why would it do that?
According to the Reference, sleep(-1) only sleeps if procs are backlogged. To me, that sounds similar to what you want: only to sleep when processing time exceeds a tick. | |
sleep(-1) just allows spawn() and such to continue, I don't actually think it proceeds to the next tick if the tick goes overtime.
source: Lummoxs DMM suite has a TON of sleep(-1) and it DOES hang a server until it's done. | |
Marked as redundant
??? | |
If your CPU didn't need to do what it was currently doing then it wouldn't be doing it all. This is both offtopic and wrong. Byond has two sets of tasks it needs to complete, client related tasks, and code related tasks. Trying to hold off on monolithic subsystems in game (like atmos) so that byond has time to handle client related tasks is nothing sort of common sense. If it could be done next tick then why did you tell the machine to do it this tick in the first place? We haven't told it to do it any tick at all, We are trying to figure out if we should queue the task up to be ran this tick, and we can't do that if the cpu var is fizzy, hacky, and seems like it just makes it up as it goes. | |
Zecronious wrote:
The only thing you will succeed in doing is wasting available CPU. Let me walk you through why. This may be a misunderstanding of the word "tick" in this context. Tick doesn't actually refer to a period of real-time; that would be tick_lag, the minimum amount of real-time any tick can last. From your example, if you called Process A and Process B during Tick 1 without any delays, Tick 1 would last longer than tick_lag because it's trying to fit 25 calculations "in the same tick". This causes the game to experience lag (equivalent to at least half a tick, I guess) and world.cpu to exceed 100. Example: world.time refers to the current tick. It won't change until the current tick is finished, so if you called Process B several times, world.time won't have changed, but the real-time equivalent of "several ticks" would have passed. That would be lag. When lag starts, the entire game world is effectively frozen until the lag ends. This feature request is about a way to avoid that happening: if a CPU-intensive procedure has used a "certain percentage of the current tick", postpone it until the next tick instead of holding back the rest of the game. | |
I can agree that sleep(-1) is somewhat problematic, because it doesn't seem to know we're in a backlog until we're already pretty deep in that backlog.
SS13's atmospherics is probably one of the ideal candidates of an application for which there is no good solution to optimization. While there are things that could probably stand to be improved, the problem itself is a problem for which there is little way to improve the issue. Atmospherics, lighting, and map loading/saving are among a few of the only real examples where the problem is unfixable through normal means. I'm not sure where I stand when it comes to a tick_delta variable. I think it would be better to be able to get information from the system clock with a proc on demand rather than waiting on it to be updated at the granularity of a single tick. The real problem is that all of our time variables are updated on the world at the start of each tick and bound to a minimum granularity of world.tick_lag. We very probably need a timeofday variant that's measured in milliseconds. Unfortunately, the number of milliseconds in a single day is approximately 86 million, which with BYOND's numeric constraints would have accuracy problems. That would limit the implementation to displaying the number of milliseconds in a little under 5 hours, which would point to the idea of implementing some sort of a millisecond getter on the world being limited to probably the number of milliseconds since the last frame start. EDIT: if measured in centiseconds, we'd be able to do a timeofday getter that returns accurate results, being an upper limit of just over 8.6 million. | |
If whoever marked this as redundant is actually serious then they need to learn the difference between redundant and not redundant.
| |
If whoever marked this as redundant is actually serious then they need to learn the difference between redundant and not redundant. Agreed, this feature request itself may be somewhat malformed, but it highlights a shortfall in how DM's world time variables are managed. What OP is asking for is not possible with the existing toolkit, and in trying to implement the feature myself short of using a DLL (which carries with it some serious problems), I found no viable solution. | |
Ter13 wrote:
If whoever marked this as redundant is actually serious then they need to learn the difference between redundant and not redundant. If they don't want their feelings hurt why not implement an administrator post system to clarify why they marked a request/bug/etc as something instead of just a silent go away | |
If they don't want their feelings hurt If you could see the pager logs of a number of admins, you wouldn't boil it down to something as simple as hurt feelings. I don't want to derail this thread with that, though. | |
I have no idea how this ended up showing up as redundant without the post being made, unless the mod deleted the auto post (which they can). But I'm reopening this because this has actually been an ongoing discussion I've had with Clusterfack.
To clear up some confusion: Zecronious, BYOND will not start to use multiple cores if the tick goes into overtime, because it is not multithreaded. The multithreading experiment didn't work out and has been disabled (it might be revisited in the future), but even when it was available it did not extend to procs. Procs always ran in a single thread, because there's no other way to handle them. Clusterfack: I had mentioned I still have reservations about the usefulness of a var like this, because I'm not sure how it can be used to schedule anything if you don't know how much of the tick is remaining. You made a post earlier on this thread that I think helps clarify something for me: You said you could shorten its sleep time so that it could be scheduled earlier in the next tick. Sleep times don't really work that way; internally, all sleep times are converted to tick counts. So you don't really have any control over what gets scheduled first on the next tick. | |
Lummox JR changed status to 'Open'
| |
I had mentioned I still have reservations about the usefulness of a var like this, because I'm not sure how it can be used to schedule anything Basically, in a loop, while processing things to be processed, It can notice that it's quite far in the current tick, and halt the loop until the next tick, (with sleep(world.tick_lag)) so that client operations can still happen. Basically a code aware background = 1, since background=1 provides concurrency issues since other parts of game state can change in the middle of a loop, as well as inefficiencies with how and when it sleeps | |
I think I might have accidentally marked this when I was testing a new user-script for making the mod tools less tedious. No idea why my mark post didn't appear though, if I did indeed do the marking during the testing.
| |
In a game situation everything runs synchronously. There's nothing you'd want in that game that can run asynchronously.
If you want to write async programs then get something like C++.