Runter
Wizard
Group: Members
Posts: 1,074
Joined: Jun 1, 2006
|
#16 Posted Oct 25, 2009, 10:09 am
|
Eh, a tick is different from a minimum pulse value. In your example you place importance on hundredths of a second. Which for your game (although I can't imagine it needing that, since latency ebbs from moment to moment more than that value) may be important. That being said, sure, everyone wants to approach a constant update time. As you approach this constant update you're going to pay for it. You're going to pay for it under the hood and it may be abstracted away from the programmer.
The idea, though, that you can remove this pulse per second completely is a bit of a red herring. At face value even you need certain facilities in your game which at best can be delegated somewhere else that requires it to have a pulse per second of some kind. E.g. dealing with active connections. These things, by caste and design, will require this.
|
|
.........................
-Heath
For once you have tasted flight Ruby you will walk the earth with your eyes turned skywards,
for there you have been and there you will long to return. --
Leonardo Da Vinci Yukihiro Matsumoto
|
|
Erok
Magician
Group: Members
Posts: 61
Joined: Jul 27, 2009
|
#17 Posted Oct 25, 2009, 10:23 am
|
Runter said:The idea, though, that you can remove this pulse per second completely is a bit of a red herring. At face value even you need certain facilities in your game which at best can be delegated somewhere else that requires it to have a pulse per second of some kind. E.g. dealing with active connections. These things, by caste and design, will require this.
Sorry, but that is not correct. I politely suggest looking into the low-level details of how systems (underlying OS and hardware, not MUD application) implement asynchronous i/o.
|
Last edited Oct 25, 2009, 10:32 am by Erok
|
|
Runter
Wizard
Group: Members
Posts: 1,074
Joined: Jun 1, 2006
|
#18 Posted Oct 25, 2009, 10:55 am
|
Erok said:Runter said:The idea, though, that you can remove this pulse per second completely is a bit of a red herring. At face value even you need certain facilities in your game which at best can be delegated somewhere else that requires it to have a pulse per second of some kind. E.g. dealing with active connections. These things, by caste and design, will require this.
Sorry, but that is not correct. I politely suggest looking into the low-level details of how systems (underlying OS and hardware, not MUD application) implement asynchronous i/o.
Okay, tell me how you in your mud are dealing with receiving data since you don't use any pulses per second or scheduling to check from incoming data?
|
|
.........................
-Heath
For once you have tasted flight Ruby you will walk the earth with your eyes turned skywards,
for there you have been and there you will long to return. --
Leonardo Da Vinci Yukihiro Matsumoto
Last edited Oct 25, 2009, 11:01 am by Runter
|
|
Erok
Magician
Group: Members
Posts: 61
Joined: Jul 27, 2009
|
#19 Posted Oct 25, 2009, 11:32 am
|
Runter said:Okay, tell me how you in your mud are dealing with receiving data since you don't ever do it at a minimum regular interval?
In my specific case, I'm using asio which supports scheduled events in addition to asynchronous i/o handling via callbacks, so there is no loop/tick. asio itself uses a set of platform specific methods, where select() is the most common demultiplexing mechanism. asio internals are discussed here, and again there is no loop/tick. If we delve into how an OS typically implements the select() system call, it ultimately boils down to the hardware signaling the OS that it is ready to read or write data, or has timed out doing so.
|
|
|
Scandum
Wizard
Group: Members
Posts: 1,105
Joined: Aug 8, 2006
|
#20 Posted Oct 25, 2009, 12:23 pm
|
Erok said:For example, on a tick, the user may see the results of multiple events that have expired since the last tick. That is, events become "bursty" because they are buffered into alignment due to the granularity of the tick. This won't be the case with an event driven approach, where they are processed as they happen, and timers (singular or repeating) can have granularity finer than a tick.
There's still the client bottleneck, tintin++ for example polls 20 times per second. Then there is the human bottle neck, no one will notice the difference between 20 loops per second and 50 loops per second. Not to mention network and OS lag.
From a practical viewpoint 10 to 20 loops per second gives a pretty fluid experience.
Davion said:Eg. Changing the aggressive update to store a list of aggressive mobs and searching that instead of the char_list for aggressive behaviour (a part of diku/ROMs limited AI). This is of course a very simple example. Such lists could be part of a much larger system dedicated to executing events.
Would make more sense (and be more event like) to launch an event looking for aggressive mobs whenever a player moves.
|
|
|
Erok
Magician
Group: Members
Posts: 61
Joined: Jul 27, 2009
|
#21 Posted Oct 25, 2009, 1:16 pm
|
Scandum said:Then there is the human bottle neck, no one will notice the difference between 20 loops per second and 50 loops per second. Not to mention network and OS lag.
Again, it isn't so much the impact on user experience as it is efficiency/elegance within the MUD. Why wake up 20 or 50 times per second (though 4 or 5 is more realistic) looking for work to do, when it's far more efficient to wake up only when there is actual work to do? Event driven isn't any more complicated to implement than polling, so IMO there's no reason to stick with polling if you're developing something new. I know polling is well understood because of it's historical usage in MUDs, but that doesn't make it the best solution.
PS: Don't know anything about tintin++, but why does it poll at all? As a client, I would have expected it to block indefinitely on read. If it's to process user input, why not do that in a separate thread? One could even simply redirect the user input to a pipe for processing by the read thread if access to shared data is a concern.
|
Last edited Oct 25, 2009, 1:17 pm by Erok
|
|
Scandum
Wizard
Group: Members
Posts: 1,105
Joined: Aug 8, 2006
|
#22 Posted Oct 25, 2009, 2:30 pm
|
Erok said:Why wake up 20 or 50 times per second (though 4 or 5 is more realistic) looking for work to do, when it's far more efficient to wake up only when there is actual work to do?
20 times nothing is still nothing, so all things considered it's not a big deal, unless you have an inefficient method of polling events.
Erok said:
PS: Don't know anything about tintin++, but why does it poll at all? As a client, I would have expected it to block indefinitely on read. If it's to process user input, why not do that in a separate thread? One could even simply redirect the user input to a pipe for processing by the read thread if access to shared data is a concern.
What'd be the big advantage?
|
|
|
Erok
Magician
Group: Members
Posts: 61
Joined: Jul 27, 2009
|
#23 Posted Oct 25, 2009, 3:54 pm
|
Scandum said:20 times nothing is still nothing, so all things considered it's not a big deal, unless you have an inefficient method of polling events.
It's not nothing if you also consider the work that the OS is doing to swap in the process for execution. If the CPU has nothing better to do, then no big deal, though I suspect MUD hosts will probably appreciate efficient server designs. Anyway, do what works for you. I jumped into the thread only to ensure the technical arguments were accurate.
Just wanted to add... although this whole discussion may seem to be a bit much in the context of a MUD, which requires few resources from a modern computer, the attitude of not designing for efficiency is what led to bloatware like Windows. I work in embedded software, where resources are limited and efficiency/performance is always a concern. I would think the same is true for other industries, such as financial software (e.g., transactions per second). It's just good practice.
|
Last edited Oct 25, 2009, 4:00 pm by Erok
|
|
Scandum
Wizard
Group: Members
Posts: 1,105
Joined: Aug 8, 2006
|
#24 Posted Oct 25, 2009, 4:30 pm
|
Erok said:It's not nothing if you also consider the work that the OS is doing to swap in the process for execution. If the CPU has nothing better to do, then no big deal, though I suspect MUD hosts will probably appreciate efficient server designs. Anyway, do what works for you. I jumped into the thread only to ensure the technical arguments were accurate.
Well, we're talking 0.01% cpu usage here, or something of that order, I doubt a MUD host would notice the difference. Regardless, it all adds up, and in that regard you certainly have a point.
|
|
|
Mudder
Conjurer
Group: Members
Posts: 196
Joined: Oct 17, 2009
|
#25 Posted Oct 25, 2009, 4:45 pm
|
I would like to mention, for the MUDs sake that it listed this feature in a section labeled "things you don't care about and probably won't notice" or something like that. I asked the question because I was curious.
|
......................... A wise man once said:Never underestimate a newbie coder and the sheer amount of spare time they may accumulate.
|
|
Mudder
Conjurer
Group: Members
Posts: 196
Joined: Oct 17, 2009
|
#26 Posted Oct 25, 2009, 5:24 pm
|
Erok. You have me convinced to try out new systems and screw around looking for something better.
What are the thoughts on Runter's event system?
|
......................... A wise man once said:Never underestimate a newbie coder and the sheer amount of spare time they may accumulate.
|
|
David Haley
Wizard
Group: Members
Posts: 5,728
Joined: Jun 30, 2007
|
#27 Posted Oct 25, 2009, 7:11 pm
|
The difference between a tick-based and event-driven architecture isn't at all just a question of terminology, most certainly as far as implementation is concerned. That said, the difference between a regularly scheduled tick event and a tick loop that runs every X time units is indeed negligible. If that's the only thing you do with the event system, it's kind of a waste of effort: the point behind an event system is indeed (as others have said) to wake up only when there is work to do. In this case, if you kept the tick event (and were being clever), you would do rather different work than in the traditional tick loop which requires a full check on everything; you might only do things like reset areas, or events that happen to everything truly once a tick.
It has a number of issues. The biggest is that one shouldn't be looping through the entire list of events to find the ones that need triggering. Events should be sorted in order of upcoming events, so that you need merely pop things off the front until things are no longer due. This means that instead of counting down a timer, you keep track of event time as "now + delay", and an event fires if "now" is greater than or equal to the event's trigger time. There are other implementation comments (for example, the comment on line 212 about doubly-linked lists allowing for faster extraction is incorrect) but there's no real use going over the code in detail because it clearly disclaims itself as a prototype of sorts. The issue of looping over events is a more serious design problem.
|
|
|
|
|
Erok
Magician
Group: Members
Posts: 61
Joined: Jul 27, 2009
|
#29 Posted Oct 25, 2009, 9:36 pm
|
I haven't looked at it, but if you are working with an existing codebase, migrating it to libevent is also an option that has good documentation and user forums.
Scandum said:One thing I'm wondering about, how are weak pointers typically implemented?
You can refer to the Boost or Loki libraries for example implementations in C++. The Boost variant has been accepted into TR1 and will become part of the C++ language standard.
|
Last edited Oct 25, 2009, 9:37 pm by Erok
|
|
Mudder
Conjurer
Group: Members
Posts: 196
Joined: Oct 17, 2009
|
#30 Posted Oct 25, 2009, 11:29 pm
|
Erok said:I haven't looked at it, but if you are working with an existing codebase, migrating it to libevent is also an option that has good documentation and user forums.
Currently I'm using a rom codebase. RaM fire, actually.
I downloaded libevent but have absolutely no idea how to make use of it. It's a library, right? ...My knowledge with such things leaves much to be desired.
|
......................... A wise man once said:Never underestimate a newbie coder and the sheer amount of spare time they may accumulate.
|
|
