Reduced precision for better perfomance

[Sasza22]

Would you mind if the game ignored resource amounts below 1g?

As for now it does all the calculations down to miligrams and even micrograms. Iirc it tgnores thermal transfer below a certain mass but there`s still mcg debris piles and mcg gas puffs flying around taking pc resources for stuff nobody really cares about. If the game just ignored those small amounts it would both help (at least a bit) with perfomance but also make vacuuming rooms much faster and potentially surface breaches more dangerous.

Or another question: Would you take reduced calculation accuracy for more performance? Like if thermal calculations are done once per 2 seconds instead of 4 times per second (or however often they are currently done). Same for diagnostics and other stuff that won`t break the game if it happens less often (i imagine pathing can`t take that treatment).

A change like this might break certain designs and cause weird bugs but personally i think it`s worth it if it can improve the gameplay.

[DolphinWing]

It reminds me a long time ago they are testing some small mass heat transfer changes but later revert it back.

It took me some time to find those patch notes. Not sure how are they going now.

Spoiler

https://forums.kleientertainment.com/forums/topic/129458-spaced-out-update-462129/

• Experimental: Allow temperature transfer of small ores less than 10 grams

https://forums.kleientertainment.com/forums/topic/129835-spaced-out-update-463486/

• Reverted "Experimental: Allow temperature transfer of small ores less than 10 grams" as it was causing issues that need further investigation.

 

 

[SharraShimada]

What do you propose? If you give a computer the task to calculate the result of squareroot 18, it will calculate exactly this. It does not calculate to approximate squarerooot 18.

Sure you can just display the first 2 digits and limit it to kilograms instead of grams. But it wont reduce the workload at all. The opposite is true if you start to round, because rounding is always a step above calculations.

[MrAnimaniac]

Not an IT guy but the format you're working with has an impact on calculation. All this seems to be surprisingly complicated but at least working with less precision (float32 instead of 64) can make things faster. Sometimes.

However, I understood the suggestion more akin of ignoring small quantities. So basically you delete a tiny fraction of e.g. CO2, hence it doesn't bother your computer.

If you would do this, you would need to have a "quantization" of used and produced resources ∆m ≥ depictable threshold. Most likely there is sth like this already so the values would only need to be adapted.

So basically it is like running the game on a coarser sieve, neglecting elements earlier and therefore having less calculations per tick. I totally can't judge the trade-off of this operation.  ¯\_(ツ)_/¯

[LadenSwallow]

Given that 18 isn't an exact square, when your computer 'calculates' the square root as anything other than a symbolic representation of square root of 18 it will have chosen to round somewhere.

When it is calculating a decimal approximation, it will follow some many term polynomial, where more terms for the polynomial give greater precision. Fewer terms will require less time/power to calculate. Essentially this is how pi is determined to different degrees of accuracy.

[Fradow]

17 hours ago, Sasza22 said:

Would you mind if the game ignored resource amounts below 1g?

I would not but ....

17 hours ago, Sasza22 said:

A change like this might break certain designs and cause weird bugs but personally i think it`s worth it if it can improve the gameplay.

That's the big assumption: reduce precision, or even reduced rate of physics calculation would improve performance.

As an educated guess from a developer in a different field: it would not, or not nearly to the degree you would expect. Reduced precision would change absolutely nothing, because there just isn't a less precise unit (in code) that would make things faster, and reduced rate of physics calculation wouldn't change much, since physics calculation is pretty optimized and likely not a low-hanging fruit for performances.

[Gurgel]

Actually, all this is in the game. ONI already uses short floats. There is likely no performance to be gained at that end. ONI already limits heat transfer: https://oxygennotincluded.fandom.com/wiki/Thermal_Conductivity 

I assume the decision whether to transfer heat is something that is not decided each tick for those masses that fall below the limits and have no transfer. The usual way would be to re-visit them each much less frequently, say every second or even less often. Hence they do not significantly contribute to computational effort. 

This leaves just one possibility: Change the limits currently in place. That would probably be a really bad idea as the current limits already lead to artefacts and hard to explain observations.

 

 

[Saturnus]

Another way to improve performance that only very marginally reduces precision would be to divide the map into 4 or more frames with the physics calculations for each frame running simultaneously on different threads. It would create minor inaccuracy in the cells where frames meet but it would increae the performance almost by a factor equal to the number of frames the map is divided into as long as that number is lower than than the number of logical CPU threads available. However, I don't think it's possible using the current API. 

[gabberworld]

If talk about performance then first look that PC not run out off memory. I to see that allot people use only 8 gib memory. That is not enoh for run game and OS at same time.

Anyway if look how this game acts there allot places where they could make it differently for better performance. But thing is that any change what they make may affect also the mods.

[Ixenzo]

1 hour ago, gabberworld said:

If talk about performance then first look that PC not run out off memory. I to see that allot people use only 8 gib memory. That is not enoh for run game and OS at same time.

I have indeed noticed ONI consuming almost as much as a heavily modded RP-1 KSP install. Well, KSP hits the 16gb ceiling in the main menu whereas ONI stops short of it after hours of runtime. Should've gotten that second pair of sticks when they didn't cost three times as much, huh.

[Red Shark]

4 hours ago, Saturnus said:

Another way to improve performance that only very marginally reduces precision would be to divide the map into 4 or more frames with the physics calculations for each frame running simultaneously on different threads. It would create minor inaccuracy in the cells where frames meet but it would increae the performance almost by a factor equal to the number of frames the map is divided into as long as that number is lower than than the number of logical CPU threads available. However, I don't think it's possible using the current API. 

I had assumed this was something they were adding in Spaced Out with the multiple asteroids (inaccuracies inside the neutronium borders wouldn't matter, after all) but as far as I know, it's all represented as a single map still (with limited camera bounds)

 

[tuxii]

I think the lowest hanging fruit would be to give us the option to disable something recently implemented that I think caused a massive performance loss when it was implemented.

Disable Diagnostics

[Gurgel]

17 hours ago, Saturnus said:

Another way to improve performance that only very marginally reduces precision would be to divide the map into 4 or more frames with the physics calculations for each frame running simultaneously on different threads. It would create minor inaccuracy in the cells where frames meet but it would increae the performance almost by a factor equal to the number of frames the map is divided into as long as that number is lower than than the number of logical CPU threads available. However, I don't think it's possible using the current API. 

Yes. I believe we already have established several times over that this is not possible due to engine limitations.

[Jann5s]

I don’t think that debris is the most important consumer now, we also have pipes, rails and path finding 

[SackMaggie]

A big jump possibly be using unity new technology eg job system but it require a portion of code rework which I don't think it gonna happen.

Anyway take a look at @Peter Han mod, It's actually awesome!.

 

[Sasza22]

Well my thinking was that if there`s less stuff the system has to worry about and does it less often it should help with performance. Quite possibly i blamed the wrong things for the performance loss. I mean there`s quite a bit of tiles in the game and if each gets to calculate stuff 4 times per second it`s a lot of work. Still i have to admit i don`t know if that`s the main prformance hog.

I probably should have phrased the OP a bit differently.

[gabberworld]

20 hours ago, Sasza22 said:

Well my thinking was that if there`s less stuff the system has to worry about and does it less often it should help with performance. Quite possibly i blamed the wrong things for the performance loss. I mean there`s quite a bit of tiles in the game and if each gets to calculate stuff 4 times per second it`s a lot of work. Still i have to admit i don`t know if that`s the main prformance hog.

I probably should have phrased the OP a bit differently.

there is something in game what does use multithread if its Simdll then you should not worry too much about calculations, my biggest concerns is still the drawing part what is used mostly in one core