Question about the 1.1 update

[TheTom]

[quote name='OrtwinS']That is quite a choice of wording.
Can you link to the research?
Sounds like an interesting read.[/QUOTE]

Sure.

[url]http://bugs.kerbalspaceprogram.com/issues/5136[/url]

I personally found that when starting to try to launch career build satellites which had by force (The larger ones were not available yet) a lot of small batteries.

To quote from the discussion there:

[QUOTE]This is almost certainly caused (or at least made much worse) by inefficiencies in the Part.RequestResource function that is called on each fuel cell part each frame to add the electricity to the vessel. Each call loops through all the parts in the vessel building a list of all the EC storage parts (in a way that creates unnecessary garbage), works out which ones of them should get filled up and then splits the amount of EC being added between all those parts. So, in addition to the garbage thrash, this is effectively O(n^2) so as the number of parts increases the performance suffers drastically.
[/QUOTE]

Obviously this call (Part.RequestResource) is not limited to electricity. Which means any larger machinery (many tanks etc.) gets quite a lot of them in a VERY inefficient way.

This means when going from 10 to 100 parts, you do not get 1/10th the performance but a LOT Worse. Which means optimizing this will give you a LOT more than "30%" performance gain for any "serious" craft (i.e. obviously not a 10 part micro satellite). Edited November 24, 2015 by TheTom

[abowl]

Alot of games have already switched to Unity 5. But not my favorite. First world problems?

[Red Iron Crown]

[quote name='*Aqua*']GPUs and CPUs are optimized for fast 32 bit floating point operations because that's the current state of the art. Games like KSP which may profit from 64 bit floats are a seldom. Your average shooter or driving game doesn't need 64 bit floats. And those use cases are what the game engines are optimized for. As you said you can calculate either 8 floats per cycle or 4 doubles. Changing everything to double will [I]half[/I] the speed of floating point calculation.[/QUOTE]
Worse than half, on most consumer hardware. Gaming GPUs typically do double operations at 1/6th the rate of floats (or worse!), you have to step up to Tesla cards and the like to get good double performance.

[Temeter]

[quote name='*Aqua*']All games with PhysX with enabled GPU acceleration calculate their physics using the GPU. The first game which allows that is Mirror's Edge.
KSP uses PhysX too but GPU acceleration for it isn't enabled.

The current Tomb Raider allows hair 'physics' to be calculated on AMD GPUs.[/QUOTE]

Afaik games like mirrors edge only calculate some extra effects on the graphics card, everything else goes over the CPU. Which is little more than a PR move.

[Kobymaru]

[quote name='parameciumkid']- Physics in Unity 5 has been massively improved under the hood, now supporting multi-threaded calculations, so situations with lots of parts on screen will generally have much better framerates. There is suspicion that this may not apply to large single vessels, but it hasn't been clearly confirmed one way or the other by SQUAD last I heard.[/QUOTE]
Pretty sure that MaxMaps "confirmed" it on one of his Squadcasts, implying that it also applies to single vessels.
Then again, MaxMaps was not a core dev, and I doubt he's a PhysX expert. So chances are, he just misunderstood something.

[*Aqua*]

IIRC Mirror's Edge only had glass and tarpaulins as physic enabled objects. There wasn't much else which needed physics. I remember it was very demanding. My Geforce 9600 GT I had back then wasn't powerful enough. (It was the second or third fastest Nvidia graphics card at that time.)


I wonder how the devs will use the updated physics engine of Unity 5. Will it be multithreaded for each (group of) part or ships? The first will provide a substancial performance increase. The later will only help when having several ships in the vicinity. Additionally the physics engine itself will be faster.
I really wonder how the perfomance will change. I hope I can fly vessels with 400 parts with much less lag.

[Terwin]

[quote name='TheTom']Now, befor you guys come out and scream that this is ridiculous - it is NOT physics. Physics as it is can handle a LOT more than we can do today. Anyone with not 10 years software experience but 2 years KSP experience will remember how we could run multiple times the current part count in the past. Physics has not changed a lot during these times.
[/QUOTE]

I would think that the aerodynamics change to start accounting for things like occlusion, lifting bodies, and general non-soup-like atmosphere would be considered a fairly substantial change.

And while it may not be optimal, a first-pass coding of things like occlusion may not bother to check for the presence of an atmosphere before performing calculations, giving a slow-down both in and out of atmosphere for the sake of providing better atmospheric effects.(edit: almost forgot: occlusion is not just for atmospherics, it also affects solar exposure and other things)

While I am hopeful for 1.1 to have a nice performance boost, performance optimization is not a simple task, especially with a substantial existing code-base and a rather avid fan-base.

[adsii1970]

I do have a question about 1.1.0 - and it involves making a mod. I have Unity 4; will I be able to use mods created in Unity 4 with the new KSP operating system being based on Unity 5?

[NecroBones]

[quote name='Daid']
General rule of optimization, do not expect magic. 5% to 30% is a rule of thumb (I'm an software engineer, 10 years of experience)
[/QUOTE]

[quote name='TheTom']Thanks for demonstrating the sad state of software engineers.
[/QUOTE]

lol, well, it's just that when you see the sun rise every morning, you start to expect that you can rely on it.

Sadly, that's often the case in the software field. Lots of improvements/optimizations, or an architecture change (etc) often means 5% to 35% in my experience too (17 years IT experience). Every once in a while you get surprised and some brilliant new architecture might get you a 2x or 3x improvement, but that's exceedingly rare IMHO. Usually if you see those kinds of improvements, it's because the initial implementation was absolutely terrible from an efficiency standpoint.

The thing is, what makes this less predictable is that the biggest bottleneck in the game (the physics) is being enhanced from a single-threaded to a multi-threaded architecture. So I wouldn't be surprised if we see a 50% increase in the number of parts you can put on a ship before your framerate drops to the same amount, but it's hard to say whether it'll reach (or exceed) that without knowing more. Some tasks lend themselves well to multithreading, and others only see modest improvement in performance.

EDIT: This is all speculation at this point, of course. I wouldn't exactly stake my reputation on any of this, since we just don't have any data right now. My only point to this was that yes, modest gains are usually what you want to expect for any optimization pass. It's not pessimism, it's just setting appropriate expectations. ;) Edited November 25, 2015 by NecroBones

[*Aqua*]

[quote name='adsii1970']I do have a question about 1.1.0 - and it involves making a mod. I have Unity 4; will I be able to use mods created in Unity 4 with the new KSP operating system being based on Unity 5?[/QUOTE]
What we know is that all GUI related code will probably break. Also wheels will work differently (Kerbal Foundries & Adjustable Landing Gear will break).

My guess is that around 90-95% of the mods won't work in 1.1.

[TheTom]

[quote name='Terwin']I would think that the aerodynamics change to start accounting for things like occlusion, lifting bodies, and general non-soup-like atmosphere would be considered a fairly substantial change.

And while it may not be optimal, a first-pass coding of things like occlusion may not bother to check for the presence of an atmosphere before performing calculations, giving a slow-down both in and out of atmosphere for the sake of providing better atmospheric effects.(edit: almost forgot: occlusion is not just for atmospherics, it also affects solar exposure and other things)

While I am hopeful for 1.1 to have a nice performance boost, performance optimization is not a simple task, especially with a substantial existing code-base and a rather avid fan-base.[/QUOTE]

And again. aerodynamics are not handled in the physics code (i.e. PhysX) but in a separate replacable subsystem. THis is how FAR works. Among other things because this type of simulation is beyong what PhysX is handled to do.

And in this particular case (aerodynamics) you ahve some seriously performance optimized code in FAR already.

[Daid]

[quote name='TheTom']What makes KSP slow are:
*SIP*[/QUOTE]
Did you profile the code? No? Then don't say what makes it slow. Profiling before optimizing is the only way to do optimizations. Assumptions in this area are usually the biggest ....up.

[quote name='*Aqua*']GPUs and CPUs are optimized for fast 32 bit floating point operations because that's the current state of the art. Games like KSP which may profit from 64 bit floats are a seldom. Your average shooter or driving game doesn't need 64 bit floats. And those use cases are what the game engines are optimized for. As you said you can calculate either 8 floats per cycle or 4 doubles. Changing everything to double will [I]half[/I] the speed of floating point calculation.[/QUOTE]
AUCH. Your post just hurts from bad info.

Floating point calculations in modern CPUs are done in 80bits, always. 32bit operation? Don't care, first turned into 80 bits internally in the CPU before the math is done. As long as all your data fits in the cache, it's the same speed. Else you're just having memory bandwidth issues.
GPUs are the most complex things you can think off. While the can do 32bit or 64bit operations just fine, it's the memory access that is speed wise the problem here. As well as branching. It's a bit hard to explain in a short post. But GPUs work by doing the same math on a lot of numbers at the same time, exactly the same math. Got a "branch" (choice) in your code? GPU needs to do it twice, once for both results. You also need a certain set of problems that are usable on the GPU. Physics can be one of these problems, but once again, do not expect miracles.
But once again, GPUs are mostly memory bandwidth constrained in these sort of problems.

[quote]The only reason why software slowly changes from 32 bit integers to 64 bit integers in the last decade is because there's a need for more addressable memory.[/quote]
We didn't switch to 64bit integers (we had those in a Pentium 3 already just fine), we switched to 64bit MMUs with 64bit address space. That's what the 64bit OS and capable CPU is about, and 64bit KSP as well.

[TheTom]

[quote name='NecroBones']lol, well, it's just that when you see the sun rise every morning, you start to expect that you can rely on it.

Sadly, that's often the case in the software field. Lots of improvements/optimizations, or an architecture change (etc) often means 5% to 35% in my experience too (17 years IT experience). Every once in a while you get surprised and some brilliant new architecture might get you a 2x or 3x improvement, but that's exceedingly rare IMHO. Usually if you see those kinds of improvements, it's because the initial implementation was absolutely terrible from an efficiency standpoint.

The thing is, what makes this less predictable is that the biggest bottleneck in the game (the physics) is being enhanced from a single-threaded to a multi-threaded architecture. So I wouldn't be surprised if we see a 50% increase in the number of parts you can put on a ship before your framerate drops to the same amount, but it's hard to say whether it'll reach (or exceed) that without knowing more. Some tasks lend themselves well to multithreading, and others only see modest improvement in performance.[/QUOTE]

And again that ridiculous claim pops up. The biggest bottleneck in the game.... is not physics (as: physX) to start with. Ups. Here you logic goes. Despite claimed 17 years.
And this is btw. also extremely simple to paralellize into a number of threads. How? Paralellize: PhysX (body motion), Aerodynamics calculation, Resources (one thread per resource), Heat. Introduce SMALL delays - for example calculate aerodynamics on frame behind. Noone will see the difference, suddenly you can use a lot more threads in parallel. Heck, I would even say you do not need to handle most resources every frame, to start with.

Yes, the code in KSP is partially quite sub standard. Which puts it on par with a lot of cod I have seen. 2x-3x gains are not "exceedingly rare", I have seen quite a lot of them. A ton of code out there in companies is written quite badly thanks to "senior" developers with 5 years programming experience making design decisions.

For example - you (like many) claim the problem is PhysX - but before some changes done to resource allocation and aerodynamics... one could launch much larger ships than today.

[I_Killed_Jeb]

this thread is a classic example of the dunning-kruger effect

[Francois424]

[quote name='I_Killed_Jeb']this thread is a classic example of the dunning-kruger effect[/QUOTE]

Well everything is pure speculation afterall. The real goodie will be at Christmas or in January.

[Hannu]

[quote name='*Aqua*']All games with PhysX with enabled GPU acceleration calculate their physics using the GPU. The first game which allows that is Mirror's Edge.
KSP uses PhysX too but GPU acceleration for it isn't enabled.[/quote]

OK. GPU acceleration may be good reason to use floats in such games.

[quote]Games like KSP which may profit from 64 bit floats are a seldom.[/quote]

Under these conditions it is mistake to choose 32 bit physics engine in this game. It is also not good reason to keep an option to use GPU. Especially, because physics of KSP is very simple and it would not have been a huge task (compared to whole game) to program physics from scratch. Graphics, UI etc. is much more demanding (at least from my point of view). I think that it would also be possible to use Unity engine for drawing, UI etc. stuff and make calculations by using own code.

[quote]As you said you can calculate either 8 floats per cycle or 4 doubles. Changing everything to double will [I]half[/I] the speed of floating point calculation.[/quote]

This is true only in very special conditions, which are rare in games (and almost everywhere). Simultaneous calculation demands that data is 8 dimensional vectors and n x 8 matrices. Typically there is 4 dimensional vectors and 4 x 4 matrices in physical simulations, 3D models etc. I guess that KSP does not use 8-vectors at all. If data must be rearranged for calculations it takes an advantage. As far as I know single 32 bit floating point operations are not faster than 64 bit operations (in modern CPUs).

[quote]The only reason why software slowly changes from 32 bit integers to 64 bit integers in the last decade is because there's a need for more addressable memory.[/QUOTE]

I did not talk about integers but floating point numbers. First popular arithmetic processor with 64 bit (actually 80 bit) floating point registers and arithmetic was Intel's 8087 from year 1980. Huge tables may be better to store in float format, but calculations should be made with greater accuracy and results can be stored as floats, if memory saving is necessary and there is not need for accuracy.

[Mischief]

I love KSP. However I just can't play it without 64bit support anymore. The mods I want to play are what still draws my interest but they can't all fit on 32bit.... so I'm locked out of my favorite game until 1.1 :(

Wants it. Wants it so bad.

[Hobbes Novakoff]

[quote name='parameciumkid']
- Unity 5 ships with a nice "Standard" shader that uses Physics-Based Rendering to appear nearly photorealistic. Parts and ships are unlikely to implement this off the bat, but background objects, buildings, or whatever might benefit. If nothing else, at least the primitives used in Whack-a-Kerbal will look better xD
[/QUOTE]

By the way, as of today's Devnotes, KSP will be using the Standard shader, at least for the parts.

[*Aqua*]

[quote name='Hannu']Under these conditions it is mistake to choose 32 bit physics engine in this game. It is also not good reason to keep an option to use GPU. Especially, because physics of KSP is very simple and it would not have been a huge task (compared to whole game) to program physics from scratch. Graphics, UI etc. is much more demanding (at least from my point of view). [/QUOTE]It doesn't matter that the calculations aren't that complex. Physics calculation is THE major resource hog in KSP. Everything else is pretty frugal compared to it. If it would be so easy to speed it up people would already have done it.

Graphics, etc. don't require much attention from the CPU. Rendering is handled by the GPU alone once everything (textures, meshes, shader programs) is copied into VRAM. Unity just sends camera and entity updates (position, rotation, animation) and the GPU takes over from there.

The option for GPU accelerated physics is actually a good one. GPUs are number crunshers, they are optimized for it and CPUs can't compare to that. (My graphics card can process 1,536 shaders programs in parallel, my CPU only 4.)
It's a sad thing that Nvidia locked AMD out of PhysX. If they didn't we might already have shader units optimized for physics calculations in every GPU.


[quote name='Hannu']Simultaneous calculation demands that data is 8 dimensional vectors and n x 8 matrices.[/QUOTE]I'm not sure where the 8 comes from.
The FPUs in my CPU can perform either 8x 32 bits, 4x 64 bits or 2x 128 bits floating point calculations in parallel in one cycle. That's a hardware limit. Clever code rearrangement won't change that. If you convert everything to doubles you half the ability to process stuff in parallel. The CPU will always try to process things in parallel to speed things up. Your idea limits that greatly. One double calculation might be as fast as a float calculation but the overall processing speed will go down.


[quote name='Hannu']I did not talk about integers but floating point numbers.[/QUOTE]I wanted to point at the fact that changes will only come if they are needed. Currently 64 bit floats in physic engines aren't really needed. There's KSP which might profit from it. There's Infinity Battlescape which I believe has a 64 bit physics engine. And those are all. Are there other games which make the development of a new physics engine reasonable? I mean is there a great enough demand that it'll be profitable?
The development of a new physics engine will take years and costs a lot of money (several millions).

[problemecium]

[quote name='Hobbes Novakoff']By the way, as of today's Devnotes, KSP will be using the Standard shader, at least for the parts.[/QUOTE]

W0000T! *cheers*

[spikeyhat09]

I hope it lifts the performance hit of the recent updates. In ye olde days I could build into the 800 part range before my fps went under 20, now if i go much past 200 the fps goes under 10

[Daid]

[quote name='TheTom']And again that ridiculous claim pops up. The biggest bottleneck in the game.... is not physics (as: physX) to start with. Ups. Here you logic goes. Despite claimed 17 years.
And this is btw. also extremely simple to paralellize into a number of threads. How? Paralellize: PhysX (body motion), Aerodynamics calculation, Resources (one thread per resource), Heat. Introduce SMALL delays - for example calculate aerodynamics on frame behind. Noone will see the difference, suddenly you can use a lot more threads in parallel. Heck, I would even say you do not need to handle most resources every frame, to start with.[/QUOTE]
Physics modify body positions and uses forces and weight. Aero uses positions and add forces. Resources modify weight (and, in case of engines, add forces). It's all connected, making it far from trivial to run thread-safe in parallel.

[QUOTE]Yes, the code in KSP is partially quite sub standard. Which puts it on par with a lot of cod I have seen. 2x-3x gains are not "exceedingly rare", I have seen quite a lot of them. A ton of code out there in companies is written quite badly thanks to "senior" developers with 5 years programming experience making design decisions.[/quote]2x-3x can be done, but usually means you changed architecture a bit, or added better algorithms.
My personal record is a 60x increase (average, best case 10000x), but that replaced everything (including the language the stuff was written in).

[TheTom]

[quote name='*Aqua*']It doesn't matter that the calculations aren't that complex. Physics calculation is THE major resource hog in KSP. Everything else is pretty frugal compared to it. If it would be so easy to speed it up people would already have done it.[/QUOTE]

That stupid statement is not more true if you repeat it 100 times. It is proven to be wrong. There are a lot of resource hogs. Even if you count the aerodynamics model into it (which can be replaced and is not part of the core physics loop) - it is not true.

Resource allocation (i.e. in game resources) and graphics are proven resource hogs.Resources in particular are REALLY bad, creating potentially hundreds of memory allocations PER FRAME which are not only totally not needed, but on top also result in a lot of garbage collection by an outdated and sub par .NET implementation (the mono version used in Unity is ancient).

Physics is not on the top of the list for anything but extremely small craft with very few resource consumers/producers (like a starter rocket: 1 engine, 1 tank, 1 controller). Once you hit larger elements the extremely inefficient code explodes.

Now, Aeorodynamics is a problem, but then - most of the problem is seriously implementation, as can be seen in FAR (which does the calculations a lot more realistic AND not less efficient).

So, stop spreading this lie. Physics can handle craft with 1000+ parts quite easily.

[Hannu]

[quote name='*Aqua*']It doesn't matter that the calculations aren't that complex. Physics calculation is THE major resource hog in KSP. Everything else is pretty frugal compared to it. If it would be so easy to speed it up people would already have done it.[/Quote]

I wrote about development time and costs. Physics in KSP is very simple to program and execute. If it would have programmed well, we could fly 10000 part ships and have much more accurate orbits and maneuvering, more sophisticated resource handling etc. Even I could make that kind of physics engine in the same time as KSP has been developed. It is not so simple that everything easy will be done. It seems that there are no-one in KSP's dev team who have the knowledge in physical simulations. Certainly it is very difficult, if not impossible, task to do properly if programmers does not have knowhow and special interest to that topic. It is just one boring thing which must be done before interesting things. They have probably taken the most easy (and maybe cheap) engine without thinking limits.

[quote]The option for GPU accelerated physics is actually a good one. GPUs are number crunshers, they are optimized for it and CPUs can't compare to that. (My graphics card can process 1,536 shaders programs in parallel, my CPU only 4.)[/quote]

It is not so simple. Graphics rendering is very special task which can be parallelized very efficiently to huge number of cores. But physical simulation is generally not so easy to parallelize. Most applications do not benefit if there are more than 128 or 256 cores and they have typically hundreds of thousands of equations and millions of interactions between them. Small systems with few interacting parts, like KSP, is much more hard to parallelize and can never utilize hundreds of GPU cores. Most of professional simulations is done with CPUs.


[quote]I'm not sure where the 8 comes from.
The FPUs in my CPU can perform either 8x 32 bits, 4x 64 bits or 2x 128 bits floating point calculations in parallel in one cycle. That's a hardware limit. Clever code rearrangement won't change that. If you convert everything to doubles you half the ability to process stuff in parallel. The CPU will always try to process things in parallel to speed things up. Your idea limits that greatly. One double calculation might be as fast as a float calculation but the overall processing speed will go down.[/quote]

8 floats comes from 256 bit ymm registers. It is practical size in current processor technology but will be increased to 512 bits in near future.

CPU does not try anything by itself. Program developer must make the parallelization (or use compiler options, but they are not well suited for most physical simulations). It varies much how practical such parallelization is. If calculation needs results of previous states it is hard to parallelize. Mechanically interacting rigid bodies are hard problem to parallelize, even in professional simulations. KSP's systems are also so small, that overhead takes easily an advantage. It may not be bad idea to keep physics of single craft in single thread, but optimize it.

These instruction are intended for vector arithmetics. Especially products between matrices and vectors are very efficient to calculate. But vectors are 3 or 4 dimensional in 3D space. Both, physical quantities and graphical vertices. There are very limited use for 8 vectors. Parallelized vector extension instructions have also to be programmed by hand. At least Microsoft's Visual Studio can not use them automatically. I doubt that they are not used at all in KSP and would not be surprised if they were not used in Unity too.

[quote]Are there other games which make the development of a new physics engine reasonable? I mean is there a great enough demand that it'll be profitable?
The development of a new physics engine will take years and costs a lot of money (several millions).[/QUOTE]

If we talk about physics model of KSP, that would not cost millions. Maybe tens of thousands are better approximation. It would probably take couple of months from some physics student. If there had been some interested or educated individual in KSP's development team they would probably have done it.

I know that it is now economically impossible to fix it in KSP, but it is also interesting to discuss at general level. And maybe there will be KSP 2 or some reader decides to make a new game in spaceflight genre. I hope that they do not have to make same mistakes.

[Algiark]

Wow, what a thread this has become! It's a wonder anyone hasn't invoked Godwin's law and talked about how Nazis created the first physics simulation engine for their unfinished V3 rocket project :confused: