DanCar Posted July 19, 2014 Report Share Posted July 19, 2014 (edited) Does someone have a high level design how this would be accomplished?Brainstorming I'm thinking how to split up threads:1. Different AI can be on separate threads2. Graphics3. Physics and path finding, simulation of the worldWould be nice to have high level profiling information to more intelligently discuss how to divide up the CPU cores.What is most of the CPU time spent on?The design should encompass 16+ cores, since in the not too distance future, ARM chips will have this. Already exist 8 cores. Edited July 19, 2014 by DanCar Quote Link to comment Share on other sites More sharing options...
Josh Posted July 21, 2014 Report Share Posted July 21, 2014 We're working on making 0 A.D. more parallel, and your outline roughly mirrors our plans. However, multithreading is a lot harder than it sounds - especially with our limited resources.I think the current consensus is that most CPU time consuming part is the simulation (pathfinder in particular) and AI. I few months ago I did a few runs in a profiler and the results are here (see cpuprofile1.svg - cpuprofile11.svg and note that this doesn't show javascript time nicely). 2 Quote Link to comment Share on other sites More sharing options...
HenryJia Posted July 22, 2014 Report Share Posted July 22, 2014 I might take a look into this after I finish expanding the ranking system.I did a bit of OpenMPI High Performance Compute Cluster programming about a year ago and this sounds kinda interesting Quote Link to comment Share on other sites More sharing options...
sanderd17 Posted July 22, 2014 Report Share Posted July 22, 2014 We want to wait with multithreading until the interfaces are designed well. Both things scheduled for multiple threads: the AI interface and the pathfinder interface, are scheduled for rewrite. Though so far, they've both been designed with multithreading in mind. So the AI API is designed to never touch the simulation data, and only get a copy of the simulation data every turn. And the pathfinder is designed to be able to only return a path the next turn, so it can also run in a separate thread (or multiple threads). And turns can only advance when every component (simulation, AI, pathfinder, ...) is done. As developing something that doesn't run in the main thread is hard work, we certainly want to wait with running the pathfinder and the AI in a separate thread. And if threading gets implemented, there should be settings or compiler flags to disable it for sure. Quote Link to comment Share on other sites More sharing options...
agentx Posted July 22, 2014 Report Share Posted July 22, 2014 I wouldn't say the pathfinder is slow, there are only some edge cases where it is extremely slow. If full map scans can be avoided it is barely noticeable at all. Quote Link to comment Share on other sites More sharing options...
DanCar Posted July 23, 2014 Author Report Share Posted July 23, 2014 We're working on making 0 A.D. more parallel, and your outline roughly mirrors our plans. However, multithreading is a lot harder than it sounds - especially with our limited resources.I think the current consensus is that most CPU time consuming part is the simulation (pathfinder in particular) and AI. I few months ago I did a few runs in a profiler and the results are here (see cpuprofile1.svg - cpuprofile11.svg and note that this doesn't show javascript time nicely).Thanks Josh for the info. If you document your plans, for example use a shared google doc, then you might find people willing to help out with the tasks. Quote Link to comment Share on other sites More sharing options...
Josh Posted July 24, 2014 Report Share Posted July 24, 2014 Thanks Josh for the info. If you document your plans, for example use a shared google doc, then you might find people willing to help out with the tasks.See http://trac.wildfiregames.com/wiki/GamePerformance for status on performance tasks. 1 Quote Link to comment Share on other sites More sharing options...
Jaydev Posted September 7, 2014 Report Share Posted September 7, 2014 How many cores can the game use @ present? Quote Link to comment Share on other sites More sharing options...
niektb Posted September 7, 2014 Report Share Posted September 7, 2014 Exactly 1 core is being used. Quote Link to comment Share on other sites More sharing options...
Yves Posted September 7, 2014 Report Share Posted September 7, 2014 Exactly 1 core is being used.That's not quite true. The game does stuff in multiple threads for random map generation, sound, some network related tasks and the user feedback functionality on the main menu. SpiderMonkey, our Javascript engine, runs JIT compiling of Javascript code in separate threads and some parts of the garbage collection happen off-thread. Saying the game is completely "single threaded" is technically wrong and just means that some very performance intensive tasks that could benefit from multithreading don't do it yet. Quote Link to comment Share on other sites More sharing options...
Jaydev Posted September 7, 2014 Report Share Posted September 7, 2014 Multicore support would be awesome when it comes out, since most people have at least two cores; and if it runs this nicely on one (and a little extra ), it'll be awesome when it it utilizes more cores! 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.