Dream daemon uses only a one cpu or more?
Dream daemon can establish colour's process?
Sep 25 2015, 9:20 am
Best response
|
|
Ter13
    |
Effectively, DD uses one core. The multithreading experiments done earlier in the last year were considered by Lummox and Tom to be failures.
|
Also the multithreading was really only intended to separate the UI and the server code; the server code itself was always going to be kept on one core, with the exception of map processing. Map processing is typically the least CPU-intensive thing the server does, though.
| |
Ter13 wrote:
Effectively, DD uses one core. The multithreading experiments done earlier in the last year were considered by Lummox and Tom to be failures. A tad off-topic but was there any more information given about this? Searching "multithreading" gives a whole bunch of responses. | |
A tad off-topic but was there any more information given about this? It's not worth looking into. Basically, Lummox and Tom wanted to try to make it so that map processing/sending had separate threads at some level. It didn't work out properly, though. Better to pretend it never happened, because all it did was make DS/DD unstable and in several cases that I tested slower. | |
So, my host is 2 cpu 3.3 ghz.
it's good ? | |
Ter13 wrote:
A tad off-topic but was there any more information given about this? I recall at one point the map was threaded, is that no longer a feature then? | |
Basically here's how the threading thing was meant to work: Turning threads on would allow the Dream Daemon frontend and the server processing core (including networking) to run on separate threads. The map-threads option allowed a further split by having the server run its map processing--which is essentially all read-only as far as most of the global values are concerned--in separate concurrent threads. Map processing is usually only a small part of what the server does, but it was something that could be threaded in theory.
In practice, because so much of the suite was written without threads in mind, a lot of things didn't communicate right. It was impossible to pin down, in a lot of cases, where things went wrong. world.Export() was a notorious offender, because even though it should have been setup properly it was still finding ways to screw up. (And heck, even without threading it still has some outstanding bugs I've been unable to trace. Chances are those issues are all related.) | |