Hi, quick question,
to what extent is this program able to use multiple core for simulation? I notice that my cpu usage overall for this game is hovering around 8% for my 16 core system, with simulation speed as high as it will go
thanks
Hi, thanks for the follow up. Do you think decoupling the AI and physics from unity's draw loop is possible to give you enough control to implement separating it into multiple threads? (physics/AI loop on a timer, influenced by the game speed setting, draw loop on maximum/vsync with some linear interpolation between physics frames) I don't have experience with Unity so I can't say for sure myself if this is possible
I wouldn't ask you to implement this right away since it's a lot of work, but using all of the CPU's cores seems like an important step for an evolutionary simulator that takes time to run and is bottlenecked by AI and heatmap calculations. just food for thought
A little more detail, as I've been doing some optimization work lately.
The draw loop and physics loops are already pretty well decoupled from other stuff in Unity. Physics actually runs multithreaded natively. Just as you suggest, I run all gameplay code including AI on a fixed timer, adjusted by game speed, while the draw loop runs as fast as the machine can handle. Unfortunately you can't just split some of your Unity objects off into different cores -- all the scripts run on the main thread.
Unity does have a Jobs system for performing multithreaded tasks. The trouble with applying it to NeuraQuarium is that (a) multithreaded Jobs cannot access objects on the main thread -- all relevant data must be copied and sent as raw values (b) the costliest calculations in the simulation involve large areas of the world -- all the objects in a Critter's visual field, with all of the properties used to process those objects into visual stimulus; or the set of all regions that contain a given scent; etc. Essentially, even if I were to convert some of these processes to multithreaded jobs it's not clear that the speed from using more cores would offset the cost of copying very large amounts of information back and forth hundreds of times.
I'm not done experimenting, though. Time will tell!
Hi, definitely interesting. I looked into the Jobs system briefly and it seems like a lot of others encounter the difficulty of trying to use Jobs without copying large amounts of static data between jobs and the main thread. It seems like Unity Jobs is a lot more "managed" in this way. Some people suggest using native multi-threading instead, like C# async/await, which are more flexible with concurrent data access and should be safe if your threads only need access to read-only data.
That said, you've got one of the most interesting evo sim projects going right now and I'm pretty excited to see where it goes. I even got to teach my gf about neural nets because it happened to be on screen at the time. crazy
That's awesome! Love to hear about the project inspiring knowledge.
For what it's worth: I did actually spend a day today converting the Vision system to use the Jobs system. The ultimate result was... about the same! The jobs run super quick on those multiple worker threads. But it doesn't actually shave off any frames per second or enable faster speeds.
I'm going to see if I can do something with the heat/gas diffusion system, which is a big cycle hog. If I could cut those times in half it would go a long way.
I was wondering as well if there would be any place in the code where you could use some GPUs to speed things up.
I noticed that the time seems to pass quite slowly on the largest map size with around 200 critters, even on x10, and though one process is indeed using 145% CPU, but it's spread out around different threads and no single thread is above 50% usage (except for a few peaks at 55~60%), and it doesn't seem to be using any considerable GPU either.
Should I be seeing higher CPU usage for this (at least one thread going up to 100%)? Or is this normal behaviour?
Running on Linux, in case that matters (Pop!_OS 22.04 LTS).
(Yes, I know I shouldn't be running a game on the largest map size, but I couldn't help myself and had to try it - even though I haven't filled barely a fourth of the map lol)