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

[Pecan]

This is just so full of Wrongâ„¢ I don't even know where to begin ... "closed system disease"-ridden Mac.

As cantab partly illustrated - Apple stuff only works on Apple machines and if you want to write for Apple you have to start by buying one of their machines. I'd like to like them more, Apple IIe was the first machine I used as a professional, but it is the most fiercely guarded monopoly in IT. Good luck to them and all that, but their sales and money are coming from people who buy simple gadgets, not those that want to built a business-critical IT infrastructure. Linux has the opposite problem in that it's getting more and more popular with IT departments that have the staff who understand it but can't appeal to the mass consumer who find Windows too difficult anyway.

NB: I have no complaint about any of the three major (micro-computer) OSs, nor the people who choose them, nor their reasons for doing so. The marketing ethos of each supplier is different and something you should be aware of when buying (caveat emptor and all that) but they're equally valid.

[MalfunctionM1Ke]

I DONT want KSP to be ported into a 64-bit engine if it is not running stable.

Thats what everybodies opinion should be on the Topic and it is definetly the one of the devs, too.

[Merinsan]

I can't go into the nitty-gritty of it too much, I'll leave that to others if you want to get really techy. My high-level understanding of it is that due to the architecture of x86-64 and the longer word length the processor can handle longer numbers in fewer steps. This makes a big difference for computationally expensive tasks like encryption, video encoding and compression.

It's basically that the processor can handle 64 bits at a time. Think of it as a race track. If you want the result for 64 athletes, and you only have 32 lanes, you need to run 2 races. You only need 1 if you have 64 lanes. 64 bit architecture allows a 64 bit number to be processed twice as fast because it handles it in one cycle rather than 2 for 32 bit.

[WaveFunctionP]

http://en.wikipedia.org/wiki/64-bit_computing#32-bit_vs_64-bit

A common misconception is that 64-bit architectures are no better than 32-bit architectures unless the computer has more than 4 GB of random access memory.[26] This is not entirely true:

Some operating systems and certain hardware configurations limit the physical memory space to 3 GB on IA-32 systems, due to much of the 3–4 GB region being reserved for hardware addressing; see 3 GB barrier; 64-bit architectures can address far more than 4 GB. However, IA-32 processors from the Pentium II onwards allow for a 36-bit physical memory address space, using Physical Address Extension (PAE), which gives a 64 GB physical address range, of which up to 62 GB may be used by main memory; operating systems that support PAE may not be limited to 4GB of physical memory, even on IA-32 processors. However, drivers and other kernel mode software, particularly older versions, may not be compatible with PAE.

Some operating systems reserve portions of process address space for OS use, effectively reducing the total address space available for mapping memory for user programs. For instance, 32-bit Windows reserves 1 or 2 GB (depending on the settings) of the total address space for the kernel, which leaves only 3 or 2 GB (respectively) of the address space available for user mode. This limit is much higher on 64-bit operating systems.

Memory-mapped files are becoming more difficult to implement in 32-bit architectures as files of over 4 GB become more common; such large files cannot be memory-mapped easily to 32-bit architecturesâ€â€only part of the file can be mapped into the address space at a time, and to access such a file by memory mapping, the parts mapped must be swapped into and out of the address space as needed. This is a problem, as memory mapping, if properly implemented by the OS, is one of the most efficient disk-to-memory methods.

Some 64-bit programs, such as encoders, decoders and encryption software, can benefit greatly from 64-bit registers, while the performance of other programs, such as 3D graphics-oriented ones, remains unaffected when switching from a 32-bit to a 64-bit environment.

Some 64-bit architectures, such as x86-64, support more general-purpose registers than their 32-bit counterparts (although this is not due specifically to the word length). This leads to a significant speed increase for tight loops since the processor does not have to fetch data from the cache or main memory if the data can fit in the available registers.

64 bit isn't that big of a deal performance wise under most applications, it's the address space. 32bit already handles 64 bit length floats, and internal and external busses are larger than 32bits, even on 32 bit systems, so operating on 64 bits of data on a 32 bit machine doesn't mean it will always take twice as many clock cycles as a 64 bit machine. Modern cpus use all sorts of tricks to handle a variety of data, including double floats, quite efficiently.

[6.forty]

I DONT want KSP to be ported into a 64-bit engine if it is not running stable.

Thats what everybodies opinion should be on the Topic and it is definetly the one of the devs, too.

Well written code should really require little to no "porting". KSP 64bit is plenty stable in linux so I wouldn't think it's an issue with KSP or Unity itself, but it would make sense to me that it's an issue with platform dependent code and/or libraries that Unity uses.

[MalfunctionM1Ke]

Well written code should really require little to no "porting". KSP 64bit is plenty stable in linux so I wouldn't think it's an issue with KSP or Unity itself, but it would make sense to me that it's an issue with platform dependent code and/or libraries that Unity uses.

I understand that, forty.

All I want to say is, that Squad is free to take its time to make the 64bit Version stable and should not be hassled by People who are pushing towards it

I am fine with a Little lag due to high part Count but crashes awfull. You never know what Progress is still there while reloading the game.

[Virtualgenius]

Yeah but being locked to a limited amount of ram sucks, especially when everything is loaded into at the start. 64 bit will allow you to go past the 4gig limit which is my biggest gripe at the moment i run mods and the limit sucks. Be nice if C7 could pop in and give us a bit of an update

Edited March 18, 2014 by KasperVld

[MalfunctionM1Ke]

Yeah but being locked to a X amount of ram sucks, especially when everything is loaded into at the start. 64 bit will allow you to go past the 4gig limit which is my biggest gripe at the moment i run mods and the limit X. Be nice if C7 could pop in and give us a bit of an update

So you would like to have an unstable version of KSP which will crash everytime it has to manage some kind of heating on your ship? That would be like everytime you want to fire up your Mainsail or LVN.

That must be very frustrating to reaload your 4+ Gb of Ram with Mods after every Launch attempt.

[6.forty]

So you would like to have an unstable version of KSP which will crash everytime it has to manage some kind of heating on your ship? That would be like everytime you want to fire up your Mainsail or LVN.

That must be very frustrating to reaload your 4+ Gb of Ram with Mods after every Launch attempt.

It takes about a minute and twenty seconds for mine to load itself up to just shy of 6GB, and the only crash that has happened in some months involves ramming directly into planets at high speed from orbit. KSP itself is not unstable in 64bit, Unity is unstable on Windows/OSX in 64bit. There is a difference. A stable 64bit version of KSP is already available and in use by many; just because it's not on your OS of choice does not make it any less stable or available.

[Seret]

A stable 64bit version of KSP is already available and in use by many

I agree, the Linux 64-bit version of it works well. The problem isn't at Squad's end, they've already got 64-bit KSP working fine.

[radonek]

Yeah but being locked to a limited amount of ram sucks, especially when everything is loaded into at the start. 64 bit will allow you to go past the 4gig limit which is my biggest gripe at the moment i run mods and the limit sucks. Be nice if C7 could pop in and give us a bit of an update

You can use more then 4G with PAE, courtesy of all modern CPUs. KSP would still be limited to 4G address space though.

Edited March 18, 2014 by KasperVld

[Kialar]

A question to all those Users having access to 32bit and 64bit versions (e.g. Linux): Do you really experience a significant difference between those two?

[Red Iron Crown]

You can use more then 4G with PAE, courtesy of all modern CPUs. KSP would still be limited to 4G address space though.

It's hard to find a 32-bit OS supporting PAE that isn't Linux, in which case you should just go 64-bit anyway.

[Streetwind]

Ironically Windows has been supporting PAE for an eternity, starting with Win2000... and then Microsoft went and limited maximum memory on end user 32bit licenses to 4GB even with PAE. *facepalm*

Reason given: it broke legacy driver compatibility. Which is true, it did. But this is just another symptom of the "backwards compatibility above all else" paradigm that Windows follows. To this day, even Windows 8 32bit is still limited to 4GB with PAE. Thankfully there's next to no reason left to not buy a 64bit license nowadays.

Edited March 18, 2014 by Streetwind

[Red Iron Crown]

I think they limited it to 4GB for backward compatibility reasons. Only some server versions could actually use PAE to expand RAM capability. Other Windows versions technically supported it, in that the kernel understood PAE, but if you can't use it to actually address more RAM saying it supports it is a bit weaselly.

[magnemoe]

I think they limited it to 4GB for backward compatibility reasons. Only some server versions could actually use PAE to expand RAM capability. Other Windows versions technically supported it, in that the kernel understood PAE, but if you can't use it to actually address more RAM saying it supports it is a bit weaselly.

I think Microsoft thought about bypassing this with going 64 bit who was added in Win 2003 server. PAE don't help if your program require 5 GB anyway.

[Seret]

A question to all those Users having access to 32bit and 64bit versions (e.g. Linux): Do you really experience a significant difference between those two?

I've not noticed a big difference. You'd need to actually do some comparative testing, as I suspect it would affect some parts of the gameplay and not others.

The bottom line though is that almost everybody has 64-bit hardware, so by rights we should all be running 64-bit software. Unfortunately the Windows ecosystem is really, really holding back the transition.

[radonek]

Ironically Windows has been supporting PAE for an eternity, starting with Win2000... and then Microsoft went and limited maximum memory on end user 32bit licenses to 4GB even with PAE. *facepalm*

Reason given: it broke legacy driver compatibility. Which is true, it did. But this is just another symptom of the "backwards compatibility above all else" paradigm that Windows follows. To this day, even Windows 8 32bit is still limited to 4GB with PAE. Thankfully there's next to no reason left to not buy a 64bit license nowadays.

I stand corrected. Alas, I dare to say that "backward compatibility" is not the case anymore. I totaly believe it could wreak all kind of havoc on bad XP drivers, it certainly did on linux (PAE brings more then just a few bits to address registers, and for example DMA transfer by unaware driver can really ruin a day). But should not Vista+ drivers be certified, for exactly these reasons? Plus, amd64 arch still uses PAE (plus some extensions) so once you have working 64bit driver (which should be the case for Vista and later), you are halfway there.

So, after two major iterations and XP being officially retired (and burried under a crossroad) I don't buy this anymore. It seems more likely to me this is just to pump people for server versions.

[godefroi]

Uh, important thing to note here. 32-bit processes could ALWAYS use more than 4GB of memory. It was NEVER about memory. It was ALWAYS about address space: http://blogs.msdn.com/b/oldnewthing/archive/2009/07/06/9818299.aspx

Staggering amount of misinformation in this thread. If you're unfamiliar or only passingly familiar with the subjects under discussion here, just keep that in mind.

[Red Iron Crown]

Uh, important thing to note here. 32-bit processes could ALWAYS use more than 4GB of memory. It was NEVER about memory. It was ALWAYS about address space: [url=http://blogs.msdn.com/b/oldnewthing/archive/2009/07/06/9818299.aspx]http://blogs.msdn.com/b/oldnewthing/archive/2009/07/06/9818299.aspx[/url

Do you know if this was ever used in actual software, and not just a demonstration that such a thing was possible? Strikes me as a crude workaround.

[Arran]

Do you know if this was ever used in actual software, and not just a demonstration that such a thing was possible? Strikes me as a crude workaround.

Its something dating back from the MS-Dos 8Bit era, its the same "trick" used back then to allocate more as 512mb ram, this evolved into Windows and somehow still present to today.

Its part of the x86 memory allocation instruction set at the original design, to limit memory allocation to the CPU they could do other stuff needed (mostly due, memory back then was EXPENSIVE, and i mean REALLY expensive) thus saving on memory made computers affordable and much cheaper.

There are several gaps in the memory of a PC, at 512MB (x86), then memory needed to be extended to get 640mb (x286) memory by drivers, but drivers eat away working memory, thus if you had 1024mb memory, you can map drivers into that region, clearing up normal memory for usage (x386 era)

It allways kept part of the x86 based CPU in terms of backwards compatebility was is allways been one of the backbone on wish MS builded it OS system.

This design choise we still notice in some small extend.

Edited March 18, 2014 by Arran

[godefroi]

Do you know if this was ever used in actual software, and not just a demonstration that such a thing was possible? Strikes me as a crude workaround.

I'm not personally aware of any software which used the technique to use more than 4GB of memory, but the technique is commonly used for other purposes. Bank-switched memory access techniques in general were very common, though they are much less so today, with our larger address spaces.

One other point. Recompiling for 64-bit will not (necessarily) make it any faster. I don't know about Mono, but for .NET, the 64-bit JIT isn't as good as the 32-bit JIT. Also, you (necessarily) use more memory, because pointers (at least) get bigger. You have access to more registers, yes, and you don't have the WoW64 (on Windows) layer to deal with, but you still have the same amount of CPU cache, and you're using it less efficiently.

There's a lot of things that go into this, and unless the developers are participating in this discussion, none of us likely has enough information to make blanket statements.

[radonek]

Uh, important thing to note here. 32-bit processes could ALWAYS use more than 4GB of memory. It was NEVER about memory. It was ALWAYS about address space: http://blogs.msdn.com/b/oldnewthing/archive/2009/07/06/9818299.aspx

Staggering amount of misinformation in this thread. If you're unfamiliar or only passingly familiar with the subjects under discussion here, just keep that in mind.

What I gathered from article: to avoid 64bit arch rewrite, you "only" need to rewrite all memory code to use completely different mechanism. Which is incompatibile with any existing libraries or even syscalls. Outside of coding excercise, how does that help?

[godefroi]

What I gathered from article: to avoid 64bit arch rewrite, you "only" need to rewrite all memory code to use completely different mechanism. Which is incompatibile with any existing libraries or even syscalls. Outside of coding excercise, how does that help?

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.

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).

[cantab]

Ironically Windows has been supporting PAE for an eternity, starting with Win2000... and then Microsoft went and limited maximum memory on end user 32bit licenses to 4GB even with PAE. *facepalm*

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.