A 64-bit KSP might be closer than we think(or at least Squad is working on it)

[godefroi]

And it's Microsoft who, in their official training materials, have misrepresented the 4GB memory limit for 32-bit OSes as something inherent in the hardware. I know better, others not familiar with *ix might not.

But that's a bit off-topic.

Off-topic, yes, but telling. Even the "experts" get it wrong.

[Red Iron Crown]

It doesn't help. It's simply a note that people who say "you can't use more than 4GB of memory in a 32-bit process" are wrong, and you need to realize that not only do they not know what they're talking about, they don't even understand the problem.

The distinction between "you can't use more than 4GB of memory in a 32-bit process" and "you can't practically use more than 4GB of memory in a 32-bit process" is largely a pedantic one. People understand the problem, they're running out of memory when running modded KSP (accurate) and switching to a 64-bit process would help with that (accurate).

[radonek]

It doesn't help. It's simply a note that people who say "you can't use more than 4GB of memory in a 32-bit process" are wrong, and you need to realize that not only do they not know what they're talking about, they don't even understand the problem.

I looked up that syscall at MSDN ( http://msdn.microsoft.com/en-us/library/windows/desktop/aa366537.aspx ) and it seems to me to be just variation on posixish mmap(). You get swap-backed file handle and access it via ordinary file IO calls. You cant pass that memory to syscall, you cant allocate from it in library, you cant pass it to GPU as texture buffer. In short, you can't do anything except boasting you somehow "allocated" >4G of memory. Unless you reimplement most of core libraries in a very inefficient way, that is.

Thus, "you can't use more than 4GB of memory in a 32-bit process" still holds, for any usefull values of "use".

BTW you can do the same on *nix, and on linux you can do even better using hugetlbfs, but for exactly same reasons it is only used for very special workloads (mostly big databases).

We're just a bunch of armchair coders "fixing" all of Squad's problems from the back seat (how's that for a mixed metaphor).

True enough…

[godefroi]

I looked up that syscall at MSDN ( http://msdn.microsoft.com/en-us/library/windows/desktop/aa366537.aspx ) and it seems to me to be just variation on posixish mmap(). You get swap-backed file handle and access it via ordinary file IO calls. You cant pass that memory to syscall, you cant allocate from it in library, you cant pass it to GPU as texture buffer. In short, you can't do anything except boasting you somehow "allocated" >4G of memory. Unless you reimplement most of core libraries in a very inefficient way, that is.

Well, if you don't like CreateFileMapping(), there's always AWE, then. VirtualAllocEx() will allocate you more than 4GB, I believe? You just won't be able to map it all into your address space at once...

Also, if I read the table correctly, if you're running a 32-bit OS, KSP gets 2GB of address space (3GB if you're using 4GT), and if you're running a 64-bit OS, KSP gets 4GB of address space. This is because KSP.EXE has the IMAGE_FILE_LARGE_ADDRESS_AWARE flag set.

[6.forty]

Why try to work around the 32bit address space when you could just fix the code that already exists? Most of the issues arise from assumptions on data type sizes and careless pointer and unsigned value use. It doesn't help that those things aren't entirely consistent between Windows and other OS's.

[Athlonic]

Just tell me KSP will switch to Unity 5

**drool.jpg**

[radonek]

Well, if you don't like CreateFileMapping(), there's always AWE, then. VirtualAllocEx() will allocate you more than 4GB, I believe? You just won't be able to map it all into your address space at once...

Same thing. You have memory which you can't use without going through some hops and can't pass along to anything else. MSDN says, among other limitations: "AWE address ranges cannot be used to buffer data for graphics or video calls." What use can game engine make of it?

If you need to squeeze some big database tablespace into memory, you can live with that, databases tend to handle their memory themselves anyway.

Otherwise, it seems somewhat less clunky API then using memory mapping, but it says you need to lock those pages into physmem, since its not backed by pagefile. This means running under escalated privileges, which is showstopper in my book.

Nothing of this is relevant to KSP anyway – even if that memory could actually be usefull, you cant really go to Unity developers asking them to implement more difficult and less usefull then plain amd64 arch support.

[LadyAthena]

Now that Unity is Unity 5 with 64 Bit support, there is no way KSP isn't going 64 bit for windows soon.

[Motokid600]

Just tell me KSP will switch to Unity 5

**drool.jpg**

Now THAT is interesting. KSP's always been kept up to date with Unity, no? so id imagine this would be no different. And just to clarify this version of Unity DOES have a functioning 64bit client for Windows?

Edit: I saw three very awesome things in that video.

64-Bit Editor support ( whats that mean for the cause exactly? )

Multi-Thread support

HDR.

Ksp with those three things = ... words cant describe.

Edited March 19, 2014 by Motokid600

[_Aramchek_]

Now THAT is interesting. KSP's always been kept up to date with Unity, no? so id imagine this would be no different. And just to clarify this version of Unity DOES have a functioning 64bit client for Windows?

Edit: I saw three very awesome things in that video.

64-Bit Editor support ( whats that mean for the cause exactly? )

Multi-Thread support

HDR.

Ksp with those three things = ... words cant describe.

Add "PhysX3 upgrade" to that list too.

[IrRedemption]

Well from what i read this is not going to multithread its gonna allow PHYSx to render the processes to the gpu but only to nivida gpus.

[Red Iron Crown]

Well from what i read this is not going to multithread its gonna allow PHYSx to render the processes to the gpu but only to nivida gpus.

By the very nature of GPUs this means that the physics has to be multithreaded. GPUs are large arrays of relatively simple processors, if using them improves performance the workload must be multithreaded.

[MalfunctionM1Ke]

Now that Unity is Unity 5 with 64 Bit support, there is no way KSP isn't going 64 bit for windows soon.

I think Squad confirmed that they are experimenting with a 64-Bit Version but it was too buggy on Windows.

But they wont confirm or deny that said Version will be on the Table until they are sure that they get it working.

[Umlüx]

i'd kill for unity5 x64 to be in KSP 0.25

[LadyAthena]

i'd kill for unity5 x64 to be in KSP 0.25

So would I

[softweir]

A switch to Unity 5 may take a while. To start with, there is no release date for Unity 5, so it could be months, maybe even more than a year away. Secondly, major new versions of game engines often have changes that break old code and it can take time to rewrite the code to work with the new engine.

tl/dr: Don't hold your breath!

[lammatt]

i want 0.24 more

[Red Iron Crown]

A switch to Unity 5 may take a while. To start with, there is no release date for Unity 5, so it could be months, maybe even more than a year away. Secondly, major new versions of game engines often have changes that break old code and it can take time to rewrite the code to work with the new engine.

Depressingly accurate.

[NoMrBond]

Unity 4 had 64 bit support too, except on Windows/MacOS the executables were all but unusable.

At the moment it sounds promising, but I won't get excited until C7 mentions it in his devWeekly byline after Unity-5 is actually available a couple of months from now.

Fingers crossed the migration is both painless and viable.

[Umlüx]

i am very optimistic that a unity5 switch will come in the near future. KSP could profit sooo much from that (if all of this is really true.. stable x64, multithreaded job scheduler also working for physics)

but then again.. 'near future' is an elastic term.. i'd be happy to see it happen in 2014.

[KerbMav]

So would it be reasonably easy and change things for the better to boot Linux from USB-drive simply to play KSP, are there more advantages than 4GB+ RAM usage?

[Seret]

So would it be reasonably easy and change things for the better to boot Linux from USB-drive simply to play KSP, are there more advantages than 4GB+ RAM usage?

Booting from a USB won't generally allow you to install the proprietary video card drivers. If you've got a system that can handle KSP graphics without them then you could do it that way I suppose. It'd be a lot better to just set up a dual boot though. It's not like Linux will eat a big chunk of your hard drive. 20GB would be plenty if all you're doing is KSP.

[KerbMav]

Booting from a USB won't generally allow you to install the proprietary video card drivers. If you've got a system that can handle KSP graphics without them then you could do it that way I suppose. It'd be a lot better to just set up a dual boot though. It's not like Linux will eat a big chunk of your hard drive. 20GB would be plenty if all you're doing is KSP.

As XP is going offline soon I switched to Linux on my ASUS eeePC I only use for surfing and videos while travelling. A friend who helped me set it up mentioned incompatibilities in the file systems of Win and Linux, warning me to write to the still windows formatted drive carrying unwatched stuff I did not want to copy over again. What could he have been talking about? (We were in a hurry at the end and I didnt get to ask him.)

[cantab]

It used to be that Linux didn't support NTFS, used by current Windows versions, well. Nowadays it does.

[Seret]

A friend who helped me set it up mentioned incompatibilities in the file systems of Win and Linux, warning me to write to the still windows formatted drive carrying unwatched stuff I did not want to copy over again. What could he have been talking about?

Linux can read and write to a Windows NTFS filesystem, but Windows can't even recognise Linux filesystems (usually EXT4 these days). If you've set up a dual-boot you'll be able to copy anything still on your Windows partition over to your Linux one (but not vice versa).

There is a potential situation you can get with NTFS drives where if you don't shut down properly you won't be able to access the drive again until it's been checked for errors. Windows would do that at boot time. It's possible to do in Linux, but isn't a point-and-click job. For this reason you should probably move all your data you want access to over onto the Linux partitions instead of leaving it on the NTFS partition.