[MUD-Dev] [TECH] Server Bottlenecks

Mike Shaver shaver at off.net
Thu Sep 4 01:39:57 CEST 2003


On Sep 04, Eamonn O'Brien wrote:

> Maybe this is a dumb question but why do you need all those
> threads?

For some programming models, threads are a more natural expression
of control than explicit state machines and cooperative
"scheduling".  It can be a lot easier to say

    before();
    blocking_db_call(query);
    after();

than to split the "after" part into a separate callback, and pass
the state around, handle timeouts and error conditions, etc.  If
you're writing an explicit state machine you often end up
reimplementing a good chunk of "threads" yourself, since you have to
choose the next work-chunk to process, save and restore state, make
sure that you do that properly around anything that can block, &c.
(Make sure you update that code when your in-memory dataset grows to
the point that you want to put it on disk, and now the lookup could
block on disk I/O.)

So now you're saying "I can write a better scheduler than the OS
guys did", _and_ you're saying "that's a better way to spend my time
than on writing the killer game systems that will make my game
better".  A pretty bold statement, but I won't pretend that I know
enough about your situation to say that it's untrue. =)

Even if threads are slower -- and we would want to compare code
written "well" for threads against code written "well" for a state
machine; you can write naive expressions that will suffer under
either model -- hardware tends to improve faster than software
practices.  I suspect that most large systems have more problems
with bugs and "maintainability" than they do with performance, and
that the gap will only tend to increase.  (And it's often easier to
optimize a correct system safely than to make a fast system safe, at
least in my meagre experience.)

I guess people don't _need_ all those threads any more than they
_need_ to use high-level languages.  But it turns out that it's
usually a win to write in the high-level languages, even if it does
cost you a little bit of performance.  To stretch the analogy
further, you can also "drop down" to an explicit state machine in
order to keep CPU affinity for your high-temperature networking
thread or something, just as you can "drop down" to assembly for a
tight computation loop.

Mike
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list