[Tinymux] Flags
Stephen Dennis
brazilofmux at gmail.com
Wed Jul 6 13:19:57 EDT 2005
Platitudes directed at no one in particular:
First make it work correctly. A device which produces the right
answer slowly is infinitely more valuable than a device that produces
the wrong answer quickly.
Something is fast enough when there is no benefit to making it faster
(the user is unable to perceive the difference, the computer has idle
cycles, the hard disk wearing out any faster, etc.).
There are times when the speed of softcode deserves some consideration.
Assuming a game has 500 people who all use the same softcoded command
every 2 seconds. Let's say that it typically takes 1ms to execute this
command.
Queuing Theory (at least to the degree that I remember it) with a M/M/1
model with exponential distribution tells us that on average there is a
queueing cost of 333 us (your command is waiting on earlier commands to
complete). And, the game will consume 25% of the CPU on average.
If the service time goes up to 2ms, the queueing cost increases to 2ms,
and the game will consume 50% of the CPU. In total, a command will take
4 ms on average (still not perceivable).
A few gotchas in all this. Even with an average queueing cost of 2ms,
the worst-case queueing cost is higher than 1 second. It isn't likely,
but it is possible.
This 'queueing cost' is not what you would see by profiling the code.
It isn't the cost of running the @wait or @trigger code paths. It's
the time spent waiting on someone else's command to finish running.
The queueing might occur in the MUX @wait queue, or it might occur in
the network input queues, but it occurs whether you use functional
coding style or not.
In general, the queueing model of a MU server is more complicated.
There are several queues including the network, the command processor,
and the disk.
So, I s'pose my point is that 1 or 2 millisecond may seem
insignificant, and it is, unless it is used by enough players
frequently enough that it isn't -- and in that case, the cost also
includes some dynamic behavior.
Brazil
More information about the Tinymux
mailing list