How much would 64-bit actually matter?

[lazarus1024]

There will be absolutely no noticeable difference for you (or most people, including me). Turning 64-bits will give more space for mods, that is it.

Likely an increase in performance.

AMD64 instructions have twice the execution registers that x86-32 does. This is where the tendancy for 64-bit programs to run around 10-15% faster comes in. This is ONLY true for "x86 compatible" type stuff though. RISC (ARM as one example) has vastly more execution registers already available and I don't know that there is a different between ARMv7/8 and ARMv9 64-BIT stuff in terms of execution registers (there might be, I just don't know).

So odds are, there would actually be a slight increase in performance depending on how stuff is excuted in the code and int vs float calcs. I'd say odds are good the way the physics calculations are performed and since they are performed within only one thread, that 64-bit would likely lead to a small but noticable gain in performance (again, in that 10-15% range).

[KerbMav]

If I am wrong in my next sentence, it is probably not worth to continue reading the rest of my post.

Windows can handle more RAM in total than it can make available to/can be used by a single 32bit program.

Squad loads every bit of data into RAM at startup to have it readily available when a vessel enters the 2,xkm physics range - but it still creates a short lag at times.

Now, I asked this in a different thread already, but did not get a clear answer to it:

What if KSP came with the option to load a second program creating a RAM-drive? Instead of loading everything into the RAM allocated to KSP directly, it would load only planets, KSC, the UI and program itself directly. The rest it would simply copy into the RAM-drive to load when needed, still faster then reading the harddrive.

Yes, no, maybe, I dont know?

[dellcom1800]

If I am wrong in my next sentence, it is probably not worth to continue reading the rest of my post.

Windows can handle more RAM in total than it can make available to/can be used by a single 32bit program.

Squad loads every bit of data into RAM at startup to have it readily available when a vessel enters the 2,xkm physics range - but it still creates a short lag at times.

Now, I asked this in a different thread already, but did not get a clear answer to it:

What if KSP came with the option to load a second program creating a RAM-drive? Instead of loading everything into the RAM allocated to KSP directly, it would load only planets, KSC, the UI and program itself directly. The rest it would simply copy into the RAM-drive to load when needed, still faster then reading the harddrive.

Yes, no, maybe, I dont know?

Hello,

That is a reasonable but it wouldn't do exactly what you think. So creating a ram drive allocates a block device that the OS can use (in linux/unix we call this ramfs or tmpfs), you load data in it the same you you do any other block device after it is mounted, however there is not file system as everything is stored in memory pages. For the program to access that information from a drive it would then have to be loaded from the drive into memory for the program which cannot be done with a simple memory map. This would be an inefficient way to store the game data.

You *could* create a ram drive for yourself and then move the whole KSP directory into it and execute it from there (assuming you have enough memory). If it uses relative path to store the saves and stuff like that it should also right too this ram drive.

But this would be very volatile and require constant backing up to a disk or batteries.

Do you use a SSD? because that pretty much exactly what they do to get their speed. FLASH is quite slow so they are packed with DRAM as cache which is why they appear to be so quick on IO.

[Xarian]

You people are way too narrowly focused on RAM.

Benefits for x64:

1 - More RAM usage (as stated before)

2 - Making optimal use of multiple cores

x64 would allow your system to run the physics thread across multiple cores instead of only one. Think for a second: timewarp during acceleration, huge part counts without slowdown, more accurate physics calculations, defeating the kraken for good.

[dellcom1800]

You people are way too narrowly focused on RAM.

Benefits for x64:

1 - More RAM usage (as stated before)

2 - Making optimal use of multiple cores

x64 would allow your system to run the physics thread across multiple cores instead of only one. Think for a second: timewarp during acceleration, huge part counts without slowdown, more accurate physics calculations, defeating the kraken for good.

64 bit optimized code doesn't have anything to do with utilizing multiple processors. Multi-threading already occurs on this game. Check your process manager if on windows or run # mpstat -P All 1 on Linux when running KSP. So it is already capable, now how optimized their code is to use that is another thing. But just making it 64 bit will not change that.

[jfx]

You people are way too narrowly focused on RAM.

2 - Making optimal use of multiple cores

x64 would allow your system to run the physics thread across multiple cores instead of only one. Think for a second: timewarp during acceleration, huge part counts without slowdown, more accurate physics calculations, defeating the kraken for good.

Go directly to jail; do not post again, do not collect $200.

(Utter nonsense).

[Mmmmyum]

Also changing physics engine's to one that uses the GPU would take the game away from quite a few laptop owners without KSP, such as myself; my i7 can handle the game pretty easily but methinks that my HD4000 won't

Edited November 7, 2013 by Mmmmyum

[Arsonik]

Also changing physics engine's to one that uses the GPU would take the game away from quite a few laptop owners without KSP, such as myself; my i7 can handle the game pretty easily but methinks that my HD4000 won't

I will be honest that I skipped to the last page and only read the OP and first few replies last night. But to address your point, as far as nVidia and PhysX are concerned anyways, you can dictate whether PhysX calculations are done on the CPU or GPU in the nVidia control panel. Since you have an AMD card I can't say for certain if that would work for you. But as I understand KSP/Unity is using PhysX for part of its Physics, and PhysX is not supported on AMD GPU's as far as I know. So no cause for concern for your laptop.

..... I'm probably wrong though.

[Wheffle]

Genuine 64bit apps on a 64bit CPU typically run ~10-15% faster than the same app compiled and run in 32bit mode.

"Accuracy" is unchanged.

This is correct. Apps compiled for 64 bit will run faster simply because of compiling querks. 32-bit compiled apps usually won't use the newer, faster features of new CPUs as they are worried about backwards compatibility with old 32-bit processors, where 64-bit compiled programs have no such inhibitions.

[boxman]

This matter has been bugging me for a good while now. When I run KSP, My computer's RAM usage only goes up by about a gigabyte and a half, far below the maximum amount allowed in the 32-bit game. If a 64-bit version of the game does appear (yes, I know there's a Linux one already), what would the difference be? Wouldn't the game still only use about 1.5 GB, since that's all it needs to run in the first place?

It will make a difference if you have alot of mods installed. That will make it lag less when you run low on memory and will stop it from crashing constantly.

If you run vanilla on the other hand there wont be much of a difference. It wont affect the lag caused by lack of processing power with larger ships for example.

[Demon_82]

I will be honest that I skipped to the last page and only read the OP and first few replies last night. But to address your point, as far as nVidia and PhysX are concerned anyways, you can dictate whether PhysX calculations are done on the CPU or GPU in the nVidia control panel. Since you have an AMD card I can't say for certain if that would work for you. But as I understand KSP/Unity is using PhysX for part of its Physics, and PhysX is not supported on AMD GPU's as far as I know. So no cause for concern for your laptop.

..... I'm probably wrong though.

PhysX works by default using CPU on PCs that don't have an nVidia GPU, and it gives you the option to choose between CPU and GPU in PCs with an nVidia GPU, using the GPU by default on that PCs. Many games use it and AMD/ATI owners can still play them with great performance. Intel GPUs usually are the weakest of the pack in any comparison, but they as the AMD/ATI cards, won't have to do PhysX, it will be their CPU tasked with it. So it won't take if away from anyone, it just could improve, or not, for about one third or one half of the PCs out there.

[numerobis]

Unity PhysX is single-threaded on the CPU. Squad could, at some fairly significant development effort and likely breaking certain mods, use another physics library and get around this. They've chosen other development priorities instead.

The question of 32- versus 64-bit words is of little relevance for the floating-point parts. You can use 64-bit floating point math in the IA32 architecture, and KSP does all over the place. Intel-compatible machines have been using 64-bit floating point math since the original 8086/8087 pairing, which had 16-bit words. I don't say it's of *no* relevance because the newer instruction sets you get to use when assuming a 64-bit architecture provide you with floats that are actually 64 bits rather than 80 bits; precision is slightly reduced on newer machines (but we're talking parts per billion here).

64-bit would mean you need more memory to run KSP, but that it wouldn't crash when it overran its address space. in 0.22 that only happens when you have lots of mods; in prior versions it happened more often, and I assume that it'll happen in the future.

64-bit also means the compiler can safely assume you are running on a modern CPU instead of a 386 or an original Pentium. It therefore can use newer instructions, and otherwise tune the code to be rather faster.

[Mmmmyum]

Intel HD4000... Soz always forget that AMD have a similar line of cards

[Pds314]

It depends on what you're doing. I desperately want a 64-bit KSP because I have some ships in the many hundreds of parts range that frequently crash by overflowing at a bit under 4 GB of RAM despite having 16 gigabytes available in total.

Also, I'd guess about 12% or so of KSP users would be unable to run a 64-bit program at all due to having a 32-bit PC or 32-bit OSes.

One major thing that seems to kill you is textures. For example, running KSP with FAR, B9, Firespitter, KW Rocketry, and Hooligan labs (blimps), I frequently crash on anything over a 300 parts or so. In editors, undo history can be a major issue as well. Trying to undo or reload while working on a 500+ part ship will invariably crash the game. Crashing my 916-part VL-340B will almost invariable crash the game due to having to devote ram to exploding 916 parts.

[Murph]

Being able to use the full x86_64 instruction set, rather than being limited to the ancient i386 instruction set (even if you allow the compiler to use some later extensions to i386) can make certain operations significantly faster. Any operations already using doubles or longs (64-bit numbers) will get a significant benefit from using 64-bit registers. The 10–15% number suggested above is quite plausible as a result of those factors.

The statement above that 64-bit calculations are slower than 32-bit calculations, on at 64-bit CPU, is very likely incorrect, although I'd need to check the silicon reference manuals to be certain. 64-bit maths on a 64-bit CPU should be roughly the same performance as 32-bit maths on a 32-bit CPU, for the same clock rate. If the 64-bit maths is slower, it should not be by a significant margin.

Apple, Linux, and the UNIX world have all fully embraced 64-bit for a long time now, with nearly everything compiled as 64-bit binaries. As far as I'm aware, performance has pretty much been universally as good as 32-bit, but better in many cases. There will be narrow cases where 32-bit code does run faster on a 64-bit CPU, but they should be a very small minority.

[Seret]

There will be narrow cases where 32-bit code does run faster on a 64-bit CPU, but they should be a very small minority.

There certainly aren't any that I'm aware of that show up in the benchmarks of actual desktop or server workloads. Phoronix have been flogging this dead horse for years, all their results come back saying that 64-bit is either the same speed or faster for any given hardware.

Edited December 11, 2013 by Seret

[Ekku Zakku]

There certainly aren't any that I'm aware of that show up in the benchmarks of actual desktop workloads. Phoronix have been flogging this dead horse for years, all there results come back saying that 64-bit is either the same speed or faster for any given hardware.

Yeah, I think it's just a fallacy; performing a operations on 64 bit values obviously would take longer than 32 bit values, unless the CPU is made for 64 bit operations in the first place. 64 bit operations and far higher are possible to do on 32 bit CPUs, but it requires more cycles and does it in a less direct way. It doesn't make sense that it would be slower on a 64 bit CPU.

[Murph]

There certainly aren't any that I'm aware of that show up in the benchmarks of actual desktop workloads. Phoronix have been flogging this dead horse for years, all there results come back saying that 64-bit is either the same speed or faster for any given hardware.

Yup, to the best of my professional knowledge of it, same or better basically sums up the move from 32-bit to 64-bit, after the first few transition years (which were over in the late 1990s / early 2000s). I probably should have said "may be narrow cases", instead of "will be…", to be honest, as I don't have any cases in mind. The only generally expected downside these days is a slight increase in memory usage due to wider memory alignment by compilers, and that shouldn't really be a significant downside. Some data-intensive applications might benefit from ensuring that they use int32 or smaller data types for certain things where they really don't need the extra number width and can be confident that it will not be needed in the future.

[Bothersome]

I remember writing some assembly stuff on the TMS9900 processor (16 bit processor, some of you old timers might know what computer that one is in). I did some timing tests for a very intensive processing routine. One of those tests was to determine if loading a byte was any faster than loading a 16 word. They were identical because the processor loaded 16 bits across the data bus reguardless of how many bits you actually wanted. If you wanted the byte (MSB or LSB) it fetched the whole word from memory first then threw out the byte you didn't want.

I believe it was a limitation to the data size as wired onto the memory. I would imagine that our 64 bit processors and memory are wired the same way. You want 32 bits?, memory loads 64 and the other is discarded. There may be some buffering (in the loading of registers) if the next instruction is a read of the next 32 bits. But I kind of doubt it. Someone else might know and should offer some correction here, (I have not done any 64bit assembly) but how is 8 sequential byte reads done on a 64 bit processor? Is it one fetch, then shifted internally on the processor 8 times and fed into a register? Or is it 8 fetches from L1 cache?

[Murph]

I believe it was a limitation to the data size as wired onto the memory. I would imagine that our 64 bit processors and memory are wired the same way. You want 32 bits?, memory loads 64 and the other is discarded. There may be some buffering (in the loading of registers) if the next instruction is a read of the next 32 bits. But I kind of doubt it. Someone else might know and should offer some correction here, (I have not done any 64bit assembly) but how is 8 sequential byte reads done on a 64 bit processor? Is it one fetch, then shifted internally on the processor 8 times and fed into a register? Or is it 8 fetches from L1 cache?

Yes, down at assembly level, the memory read operation may well do a wide read then discard. That's the sort of thing which the compiler can optimise away, however, when reading adjacent data. The time where it can be important to use the smaller data types is when you are coding for vast arrays or data structures, and the difference between int8, int16, int32, and int64 (or float vs. double) multiplies up to become significant in terms of total memory footprint. That's assuming that any processing overhead doesn't kill the advantage in real terms. Or, for certain narrow cases of code, there can be an advantage (I think, I'd need to confirm the specifics on x86_64 registers) by being able to use some of the smaller registers, in addition to the 64-bit registers. The common case where it's more or less mandatory is if you are doing something like manually encoding and decoding network packet headers, or similar.

[John FX]

I am currently running 4 copies of KSP on my machine at the same time fine. They need their own folder but for testing craft while flying craft it`s great. I test KOS scripts like this as well.

They all run as well as a single copy with no frame rate loss.

Imagine how well a single copy could run with access to all those system resources...

3000 part craft, huge stations, all running better that a 600 part craft now. (this assumes multithreading also)

[Requiem762]

This matter has been bugging me for a good while now. When I run KSP, My computer's RAM usage only goes up by about a gigabyte and a half, far below the maximum amount allowed in the 32-bit game. If a 64-bit version of the game does appear (yes, I know there's a Linux one already), what would the difference be? Wouldn't the game still only use about 1.5 GB, since that's all it needs to run in the first place?

Your mileage may vary.

[Soda Popinski]

Googling Unity and multi-threading, I came across a Unity Multi-Threading Framework. I wonder if Squad or even a modder could apply this to KSP. If modders hacked in, multi-player, I wouldn't be surprised if this is doable.

[NeMeSiS]

Googling Unity and multi-threading, I came across a Unity Multi-Threading Framework. I wonder if Squad or even a modder could apply this to KSP. If modders hacked in, multi-player, I wouldn't be surprised if this is doable.

Disclaimer: Loom does not 'magically' enhance performance. Implementing multithreading takes time and efford. Unity's tools like physics, AI, networking, audio, etc will not directly benefit from this toolkit. Unity engine does remain thread-unsafe, therefore using Loom to speed up loading times of scenes and resources will not result in beter performance.

Considering the single PhysX thread is almost always the bottleneck it wouldnt help all that much.

EDIT: About mods making us run out of 32bits address space: Operation Flashpoint (2001) had the exact same problem about 10 years ago with mods, in the end developers did this which solved those problems. Though i dont know how it works, i assume that it is fixable.

Edited December 11, 2013 by NeMeSiS

[Donziboy2]

Well people could try using the Active-Memory-Reduction-Mod ....

It does a pretty good job of lowering the memory footprint.