For dummys: how will Unity 5.x affect the performance?

[Farex]

Greetings fellow Kerbonauts!

I was recently watching a lifestream from a man with a very efficient haircut and he mentioned how happy he was for the Unity 5.x upgrade and how he can't wait for it.

I myself am working in the IT-Branch, but have absolutely no clue about things like this, programming. Could someone please explain in a simple way how the Unity 5.x Update will affect the performance of KSP?

I am aware that it is currently a 32bit application, which also only uses 1 core. I am perfectly fine with all this stuff, it's my work. So, what will the changes be? Anyone?

[cantab]

Based on a statement regarding joint performance in the new PhysX, I'm predicting a 20-50% performance boost for single vessels in KSP. Not insignificant, but not enormous either.

[Foxster]

I think I'm going to wait and see before I celebrate any improvement gains.

Software has a tendency to woefully under-perform compared to hoped-for expectations.

[CalculusWarrior]

I think I'm going to wait and see before I celebrate any improvement gains.

Software has a tendency to woefully under-perform compared to hoped-for expectations.

I think this is one of those things which will perform differently for different machines (which is why Squad hasn't sated definitively how much of an improvement it will bring), so we really will have to wait and see how things go once the update drops.

[FyunchClick]

Software has a tendency to woefully under-perform compared to hoped-for expectations.

Well, there were a couple of times in my career as IT professional where a small tweak to something very basic (as in at very the basis of the application) just moved performance from painfully slow to fantastically smooth. This seems a biggie.

I'm more worried that it'll mean my fleet is dropping out of the sky left and right because all of a sudden things that had no problem being clipped do now, or some wing joint all of a sudden can't take the stress or something like that. But we'll see.

[mikegarrison]

Well, there were a couple of times in my career as IT professional where a small tweak to something very basic (as in at very the basis of the application) just moved performance from painfully slow to fantastically smooth. This seems a biggie.

I'm more worried that it'll mean my fleet is dropping out of the sky left and right because all of a sudden things that had no problem being clipped do now, or some wing joint all of a sudden can't take the stress or something like that. But we'll see.

IMO, it is unreasonable to expect saves to never break, especially with big changes to the software. Squad allows you to keep as many saves of as many versions of KSP as you want, so if you want to keep a 1.04 fleet flying in 1.04, you can. That's why I don't think they have any responsibility to keep your 1.04 fleet flying in 1.1.

[FyunchClick]

That's why I don't think they have any responsibility to keep your 1.04 fleet flying in 1.1.

And rightly so, so I wouldn't hold it against them if it breaks; I'm just hoping I'm able to continue this career as I've never made it further into the system than this.

[Kerbart]

IMO, it is unreasonable to expect saves to never break, especially with big changes to the software. Squad allows you to keep as many saves of as many versions of KSP as you want, so if you want to keep a 1.04 fleet flying in 1.04, you can. That's why I don't think they have any responsibility to keep your 1.04 fleet flying in 1.1.

Previous to 1.0 I'd say yes. But with the software out of beta one would expect features to be robust and bug free, and the modelling of things like aero and heat to be stable. That's what the extensive range of beta versions was for, after all. So honestly I don't expect my saves to break. That's the implicit promise Squad gave me when they rushed progressed to version 1.0

[cantab]

The save files are plain text, so you can usually tinker with them to make them work in the newest KSP, if for some reason it doesn't work "out of the box".

[Bev7787]

Unity 5.x allows the game to run over multiple cores or 64 bit for all platforms which means there is almost no more crashes due to memory limits.

[Luckless]

Unity 5.x allows the game to run over multiple cores or 64 bit for all platforms which means there is almost no more crashes due to memory limits.

Given the nature of the Kerbal Mindset, I would say that someone is still going to find a way... 64bit memory addressing just pushes the limits up to insane levels, but doesn't actually get rid of them after all... (Also memory handling isn't 'true' 64bit in most cases, and most systems break down well before their actual 2^64 max. Luckily it is still an insane amount of data before that happens, but, well, 'moar boosters' and whatnot... I expect someone is going to break it sooner or later.)

[p1t1o]

Unity 5.x allows the game to run over multiple cores or 64 bit for all platforms which means there is almost no more crashes due to memory limits.

How hard is this prediction? My gut just says that the upgrade moving us from single-core 32bit to multi core 64bit (lacking the horrible bugs the last 64bit build had) is quite a lot to wish for and for it to be resolved entirely, even if hypothetically possible, seems unlikely...to my gut.

Can I raise my somewhat pessimistic hopes a bit?

[cantab]

Better multithreading is regarded as near-certain, though a lot of people myself included think the physics of a single vessel won't multithread well.

Windows and OSX 64-bit versions are regarded as very likely, Unity 5 is free of the issues Unity 4 had with that.

In both cases it depends more on what Unity and NVidia (PhysX) do. Squad are porting the game to the new Unity version, it's the nature of using any "off the shelf" engine that the game developers don't work on the nitty-gritty details.

[Motokid600]

"Help even with 64bits my game still crashes!!!!"

Give it a few hours after release.

[Stratoroc]

I doubt single vessel physics will be multi-threaded, this will require some sort of part clustering to shuffle segments of a ship between cores. And this in turn requires of a major enough rework of the mess of parts flying in close formation that a ship is now, and I don't recall dev notes bringing anything like that up.

2 vessels on the other hand are separated and can be calculated on different cores.

[NecroBones]

Just as a point of clarification: The game is already multi-threaded, but the "long pole in the tent" is that the physics can only run on one core (because of a single thread) currently, and it's also the biggest performance bottleneck in the game. The new Unity 5 update is expected to have multi-threaded physics, but it's hard to predict what the performance gain is, because we don't know how it divides up the work, how much the threads will be blocking on one another, and how divisions within a single craft will work. Supposedly there are other performance gains coming, both from Unity 5, and from Squad's work over the last few months. But again, we just don't have an inside view with which to gauge that currently.

I think Cantab's estimate of 20% to 50% gain is probably fair, until we know more.

[eddiew]

Performance gain will be nice... 64 bit memory gain will be better, IMHO. Finally I can have all of the mods.

[DocMoriarty]

There is a lot more to 64-bit than just probable improvements due to multithreaded physics.

It starts with all memory access commands of the processor being up to twice as fast than now simply due to the double integer width compared to 32-bit. That alone will improve performance quite a bit, especially loading/saving stuff actions and other stuff that transfers a lot of data to/from the CPU.

From what i read here though the physics aren't the current reason for the lag and bottleneck of KSP so improving them won't do that much. It's the currently not very bright coded logic of resource (fuel, mono, electricity etc.) access which kinda creates a 'resource map' for every iteration (frame) of the vessel which is not very performant. A logic is needed where this is only created once and then only updated when the composition of the vessel changes (parts exploding, undocking, docking, separating etc.). If this isn't gonna be fixed vessels with 200+ parts will still be laggy, probably not that much but the times where we could do 1000+ part ships won't return without that being fixed.

Not holding my breath.

[Umlüx]

i expect my performance to be significantly worse. because of the metric sthitton of mods i am going to install

[cantab]

From what i read here though the physics aren't the current reason for the lag and bottleneck of KSP so improving them won't do that much. It's the currently not very bright coded logic of resource (fuel, mono, electricity etc.) access which kinda creates a 'resource map' for every iteration (frame) of the vessel which is not very performant. A logic is needed where this is only created once and then only updated when the composition of the vessel changes (parts exploding, undocking, docking, separating etc.). If this isn't gonna be fixed vessels with 200+ parts will still be laggy, probably not that much but the times where we could do 1000+ part ships won't return without that being fixed.

I've heard this before too. If it's right I'm going to be seriously ****ed off with Squad, if it turns out that all the lag, the seconds-per-frame pain, has been not because simulating KSP rockets is inherently hard and not because of the limits of PhysX or Unity but because of some utterly retarded idiocy on Squad's part.

If it's right.

[Xavven]

There is a lot more to 64-bit than just probable improvements due to multithreaded physics.

It starts with all memory access commands of the processor being up to twice as fast than now simply due to the double integer width compared to 32-bit. That alone will improve performance quite a bit, especially loading/saving stuff actions and other stuff that transfers a lot of data to/from the CPU.

From what i read here though the physics aren't the current reason for the lag and bottleneck of KSP so improving them won't do that much. It's the currently not very bright coded logic of resource (fuel, mono, electricity etc.) access which kinda creates a 'resource map' for every iteration (frame) of the vessel which is not very performant. A logic is needed where this is only created once and then only updated when the composition of the vessel changes (parts exploding, undocking, docking, separating etc.). If this isn't gonna be fixed vessels with 200+ parts will still be laggy, probably not that much but the times where we could do 1000+ part ships won't return without that being fixed.

Not holding my breath.

Holy WHAT? I'm an amateur programmer at best (VB .NET) and even *I* wouldn't do something that silly. Hm, maybe I should start working on a game.

[rudi1291]

Actually, i think there are more "features" like that in this game. Its like "Just make it work, we can still make it faster/better when it works". The "make it faster/better" part of it just never happened. And i wouldn´t blame SQUAD for this if this game was still in alpha/beta...

[Padishar]

There is a lot more to 64-bit than just probable improvements due to multithreaded physics.

It starts with all memory access commands of the processor being up to twice as fast than now simply due to the double integer width compared to 32-bit. That alone will improve performance quite a bit, especially loading/saving stuff actions and other stuff that transfers a lot of data to/from the CPU.

From what i read here though the physics aren't the current reason for the lag and bottleneck of KSP so improving them won't do that much. It's the currently not very bright coded logic of resource (fuel, mono, electricity etc.) access which kinda creates a 'resource map' for every iteration (frame) of the vessel which is not very performant. A logic is needed where this is only created once and then only updated when the composition of the vessel changes (parts exploding, undocking, docking, separating etc.). If this isn't gonna be fixed vessels with 200+ parts will still be laggy, probably not that much but the times where we could do 1000+ part ships won't return without that being fixed.

Not holding my breath.

I don't believe there is a significant difference in memory bandwidth due to running x64 rather than x86. Modern CPUs are all highly abstracted away from the instruction set and what they do internally is considerably different to what the instruction set implies.

The resource handling code, while it is currently both very inefficient and buggy, hasn't changed significantly since before the days we were able to launch 1000+ part vessels. Yes, improvements in this area are long overdue and should result in significant performance improvements, but there are also a number of other recently added features that are stressing the CPU, especially with higher part counts (e.g. new heat system, new aero system).

[godefroi]

Unity 5.x allows the game to run over multiple cores or 64 bit for all platforms which means there is almost no more crashes due to memory limits.

Multiple cores and 64 bit are unrelated; Unity 4.x already allowed the game to run on multiple cores, and indeed KSP <1.1 already does; the problem is that almost everything is done by a single thread, which generally would be scheduled on a single core (though neither KSP nor Unity guarantees that, it's up to the OS to decide).

[xtoro]

Since there's nothing official on the table with regards to U5 plans, everything is just speculation, theory and rumors at this point. U5 could bring some fantastic performance increases, but only if Squad actually takes advantage of them and does some serious optimizations. You can go to medical school where you're given all the tools, knowledge and opportunities to become a doctor, but that won't happen if you don't use any of those things afforded to you.

At this point I'm not expecting much performance increase because it hasn't been stated officially. And I've learned my lesson of being excited and optimistic of new versions EXPECTING better performance when for me and many others according to threads on here, the opposite happened. I guess we just wait and see how much effort and skill is actually put into it to take advantage of U5's offerings.