[BUG] CPU not fully utilized

[Camacha]

I have not started US² for a while now, so I updated and opened the application. I noticed significant slowdowns in simulations that used to run just fine, so I took a look at the CPU utilization. It tends to hover at either ~33% or about 50%, even when stressed with complex simulations. I checked the multi-core setting, which is on, system temperatures to make sure the CPU is not throttling, GPU usage to make sure that the game is not limited that way and I started another game to ensure that there is not some general problem with the system. When I run US² and also start a CPU stressing application like LinX, the graph goes right up to 100%. I toggled all the settings in the Settings menu, nothing changes.

Am I missing something here or has there been some update that might explain this behaviour?

[Jar]

It may be helpful to see your logs. Please run the performance test and send in the results.

[Camacha]

I ran the performance test and scored 27. I forwarded the output_log.txt to you via PM.

I noticed something about Compute Devices: 2 in there. Does that mean 2 logical threads/cores on the CPU or is it something else? Because the former somewhat lines up with the results, but is not right.

Edit: after experimenting with the affinity of the processor threads I can conclude US² only uses one thread. When it has only affinity with one core/thread, the program neatly fills it up to a 100 percent. When I add more threads, the load gets distributed, but not increased. Again, I have Use multi-core turned on.

I tried uninstalling and reinstalling the game yesterday. No change. Running US²  also seems to introduce this jitter/lagspikes with an interval of something like 0,5 or 0,25 seconds in other applications, which is for instance very visible when playing a movie or scrolling through a webpage. This makes me believe the issue is bigger than just the program only using one core. Before I could easily browse and forget I was also running US² in the background.

[C7]

I checked the performance reports, and I can't seem to find one with your username or information.

If you could, run the performance test, and send feedback. In the notes section, put something in there that I can use to find the report. Like Atten: C7, or Camacha's performance report. I'll look into what's causing slowdowns for you.

In regards to the cpu usage. It's very rare that you'll see an application use all of your cores to the max, there's a lot of reasons for this, including issues with thread priority on a modern operating system.

If you're interested in the technical details. There's a detailed explanation below. But, in regards to the stuttering, we have a pretty good idea what's causing that and we're working on a solution. We've made some major changes to the physics engine, and rendering systems that should address a lot of this. The current version you're using is an in-between, and this is a case of it getting a bit worse before it gets better.

Technical Info :

Part of the problem is that we're not going to achieve 100% efficiency of threading. We can only use multi-theading in very specific areas, and we try to focus on using it in high frequency code where we can get the most benefit. Unity engine is itself threaded and uses multiple processors for script execution and rendering tasks, but it's not "thread-safe". What that means is, we can't interact with Unity's data or objects inside of a thread that we make, we can only do so when we are allowed to in Unity's sequential script execution.

We get around this a bit by utilizing OpenCL, where we can dispatch a work packet or kernel, to various types of hardware, including a cpu or gpu. This lets us take advantage of lower level optimizations and feature sets that the hardware supports. (Such as sse). However, we currently have to call even the OpenCL job in sequence, which means, we start the work (let it compute on multiple processors), and then we continue after it has completely finished. Ideally we'd be able to just let physics run completely asynchronously in its own threads and "sync" with Unity when we're allowed to. Maybe we'll be able to do that at some point, but right now we're just doing our best to work around the issues at hand, to give the best performance possible.

[Camacha]

Thanks for the detailed explanation

I know programs often don't score a full 100% for a number of reasons, but US² was actually doing pretty well before. It might not have been a 100%, but it came pretty close. I remember liking that as opposed to the first US, where only one core was properly used. Finally my hardware could breathe.

Even if 100% is not fully achievable, just ~25% might be a bit sparse, especially since it seemed to work out before without too much issue. I understand this is a work in progress, so I am not complaining and eager to see what you might come up with.

Performance test report has been sent with the comment Performance test as requested by C7/Jar.

[C7]

Thanks for the performance logs. It seems what's taking the most time right now is the physics advance, especially in the galaxy simulation.

The good news, is that we're working really hard on getting that running better. We just don't have an update ready just yet.  (hopefully soon) Once that's out, it should help a lot in cases like this.

I did notice that we're not detecting your CPU as an OpenCL device, even though it's capable of running it. If we're running the gravity calculations on your GPU, it won't show up as usage under task manager. Since it's only watching the main processor.

One thing you can try is to get OpenCL working for your main processor. So we can test which is best suited to run our calculations.

You can find the drivers for Core series intel cpus on the page below.

https://software.intel.com/en-us/articles/opencl-drivers

If that doesn't work, you can try AMD's APP. Which works on processors that otherwise wouldn't even support OpenCL, with good results.

http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk/

[Camacha]

Interesting, with the x64 OpenCL driver installed the Task Manager (and Process Explorer) indicates a 35-42% utilization. This seems to be associated with an actual - and in relative terms substantial - gain in the frames per second department. Not quite there yet, but an improvement. Temperatures seem to indicate that this is roughly the actual number; if the processor was to be secretly slaving away I would see temperatures that are a little higher than these.

I have run the performance test again and this confirms my observations - a score of 57, rather than 27. I submitted it under the same description with part 2 added, maybe you guys can use it in development.

The numbers suggest there is still quite a bit to gain, so I eagerly await your coming improvements. Thanks for the hard work and taking the time to answer these questions

[Camacha]

All right, this somewhat surprised me - I bought a new GPU and ran the test again for the fun of it. I expected the results to be about the same, as the performance seemed to have been brought down by the CPU rather than the video card, but with the new card I scored a whopping 98. I guess the parts where the CPU is not the limiting factor added quite a few frames to the score, increasing the overall score quite a bit.

The underperforming simulation does have the frame rate it had before, so no surprises there.