Please dont hijack this thread with a debate about the pros/cons of multi-threading!
So since it appears valve has aborted the multi-threaded srcds, couldnt we just make a plugin that overrides the normal game engine frame routine with helper threads instead of sequential calculation of each client's state. For each client there is a set of things that the server has to calculate each frame. By spawning one helper thread per client, then letting them run on any available logical core, a dual core server theoretically would finish calculating a tick in half the time. This of course is pointless on a relatively small server, but a 20 player iceworld server could definitely see major performance increase when full. At this point a 20 player 100tick iceworld running on a 2.0ghz xeon processor starts to drop tickrate at about 15 players. Without multi-threading a dual core server is no better than a single core unless you are running 2 servers on it. But even if you are running a server per core, while one server may only use 20% of its core the other 80% could be available to the 50 slot d2 dmatch server if it were multi-threaded. Of course, since the source for srcds itself is not available(for obvious reasons), this means sig-scanning for the snapshot generating function, finding the loop that renders each client's snapshot, spawning a thread to calculate each client and blocking execution on a counter that is decremented as each thread finishes.
yeah, just an idea, Im a srcds coding noob, but i have experience coding programs that break iterative tasks into multiple threads for increased performance.
So since it appears valve has aborted the multi-threaded srcds, couldnt we just make a plugin that overrides the normal game engine frame routine with helper threads instead of sequential calculation of each client's state. For each client there is a set of things that the server has to calculate each frame. By spawning one helper thread per client, then letting them run on any available logical core, a dual core server theoretically would finish calculating a tick in half the time. This of course is pointless on a relatively small server, but a 20 player iceworld server could definitely see major performance increase when full. At this point a 20 player 100tick iceworld running on a 2.0ghz xeon processor starts to drop tickrate at about 15 players. Without multi-threading a dual core server is no better than a single core unless you are running 2 servers on it. But even if you are running a server per core, while one server may only use 20% of its core the other 80% could be available to the 50 slot d2 dmatch server if it were multi-threaded. Of course, since the source for srcds itself is not available(for obvious reasons), this means sig-scanning for the snapshot generating function, finding the loop that renders each client's snapshot, spawning a thread to calculate each client and blocking execution on a counter that is decremented as each thread finishes.
yeah, just an idea, Im a srcds coding noob, but i have experience coding programs that break iterative tasks into multiple threads for increased performance.
irectInit(char const *)" (?DirectInit@CRegistry@@UAE_NPBD@Z)
hysicsSimulate( void )). I still have to find where the engine loops to call this for each player then from there I can probably find the function that is used to decide what info about other clients and the world gets sent to each client. But finding this per tick physics generation routine is a huge step forward in itself if it is indeed what I think it is.
