andrewas wrote:The thing is, X3 is not a typical game. The OOS system is an obvious candidate for multithreading, since it naturally breaks down into smaller problems. If they were coding X3 today, multithreading OOS would be a no brainer. Its obviously harder to change it at this stage, but not impossibly so, and the payoff would be much higher framerates, and perhaps a more detailed OOS simulation.
Exactly what I was thinking. I can see the GoD, OOS, collision detection and the script monitor all as separate threads. I'm still hoping some of the devs agree with me
andrewas wrote:The thing is, X3 is not a typical game. The OOS system is an obvious candidate for multithreading, since it naturally breaks down into smaller problems. If they were coding X3 today, multithreading OOS would be a no brainer. Its obviously harder to change it at this stage, but not impossibly so, and the payoff would be much higher framerates, and perhaps a more detailed OOS simulation.
Exactly what I was thinking. I can see the GoD, OOS, collision detection and the script monitor all as separate threads. I'm still hoping some of the devs agree with me
Yes if you build a new engine.
But with the current engine they are interconnect so hard that removing one of those would severely hinder if not stop the other from working
So it would take alot of time to make all of those into seperate threads.
The Boz wrote:
Exactly what I was thinking. I can see the GoD, OOS, collision detection and the script monitor all as separate threads. I'm still hoping some of the devs agree with me
It would be more natural to split it into groups of sectors rather than different tasks. All the IS stuff would go in one thread, the OOS stuff would be in multiple threads on the other cores.
The Boz wrote:
Exactly what I was thinking. I can see the GoD, OOS, collision detection and the script monitor all as separate threads. I'm still hoping some of the devs agree with me
It would be more natural to split it into groups of sectors rather than different tasks. All the IS stuff would go in one thread, the OOS stuff would be in multiple threads on the other cores.
I was under the impression (although I could be wrong and would like to be corrected if I am wrong) that simply making an application multi threaded wasn't enough to make it utilise different cores on a processor and you actually had to instruct it to use the extra cores (or is this handled by the underlying OS and architecture). If this is the case, wouldn't this mean an extra level of complexity to this whole multi-threaded argument - deciding which threads go where on single core, dual core, quad core, dual quad core and 8 core systems?
The Boz wrote:
Exactly what I was thinking. I can see the GoD, OOS, collision detection and the script monitor all as separate threads. I'm still hoping some of the devs agree with me
It would be more natural to split it into groups of sectors rather than different tasks. All the IS stuff would go in one thread, the OOS stuff would be in multiple threads on the other cores.
I was under the impression (although I could be wrong and would like to be corrected if I am wrong) that simply making an application multi threaded wasn't enough to make it utilise different cores on a processor and you actually had to instruct it to use the extra cores (or is this handled by the underlying OS and architecture). If this is the case, wouldn't this mean an extra level of complexity to this whole multi-threaded argument - deciding which threads go where on single core, dual core, quad core, dual quad core and 8 core systems?
To my knowlegde windows handels the core assigments normaly.
But this is only if there are 2 threads/apps in the taskmanager window.
If the game only starts one windows thread it will run on the core that has the nothing to do.
So to answer your question game with multiple windows threads = windows handles the core assigment.
Game with only one thread = game needs to force the core assignments
This is based on what i have seen in windows with games/apps that use multiple cores
The rule is quite simple: one thread can execute on one core at a time. A single-threaded game will use only one core and cannot be made to use more no matter what you do. A multi-threaded game will make better use of multiple cores, but that doesn't mean that adding more and more threads is always good; if you have many more threads running than you have cores then you will actually start to reduce performance, because switching between threads takes time. It's not a LOT of time, admittedly, but enough that running 200+ threads on one core would reduce performance quite significantly. This is why "one thread per sector" (which was a real suggestion made at one point, I forget when) would be counterproductive.
Doing multi-threading properly needs to planned from the ground up when you're writing the game engine, because you need to evenly spread the work between threads to get the best advantage.
Vista is supposed to mostly neutralize the too many threads problem with its thread...juggling. I'm not enough of a techhead to say if it works or not. Of course, most X3 players probably don't have Vista.
@ Hinder: Everyone wants the Holy Grail Space Sim. Efforts to actually create it have been failures. The market isn't big enough, and its a huge amount of work. Freelancer was originally planned to be a lot more flexible but had to be trimmed down multiple times. X3 comes closest of the space games I've played but suffers from obvious lack-of-resources issues. Battlecruiser was the most ambitious but suffers from um... being Battlecruiser. *ahem*
Sandalpocalypse wrote:Vista is supposed to mostly neutralize the too many threads problem with its thread...juggling.
Whatever Vista does it cannot fix the fundamental problem, which is that the entire running state of the thread has to be saved before it can switch to another one.
Dual core processors are more advanced that singles anyway, due to new architectures etc.., but, mostly, while the game is only on one core, everything else can be put on the other, therefore making sue your game gets the max Ghz out of the core.
Doug97 wrote:So if it won't utilize more than one core why is a dual-core processor recommended in the system specs?
That's been answered at least half a dozen times. Although the game uses only one core, background tasks associated Windows, drivers and so on can run on other cores, resulting in noticeably better performance.
