Will 32-bit be the death of KSP

[RW-1]

You sir. Are exactly what's wrong with a lot of software users.

I maintain a semi-popular application (about 80000 uses daily). And it's only 32bit for windows. And occasionally, a stupid user, who thinks they know everything, drops by and says "you should do 64bit!" or "you should do multithreaded!". Without having any clue what's really happening or what the real limits are.

64bit isn't a magical solution for all problems. Never is, never will be. The only thing it really adds is some more virtual memory space. Which allows you to map more memory, IF it's available (and there are tons of systems with no more then 4GB of memory)

Have to agree here. I play stock, no mods, and it runs fine on my machine, maybe one crash in a month...

32 bit is not the death of anything: there are too many applications out there that run 32, a majority in fact, and they will continue to do so, and be supported by processor architecture; backwards compatibility.

[Tweety]

32 Bit is certainly not the death, or going to be, of KSP. I have played both versions modded and unmodded. Now all I'm interested in is 32 Bit unmodded, just 'cause. I CAN install linux if I really wanna, I just don't see a major NEED for it. I have a beast of a PC that I still haven't unlocked the potential of yet, and I still feel like 32 Bit is plenty enough for me right now.

Tweety

[Madrias]

I run lots of mods. I also would rather play in 32 bit and have to remove mods and change mods instead of having the completely unstable mess that was experimental 64 bit.

The 'death of KSP' will be a while down the road, or it will die with KSP 1.0. Which it will be, we won't know until it happens, but it won't be because of a lack of 64 bit.

[magnemoe]

Have to agree here. I play stock, no mods, and it runs fine on my machine, maybe one crash in a month...

32 bit is not the death of anything: there are too many applications out there that run 32, a majority in fact, and they will continue to do so, and be supported by processor architecture; backwards compatibility.

32 bit backward comparability will not go away but not sure if you will get windows 10 in 32 bit version.

Lots of memory hungry programs don't work well as 32 bits or rather they limit the scope of your projects. Done 3d rendering who has demanded more than 16 GB.

For KSP lots of the problem is inefficient use of memory however even if it worked better many players would get problems.

[Snarfster]

I think it's doubtful KSP will die due to the 32 bit windows thing, with texture compression you can install quite a few mods before you run out of memory.

Running 64bit Linux myself. The fact that the Linux client happens to be 64 bit is a nice bonus but it wouldn't be a deal breaker if it was 32 bit. It is nice though not to have to pay too much attention to what I choose to use, mod-wise.

Edited February 19, 2015 by Snarfster
Error in Brain-Keyboard interface

[montyben101]

It definitely wont be the death of KSP but it is very limiting

[Kar]

Every computer is different.

Today is more easier to have a game running with so many different hardware, there are more compatibility that was, let's say in the 90's.

KSP running 100% stock is stable, at least for me. I played for hours the stock game 32bit and 64 bit with no crashes and runs pretty well. While many people have problems with game (I also have, I explain in a while) 2 things must be considered: 1- The type of hardware and OS (Win, Mac, linux) 2- Mods.

Mods at this moment on KSP is the sure way to kill the game. Also, I think it is bad thing from Unity to have to load every single thing into the memory. Sure we do not want loading screens when transfer to another planet, but there must be a better way to load everything the game needs in a particular situation of what the player is doing.

While many games still uses 32bit access, the engine of those games are better developed to use the video card. KSP is too much CPU intensive, at least for me that I have a "old" AMD Dual core. But hey, I can play amazing graphical games pretty well and I do not even have a powerful video card (HD7770).

Unity, probably is aware of this, so I hope in the future we see the engine take advantage of 64 bit for memory allocation and a better use of Video cards technology and VRAM of that same video cards.

Textures, graphics, and stuff like that should not be processed by the CPU like it is today in the case of KSP. If I alt-tab KSP, I can hardly do anything else because the CPU is around 90% of usage, while in other games with great graphics I do the same thing and I can watch youtube videos and so on.

Even if Unity gets out of beta this year (probably will) I doubt that Squad will jump ahead right away. Changing to a new engine can cause all sort of problems and create new bugs. This is probably something Squad must do when the new engine is free of bugs and stable. Maybe is because of that, the 64bit KSP have not see any development.

I say, give it some time, I bet that by the end of this year everyone of us will be amazed with KSP.

[Coam]

I'm not really concerned for 64bit in itself, but I'd like to see the game better optimised (if realistically possible) than it is at the present, since that would increase performance even for those using 32bit machines or machines with less than 4GB of RAM, and doesn't rely as much on Unity being improved.

[sarbian]

Also, I think it is bad thing from Unity to have to load every single thing into the memory.

This is not a Unity problem. KSP loads every part texture, not Unity. If the dev want to do a load on demand system for most of the ressource they can.

[juanml82]

The problem isn't 32 bits per se but the lack of optimization

[Flef]

This is not a Unity problem. KSP loads every part texture, not Unity. If the dev want to do a load on demand system for most of the ressource they can.

indeed

line to type:

Resources.UnloadUnusedAsset

Well..ok it needs a bit more refinement. but the idea lies around that line.

Generally the first thing to do is to track the memory usage and then to define the priorities in terms of reducing the memory usage.

And do not be harsh against Squad. KSP stock is not really using a lot of memory compared to what it shows ingame.

Edited February 19, 2015 by Flef

[Renegrade]

To some degree. The biggest thing is it limits available address space.

That's actually the only thing 64-bit addresses. Generally speaking, CPUs have been working with 64-bit datapaths since the original Pentium (that's why it required dual 32-bit memory modules in mid and high end boards), way back in.. uh.. 1995? The larger register set might have meant something when more than five people worked in assembly, but these days, your typical compiler is heavily optimized for a small number of registers (and still way too stupid to use a large batch effectively). That and the floating point path has been completely 64-bit since that same era.

Any performance gains from 64-bit are usually wiped out by the increased cache miss frequency that the fatter data requires (64-bit architecture requires 8-byte pointers and often results in your default 'int'-type number being 8 bytes too, vs 4/4 for a classic 32-bit environment).

This indicates to me that it's either a Windows problem or a Unity problem (or both).

As much as I like to rag on Windows' million-and-one faults, this one squarely rests with Unity.

Even if stock KSP starts well under the process limit (which, btw, is rather lower on Mac Unity, even though OSX has a 4GB not ~3.5GB limit), there's enough new allocation and leaks that stock players do get out-of-memory crashes even now with disturbing (though by no means very high) frequency. I shudder to think what all the new parts and UI and structures etc. in 1.0 will do.

Yep, a stock game can definitely leak enough memory to crash. Takes a loooong time though - but not as long as it took in previous versions. Not a good trend.

Actually, how are we leaking memory anyhow? I've seen in the logs that this C# nuttery is garbage collected (/golfclap), so.... who's not releasing references? And to what? :/

64bit isn't a magical solution for all problems. Never is, never will be. The only thing it really adds is some more virtual memory space. Which allows you to map more memory, IF it's available (and there are tons of systems with no more then 4GB of memory)

Yeah, there's a disturbing number of 64-bit machines with tiny memory pools. I always roll 32-bit if the memory count is less than 8G - 64-bit datatypes will just bloat out the limited pool faster on a 4G machine (plus I do a lot of non-Windows work, where PAE is actually useful). Yet I see a lot of Windows 64-bit machines with 4 gigs in stores, or on people's desks.

I was shopping for a new dedicated host recently, and I noticed that they were offering me only 64-bit OSes on a 1-gig box at this one place. NEXT!

Textures, graphics, and stuff like that should not be processed by the CPU like it is today in the case of KSP. If I alt-tab KSP, I can hardly do anything else because the CPU is around 90% of usage, while in other games with great graphics I do the same thing and I can watch youtube videos and so on.

Multithreading will help you there - your CPU will be at 100% and you won't be able to do anything at all then. Oh wait that's the opposite of helping.

Note that a lot of games pause when they're alt-tabbed - that can make a huge difference. Also KSP will always be CPU heavy no matter what - most games only have extremely basic physics that operate for a short time only (the collision cost of resting masses on a surface are much, much, much lower than when they're in flight. You can see this in the Unity 5 performance tests. KSP physics are basically constantly in flight unless you're on rails..that's why the orbit parameters seem to 'wiggle')

This is not a Unity problem. KSP loads every part texture, not Unity. If the dev want to do a load on demand system for most of the ressource they can.

Actually, I was playing KSP earlier, and I noticed that the planetary surfaces seem to load in - is that bit not dynamic? And also any part-based dynamic system can run into the cliff of "that 900-part-space-station-which-has-literally-every-KSP-part-in-it" - except launch clamps that is - and then what? There's no dynamic solution to THAT problem.

While it's unlikely that a station will have every part in the game, if you look at some of the monstrosities in the "what I did in KSP today" thread, you'll see some that come close (especially once a spaceplane docks). And won't those guys be pleased when they install a tiny mod and suddenly the game can't load their masterpiece at all, yet it can load everything else.

The problem isn't 32 bits per se but the lack of optimization

Given that -force-opengl requires like half the memory of DX9 mode - something fishy is going on here. (I'd be the first one to stomp on DirectX for massive suckage, but that strains even MY believability)

[Red Iron Crown]

Actually, I was playing KSP earlier, and I noticed that the planetary surfaces seem to load in - is that bit not dynamic?

What you are seeing is the rendering engine switching from one set of texture detail level to another, all the textures are already in memory.

[RAINCRAFTER]

I have a Mac that I play on.

I like to play on a 0.25 modded install with B9, MJ, Novapunch, KW and more.

It doesn't usually crash. 'Nuff said.

[John FX]

There have been quite a few games brought out that have a 32 bit limit. Some of those had a wide expanse of features , graphics and so on. Simply using 32 bit is not a reason for KSP to die.

Saying that though, there have been some very poor programming decisions in constructing KSP but that is to be expected of a company making their first game.

If the textures and other elements were loaded on demand this would mean a lot of people are not banging up against the memory limit, which seems to be the root of this thread.

I`m sure there are other areas that could also see similar benefits if revisited. Putting textures straight onto the video card would be a good thing.

With hope, unity 5 will allow more elegant solutions to existing problems

[cantab]

Even if stock KSP starts well under the process limit (which, btw, is rather lower on Mac Unity, even though OSX has a 4GB not ~3.5GB limit), there's enough new allocation and leaks that stock players do get out-of-memory crashes even now with disturbing (though by no means very high) frequency. I shudder to think what all the new parts and UI and structures etc. in 1.0 will do.

The thing is that the proper solution here is to fix the memory leaks. Releasing an otherwise stable 64-bit version without fixing those leaks is just kicking the problem into the long grass.

The leak seems to have only arisen in earnest in 0.90

As far as if and when the 4 GB limit starts to cause an issue for the stock game, I'd rather have fewer quality assets than loads of degraded ones.

As far as mods go, only a certain subset of them significantly increase RAM usage. *cough* RSS *cough* . Mods like KER, Alarm Clock, even FAR and DRE have a trivial effect. Worst case scenario, RAM-hungry mods needs to either be like Ven's Stock Revamp replacing existing parts instead of adding new ones or they need to automatically including ATM-like functionality.

Regarding a load-on-demand approach, this was discussed in a previous thread. Someone (NathanKell?) suggested that the game could monitor RAM usage and automatically fall back to lower-resolution textures if you do something like build a ship with every part.

But then all this is somewhat academic to me. I've been a Linux user for a decade, so neither the 4 GB address space limit nor it seems the memory leaks affect me. (On the other hand I do have to make do with only 4 GB of physical RAM). Now if Squad for some reason cancelled the Linux version, that would be the death of KSP for me.

[sal_vager]

About leaks, It'd depend on where those leaks are...

If they are in the Squad code on 32bit they can be found and fixed, but it's important to note that memory can be allocated for lots of reasons, as long as it is deallocated then it's not a leak, but allocated memory that has had its pointers removed will sit unusable until the program is ended.

An example of this is your browser tabs, the memory allocated to a tab is deallocated after the tab is closed.

If functions in the engine are allocating memory and not deallocating it there's not a lot Squad can do except report the leak to Unity, this is true of all other developers using Unity, though it is sometimes possible to fix this in a hacky way the Unity license doesn't permit it.

That's just 32bit, 64bit is much harder.

The Squad code is written for 32bit addresses because the Unity editor is 32bit, thankfully x64 hardware and operating systems are 32bit backwards compatible, but there can be unintended effects when compiling the same code on 64bit.

Memory addresses are larger, so code that expects an integer to be 2 bytes (16 bits) now has to work with 4 byte integers, this can become a problem if you're doing bitwise operations for speed for example.

You can code to avoid depending on an integer being 2 bytes long, and the compiler will warn you of problems with your own code most of the time, but what do you do if you are calling engine functions that depend on it?

If you're lucky, you end up watching your compiled binary crash spectacularly, throwing an error code, you code around the issue and go to the Unity bug tracker with a shiny new bug.

If you're unlucky, there's no crash, there's no errors or warnings, nothing looks wrong in the code but your scene displays inside out, or your memory use is crazy, or your buildings start fully upgraded in career.

But the only way to find out why is to access code you didn't write and can't debug.

Edited February 19, 2015 by sal_vager

[Renegrade]

What you are seeing is the rendering engine switching from one set of texture detail level to another, all the textures are already in memory.

Are you sure? It's awfully laggy when it does that. Not quite GTA IV console level of laggy, but still.. Anyhow, planetary surfaces would be a prime target for dynamic loading. Even having two bodies close together (in high-res texture range) is a massive mod-only edge case, and even then, the likelyhood of there being more than 3-4 bodies that close is extremely low, and could probably be written off as simply 'stupid and abusive'.

Another target (also having to do with planets) would be KSC of course. You can't have two levels of the same building coexisting at the same time, and they don't switch too frequently..

The leak seems to have only arisen in earnest in 0.90

Agreed, it's much worse now than it was before. I didn't play 0.25 much, but 0.24 certainly had a lot more wiggle room in terms of run time vs. creeping memory.

But then all this is somewhat academic to me. I've been a Linux user for a decade, so neither the 4 GB address space limit nor it seems the memory leaks affect me. (On the other hand I do have to make do with only 4 GB of physical RAM). Now if Squad for some reason cancelled the Linux version, that would be the death of KSP for me.

Damn, even my Linux fileserver has 12GiB of ram. The backup one has 8GiB. My phone has 1G..ish! (oh wait, that's less...) Quit your upgrade slackin'!

(seriously though, if the extra RAM goes unused by applications, it will still become disk cache, reducing wear on mechanical and flash-based disks tremendously and boosting performance)

If they are in the Squad code on 32bit they can be found and fixed, but it's important to note that memory can be allocated for lots of reasons, as long as it is deallocated then it's not a leak, but allocated memory that has had its pointers removed will sit unusable until the program is ended.

Super spazzy modern garbage-languages *COUGH* Oh I meant garbage-collected languages weren't supposed to have memory fragmentation issues~

Memory addresses are larger, so code that expects an integer to be 2 bytes (16 bits) now has to work with 4 byte integers, this can become a problem if you're doing bitwise operations for speed for example.

4 bytes (32-bits) to 8 bytes (64-bits) these days. You still in the process of upgrading from DOS?

[cantab]

Damn, even my Linux fileserver has 12GiB of ram. The backup one has 8GiB. My phone has 1G..ish! (oh wait, that's less...) Quit your upgrade slackin'!

Motherboard limited, unfortunately - two slots for DDR2, so the practical maximum is 4 GB; 4 GB DDR2 sticks exist but are extortionately priced. I'm waiting for Skylake and DDR4 for my next build to avoid getting in the same situation again. /offtopic

[Jouni]

The larger register set might have meant something when more than five people worked in assembly, but these days, your typical compiler is heavily optimized for a small number of registers (and still way too stupid to use a large batch effectively).

Most compilers are quite good at optimizing the code for a specific architecture, if you just tell them to do it. It's just rarely done in software you don't compile yourself. A program that's been optimized for one CPU could be slower on another kind of CPU than without the optimizations, or it might not even run at all. That's why most software is built for a generic x64 architecture.

Any performance gains from 64-bit are usually wiped out by the increased cache miss frequency that the fatter data requires (64-bit architecture requires 8-byte pointers and often results in your default 'int'-type number being 8 bytes too, vs 4/4 for a classic 32-bit environment).

The bigger pointers aren't such a big deal in performance-critical code. If you're working with a nontrivial amount of data, the reasonable assumption is that if you follow a pointer, you get a cache miss. Hence optimized code tends to avoid pointer-based structures.

Even if you build 64-bit code, the default integer types are still 32-bit on most compilers. That's kind of silly, because 32-bit integers are too small for most purposes these days. They should never be used, unless you're certain that their size isn't going to be a problem. (And even then, your assumptions are often going to be wrong.)

[pincushionman]

People gotta get off the 64-bits = better kick, and I say that as someone who was previously on it pretty heavily. Let's look at a few popular software packages that aren't [usually] distributed in 64-bit form on Windows:

Mozilla Firefox and Thunderbird. it's web browsing and e-mail, man. Done to reduce the effort of supporting two releases. Only a real issue if you want to avoid having separate versions of key third-party add-ons (i.e. Flash and Java)

OpenOffice/LibreOffice. Office productivity software gains very little from 64-bit architecture. If you're pushing the limit on memory use, your documents are already too large or you're using the wrong kind of software. The exception might be databases, but again you're better off with a software optimized for large databases anyway.

Internet Explorer. this may be different now, but 64-bit Windows 7 shipped with both versions of this, and you have to jump through hoops to use the 64-bit version. This is mainly because third-party tools need to be compiled for each version, and it's easier just to release and support one. Plus, as noted above, 32-bit is just plain good enough.

Microsoft Office. Anyone starting to see a trend here? At my company we do a lot of engineering analysis using Excel VBA macros and UDF's (frankly, beyond what Excel is intended to do), and I'm pretty sure I'm the only one who even knows it's still running in 32-bit. I've forced Excel into a state where it crashed due to 32-bit memory issues, but that's becsuse it was a corner case and I was literally trying to accomplish just that. Otherwise, above observations about IE and OpenOffice apply here too. Buisness users simply do not require the few advantages offered by 64-bit builds. Engineering users (whose performance requirements are more in-line with what we might need out of KSP) might, but as I've noted, thst isn't necessarily a yes.

What we should take from this is: if the major players - including the publishers of the very 64-bit OS we're concerned about here - feel that 64-bit is not by itself an advantage, then it isn't.

KSP's problem is poor memory management, and 64-bit does not fix that, it inly makes it less apparent.

Edited February 19, 2015 by pincushionman

[radonek]

You sir. Are exactly what's wrong with a lot of software users.

I maintain a semi-popular application (about 80000 uses daily). And it's only 32bit for windows. And occasionally, a stupid user, who thinks they know everything, drops by and says "you should do 64bit!" or "you should do multithreaded!". Without having any clue what's really happening or what the real limits are.

64bit isn't a magical solution for all problems. Never is, never will be. The only thing it really adds is some more virtual memory space. Which allows you to map more memory, IF it's available (and there are tons of systems with no more then 4GB of memory)

And you, sir, are prime example of why 64bit windows are slow moving form "major pain in the ass" to "slight nuissance", never mind being actually useful. Even if your app has zero advantage in running 64bit (and actually slight penalty that comes with it), your users will have significant advantage of running native. Don't you find it strange that linux port of Unity, while getting much less attention then windows one, is just fine? Is linux Unity somehow magic? Let's see… On my linux box, 100% of installed packages is 64bit. And all of them work just fine. On win7 box, about half of system is 32bit, and anything 64bit exhibits all colours of trouble (still great compared to 64bit XP though). Doesn't look to me like it's just "some more virtual memory space". 32bit emulation need some complicated and error prone machinery, and geting rid of it is advatage for your users even if app itself does not change one bit.

[Rokmonkey]

I think I've missed something, but isn't the argument, "I run Linux" kind of moot? If they don't release 64-bit versions for 1.0 won't that also affect Linux users or does that work differently on Linux?

[cantab]

The problems are solely with the Windows 64-bit build. On Linux the 32-bit and 64-bit versions of KSP have both been perfectly stable for several releases now. Meanwhile on OSX the only build is a 32-bit one. The differences are down less to the actual operating systems and more to Unity's varying quality on the different operating systems.

[ratchet freak]

I think I've missed something, but isn't the argument, "I run Linux" kind of moot? If they don't release 64-bit versions for 1.0 won't that also affect Linux users or does that work differently on Linux?

linux is an entirely different build of unity that isn't unstable in 64bit

probably because mono isn't supported for win64