Will 64 bit allow for larger, higher part count ships?

[Eric S]

Like, you have to really redesign how things access your game files to allow multi-threading at a good level.

According to the Unity 5 page that talks about the improved physics performance:

Thus, Unity 5.0 physics is not 100% compatible with Unity 4.x. Be prepared to retune your old projects and rewrite some of your physics code when migrating from previous Unity releases.

I don't know how much rewriting will be necessary, but I don't think it'll involve changing too much other than the physics itself. Now, if you wanted to make all of KSP thread-safe, that could cause potential for needed changes all over the place, but the return on investment for that would be far less than it would for being able to split physics calculations between CPU cores.

[magnemoe]

64 bit will not increase the speed if you have a large ship, that is physic/ cpu limited.

It will allow more large missions and more mods, so it will not make your 500 part ship handle better but it would let you have 40 of them.

[stupid_chris]

It really should have little to no effect. 64bit simply chamges the available memory, aka modders and mod users will be the one benefitting this.

To improve part count lag, you're going to want something to free up the processor a little, something like Unity fixing it's threadsafe issues.

[p331083]

Why do people keep bringing this topic up?

64 Bit deals 99.9% with the 3gb memory limit. All its really going to do is allow you to run all the mods you want, which is badly needed considering the amount of quality mods out there.

[NecroBones]

And multi-threading isn't really like flipping a switch, from what I understand.

Like, you have to really redesign how things access your game files to allow multi-threading at a good level.

Yes, this is true. Unlike changing from 32 to 64 bits, which can often entail tweaking a variety of things in your code and recompiling, adding multi-threaded support to something that wasn't written that way originally is an entirely different animal.

I'll give an analogy. Let's say you're taking a math class, and the teacher gives you a complex problem to solve. If you solve it from beginning to end by yourself, you've executed the equivalent of a single-threaded process.

Now let's say you want to solve that problem via committee, and break the problem down into individual parts, and give a different piece to each person. Someone still has to wait on each person's results, and coordinate them, and assemble them, and potentially hand out additional pieces based on those results. This is more like how a multi-threaded process functions.

Some problems lend themselves well to multithreading more than others. For instance, if you have lots of individual math problems to solve that have nothing to do with each other, then it's very easy. If they all rely on each other's results, then they need to coordinate and communicate, and some will take longer than others, and you may not know in advance which ones will finish first. It can become a bit of a juggling act, when programming it.

Edited July 13, 2014 by NecroBones

[Whackjob]

It really should have little to no effect. 64bit simply chamges the available memory, aka modders and mod users will be the one benefitting this.

To improve part count lag, you're going to want something to free up the processor a little, something like Unity fixing it's threadsafe issues.

If they'd fix things so I could finally break the 10k part barrier, I would be happy.

[Kerano]

If they'd fix things so I could finally break the 10k part barrier, I would be happy.

What's your record number of parts in a ship so far, incidentally?

Looking forward to trying out the 64 bit version and seeing how it compares on my computer.

[LethalDose]

So what do you think? at the moment my ISS is getting larger and will keep growing for a while, the lag is getting much worse im just hoping 64 bit will make it better

So back to the OP: No, the community expects that 64-bit will do very little, if anything, to fix your lag due to high part counts.

Many community members seem to think that the new 64-bit version is some panacea for the game. But based on comments from code-savvy individuals on the forums, most players will probably barely notice the difference between 32 & 64 bit versions after the game starts, except for having more mods.

I hope the mods lock further topics on this issue. The number of these we're seeing is getting to be silly and the only events that would actually going to settle the discussion are 0.24 getting released or the devs coming in and telling us one way or the other, and I think we know which one's most likely to happen first.

[magnemoe]

Yes, this is true. Unlike changing from 32 to 64 bits, which can often entail tweaking a variety of things in your code and recompiling, adding multi-threaded support to something that wasn't written that way originally is an entirely different animal.

I'll give an analogy. Let's say you're taking a math class, and the teacher gives you a complex problem to solve. If you solve it from beginning to end by yourself, you've executed the equivalent of a single-threaded process.

Now let's say you want to solve that problem via committee, and break the problem down into individual parts, and give a different piece to each person. Someone still has to wait on each person's results, and coordinate them, and assemble them, and potentially hand out additional pieces based on those results. This is more like how a multi-threaded process functions.

Some problems lend themselves well to multithreading more than others. For instance, if you have lots of individual math problems to solve that have nothing to do with each other, then it's very easy. If they all rely on each other's results, then they need to coordinate and communicate, and some will take longer than others, and you may not know in advance which ones will finish first. It can become a bit of a juggling act, when programming it.

However if KSP uses Unity build in functions for physic, its mostly to flip a switch. Yes it will cause new bugs, especial with physic based stuff.

just switching to unity 5 is likely to introduce lots of bugs.

[kmMango]

If they'd fix things so I could finally break the 10k part barrier, I would be happy.

I don't think that needs a fix. It's not a glitch. What you do pushes the game beyond all sane boundaries.

[MartGonzo]

I don't think that needs a fix. It's not a glitch. What you do pushes the game beyond all sane boundaries.

true, but I do think the game could be a lot more intelligent about how it calculates physics, there really should be some kind of part combining built in to reduce the physics calculations.

It really makes no sense to calculate physics separately for ever part.

Slightly off topic but I was wondering, does Unity 5 use the GPU for physics?

[MR4Y]

So back to the OP: No, the community expects that 64-bit will do very little, if anything, to fix your lag due to high part counts.

Many community members seem to think that the new 64-bit version is some panacea for the game. But based on comments from code-savvy individuals on the forums, most players will probably barely notice the difference between 32 & 64 bit versions after the game starts, except for having more mods.

I hope the mods lock further topics on this issue. The number of these we're seeing is getting to be silly and the only events that would actually going to settle the discussion are 0.24 getting released or the devs coming in and telling us one way or the other, and I think we know which one's most likely to happen first.

For some people, 64-bit instantly became world peace, the cure for AIDS and the solution for every game issue and bug.

[MR4Y]

true, but I do think the game could be a lot more intelligent about how it calculates physics, there really should be some kind of part combining built in to reduce the physics calculations.

It really makes no sense to calculate physics separately for ever part.

Slightly off topic but I was wondering, does Unity 5 use the GPU for physics?

Only if you have an nVidia GPU (PshyX), otherwise, t's CPU calculated. But KSP doesn't use PshyX. Even if you were to have KSP under Unity 5, all the physics would be calculated with the CPU.

[cpast]

Only if you have an nVidia GPU (PshyX), otherwise, t's CPU calculated. But KSP doesn't use PshyX. Even if you were to have KSP under Unity 5, all the physics would be calculated with the CPU.

I thought KSP uses Unity (and so PhysX) for part physics, only relying on its own code for orbital mechanics?

[MartGonzo]

Only if you have an nVidia GPU (PshyX), otherwise, t's CPU calculated. But KSP doesn't use PshyX. Even if you were to have KSP under Unity 5, all the physics would be calculated with the CPU.

Thanks very much MR4Y, sounds like it might be a possibility for when KSP moves over to unity 5.

That would be a great addition.

I really think they need to look at the way they handle the physics, at the moment space stations and bases are really feasible for anyone who doesn't have a monster rig.

[Linear]

Only if you have an nVidia GPU (PshyX), otherwise, t's CPU calculated. But KSP doesn't use PshyX. Even if you were to have KSP under Unity 5, all the physics would be calculated with the CPU.

Yes, KSP does use PhysX, perhaps you mean it doesn't use advanced physx.

[MR4Y]

Thanks very much MR4Y, sounds like it might be a possibility for when KSP moves over to unity 5.

That would be a great addition.

I really think they need to look at the way they handle the physics, at the moment space stations and bases are really feasible for anyone who doesn't have a monster rig.

I don't get what you said there. They shouldn't be feasible?