09-23-2009, 01:09 PM
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.