Does linux build have different binary?

[juni3227]

I was just surprised with the CPU utilization. Although it never goes over 16%.

 

Framerate was bad, but dupes were much more responsive.

[JRup]

A different binary as compared to what? Windows? Mac?

I'm inclined to interpret your question more as "a different code base" rather than binary... Of course, I'd also like to have a version built in assembler language just to let some naughty devs know the terrific pains of it... But having Unity in the mix precludes most of any so called progress, lol.

My best guess is that the linux version does take advantages of OS optimizations, but I'm not a pro on that obscure knowledge. All I know is that I haven't installed any winDos on anything other than virtual machines for ages now. I used to have fun on 7, though...

I can't begin to imagine the growing pains 11 will bring to the table...

[juni3227]

20 minutes ago, JRup said:

A different binary as compared to what? Windows? Mac?

I'm inclined to interpret your question more as "a different code base" rather than binary... Of course, I'd also like to have a version built in assembler language just to let some naughty devs know the terrific pains of it... But having Unity in the mix precludes most of any so called progress, lol.

My best guess is that the linux version does take advantages of OS optimizations, but I'm not a pro on that obscure knowledge. All I know is that I haven't installed any winDos on anything other than virtual machines for ages now. I used to have fun on 7, though...

I can't begin to imagine the growing pains 11 will bring to the table...

In windows, the game just uses only 2 treads.

[Fradow]

14 hours ago, juni3227 said:

In windows, the game just uses only 2 treads.

That's not a Windows peculiarity, that's how the game is coded. Because the game use Unity (and didn't go out of its way to use several threads), there are only 2 threads see Yobbo explanation below (there might be more in some circumstances, I don't know the details): the main Unity thread, and the Simulation thread (the "sim" is the C++ codebase that simulates a lot of things in the game such as heat exchanges, gas movement, liquid flow etc...)

If a tool reports a low CPU usage, it's generally because it averages over all cores, but you are still bound by the single-threaded performance of your CPU (or RAM timing).

[Yobbo]

10 hours ago, Fradow said:

there are only 2 threads

 

11 hours ago, juni3227 said:

In windows, the game just uses only 2 treads

Please don't continue to repeat this. Both i (here) and others (here) have done actual testing of this claim, and the game has more than two threads doing work, both on Linux and Windows.

The reason for low CPU utilization here is likely that the main thread is being switched between cores to load balance. Although the average utilization is low, there is probably one thread which is using a significant portion of a core. As it is being switched between cores this is not visible in the core utilization graph.

To see the actual utilization by thread you can use something like the "top" utility. I'm not sure of a graphical alternative, but in a command line "top -Hp `pgrep Oxygen`" should show you all the threads owned by the ONI process.

[Fradow]

Corrected. I don't know how to properly phrase it, but ONI, while having some multi-threading (as you shown), is still mainly bound by single-thread performance, as the workload is not multi-threaded enough to properly use all cores of a CPU and the main Unity thread (I think) still has most of the work to do. That statement should be correct, but let me know if I got it wrong again.

Incidentally, some things could be moved to other thread to better distribute the load and have better performance, though it's easier said than done, and off-topic.

[Yobbo]

7 hours ago, Fradow said:

Corrected. I don't know how to properly phrase it, but ONI, while having some multi-threading (as you shown), is still mainly bound by single-thread performance, as the workload is not multi-threaded enough to properly use all cores of a CPU and the main Unity thread (I think) still has most of the work to do. That statement should be correct, but let me know if I got it wrong again.

Incidentally, some things could be moved to other thread to better distribute the load and have better performance, though it's easier said than done, and off-topic.

Well, yes. But usually for me the main thread doesn't actually hit 100% core utilization and start to restrict performance until well into the late game. It would fall over much earlier if it weren't already doing the majority of the work in other threads.

But anyway even then my CPU utilization graph (like in the OP) will still show relatively even usage. I checked it out and found the main thread was being shuffled from core to core, giving the illusion of even utilization even when it was in fact restricted by the main thread. I would guess with 16 cores it will probably never go much over ~18% total CPU utilization (around 3 full cores worth).

I'm not sure if that core shuffling thing helps performance. Probably it just extends CPU lifetime a bit by not burning out one core more than the others.

[blakemw]

On 3/18/2022 at 3:44 PM, juni3227 said:

 

Framerate was bad, but dupes were much more responsive.

Interestingly I once did some comparisons with Cities Skylines between Linux and Windows. On Linux it simulated considerably faster (probably about 30% faster) so the game speed was better in large cities, but the frame rate was considerably lower. I don't know nearly enough to have an explanation for this, but it could be because Unity uses Mono, and Mono was developed in the opensource world, so maybe it just works better on Linux than Windows. The framerate thing is probably just because linux graphics drivers are worse.

[Gurgel]

On 3/18/2022 at 3:44 PM, juni3227 said:

Framerate was bad, but dupes were much more responsive.

The second one may be because Linux has much better task-switching than Windows. 

[babba]

A good "hack slimmed" Gaming Windows uses 1% cpu max permanently. As soon people have 30% tasks jumping in temporary with tons of bloatware its game over. Its like in the old days, when a 500 byte mouse driver was ace. Most people run bloat jittery systems, without knowing or caring. New audio headset connected..."Oh, 1GB RAM resident audio driver for cool interface graphics - What does that mean ?"

ONi 2 - Now with 128 core support

[gabberworld]

17 hours ago, babba said:

ONi 2 - Now with 128 core support

 

if they split main core for 2 separate part that would already give huge step. for old pc it not help mutch but it does allot for newer pcs.

we could also wait when cpu marked start todo that. but i guessing that fill be a long wait

[Omdev]

On 3/23/2022 at 1:24 AM, babba said:

A good "hack slimmed" Gaming Windows uses 1% cpu max permanently

Is there any proven guide for this?

[babba]

One can open a task manager and look for cpu hungry tasks

I`m currently doing some heavy calculation tasks. In idle its great to get a system down to ~1% cpu. If there is unexpected tasks and/or tasks you or the system never need, then it could be a good idea to get rid of them.

Windows 10 task manager example, looking and checking tasks and running processes. The simple overview often does the job, to check what is using cpu and ram.

11 minutes ago, Omdev said:

Is there any proven guide for this?