Jump to content

KSP 32 vs KSP 646

steuben

By steuben
in KSP1 Discussion

 Share

Recommended Posts

Alshain

Alshain

Posted
Posted

I question why you would leave aside the question of available memory?

Don't assume that having 4 GB of memory means it can't help you.  If you have dedicated video ram, that counts toward the total.  So if you have 512MB of VRam and 4GB of ram, you are losing 1/2 a GB of RAM if you run the 32-bit version.

Link to comment
Share on other sites
steuben

steuben

Posted
  • Author
Posted

On one machine i'm on a non-negotiable 32 bit OS, on the other i'm on 64 bit. with 4 and 8 GB of respectively.

I'm leaving aside the question of ram because it is trivial. 64 bit gives you the option of more ram available to the program.

 

Link to comment
Share on other sites
MedwedianPresident

MedwedianPresident

Posted
Posted

64-bit KSP, like said before, has more RAM allotted to it, meaning that crashes don't occur as frequently as with 32-bit KSP. I guarantee that it will still crash, but not as often. You may or may not also experience a increase in performance. I recommend running 64-bit KSP and forcing OpenGL if you have many mods (like me).

Link to comment
Share on other sites
magnemoe

magnemoe

Posted
Posted
4 hours ago, Alshain said:

I question why you would leave aside the question of available memory?

Don't assume that having 4 GB of memory means it can't help you.  If you have dedicated video ram, that counts toward the total.  So if you have 512MB of VRam and 4GB of ram, you are losing 1/2 a GB of RAM if you run the 32-bit version.

Video card memory count as part of the 4GB memory in 32 bit windows so if you have 4 GB and a video card with 2GB windows only get 2GB of main memory left. 
It you run an 32 bit program on 64 bit windows with 4 gb memory and a video card with 4 gb program still can access up to 4 gb. 
This is why 64 bit windows always makes sense. 
Still you can just as well run 64 bit KSP. 

 

Link to comment
Share on other sites
wumpus

wumpus

Posted
Posted
8 hours ago, Pecan said:

Leaving aside the question of available memory, no.
Therefore, leaving aside mods, no.

Want mods = need memory = 64-bit.
Apart from that, you've got them both so why wouldn't you run 64-bit?

You will get a better cache hit rate with 32 bit (maybe).  If you are playing pure stock it should run ever so slightly better.  For some reason I've been playing it in 32 bit mode (my icon was set to "ksp.exe" not ksp_64.exe".  It *might* have been responsible for a few bugs, but I doubt it.

Link to comment
Share on other sites
Guest

Guest

Posted
Posted (edited)
2 hours ago, MedwedianPresident said:

I recommend running 64-bit KSP and forcing OpenGL if you have many mods (like me).

Can also force DX11 instead; might work better than OpenGL on systems with better than onboard graphics.

Edited by Guest
Link to comment
Share on other sites
Pecan

Pecan

Posted
Posted
8 hours ago, Talos said:

x64 applications are best used when you have more than 4 GB's of onboard memory...

If you have a 64-bit system and don't have more than 4GB memory, you should reassess your purchase decision (ie; buy some more RAM).

Link to comment
Share on other sites
suicidejunkie

suicidejunkie

Posted
Posted
5 hours ago, Pecan said:

If you have a 64-bit system and don't have more than 4GB memory, you should reassess your purchase decision (ie; buy some more RAM).

A while ago, the company bought 12GB of ram for all our office desktops.

That was a neon sign that RAM was dirt cheap and I should get an even bigger pile for myself at home too.

Link to comment
Share on other sites
radonek

radonek

Posted
Posted

There is more to 64bit cpu than more address bits. And those other features are important, otherwise you'd be happily using Itanium by now. I will thus call current PC architecture  amd64 since thats its name in linux kernel. In no particular order:

  • Additional memory may need more levels of pagetables, slowing down memory access. Silicone uses some tricks to avoid that, so it should not be noticeable except some very special circumstances. (read: having so much memory that page tables can't fit in on-die caches)
  • amd64 have additional registers which can be used to pass arguments to functions. (read: Runs faster. Good thing as long as you don't need to debug such calls :-(
  • amd64 libraries are by default relocable (not sure if this even applies to windows)
  • x86 arch can't make use of page not-execute bit
  • Introduction of new architecture can be used to do a bit of long overdue cleanup in syscalls. (enlarging time_t, handling of large files etc…)
  • Same goes for hardware, arch design is a chance to get rid of some old cruft (segmentation comes to mind. Screaming.)
  • In fact, same could be said about many other parts of system which are in need of structural changes. For example, amd64 port of linux dynamic linker introduced some useful changes that could not be made before because of backward compatibility. Dunno about windows api, but given the heritage, I'd guess there would be even more of legacy crap in dire need of straightening up.
  • Wider hardware word occupies more space in on-die caches. If your data set is big enough to push out hot cache lines, am64 code may run noticeably slower then x86 one. (other amd64 features offset this, so you are not likely to see this directly unless you do heavy number crunching. Fun story: People who do went as far as inventing additional ABI in linux, called x32, which combines useful parts of amd64 arch with 32bit pointers. Note how this is markedly different from windows programmers who stick with x86 for ostensibly same reason, but are in fact just lazy.)
  • All that additional bits and registers are bound to have impact on task switching (you have to store and restore all registers from memory), but I have absolutely no idea how much.
  • Obviously, 32bit binaries can't use 64bit features directly (and indirect methods, like accessing more memory via PAE are complicated and limited).
  • Contrary to popular myth - you can't just run x86 code in long mode. Sure, you can feed instructions into cpu (they are mostly identical after all) but to do anything useful, you need to do syscalls, interact with drivers, link libraries etc. and that can't be done without taking some elaborate hops between long and legacy mode. Overhead depends on what exactly are you doing and how is interfacing implemented and its rather complicated, suffice to say that in long mode (on 64bit system) native code can follow somewhat shorter path then legacy code.
  • Good 'ol human factor lives and its kinda funny to compare how customs affects what should be purely technological question. Architectural ports are rare in windows world (hands up who ever laid hands on Alpha or Itanium ports) and people are not used to handle that. Drivers are one particular piece of code that have to be written well, native and without crutches, which is why early 64bit windows were so terrible and adoption struggled. (And I'm sure this was a factor in aforementioned ports eventual downfall). In *nix world situation is reversed, fragmentation is a major problem, but upside of that is people are used to porting. Thus linux could have well working amd64-based system in months, but is still stuck with (ported) incredibly baroque graphics system dating back to 1984. (and this could be applied to many other parts of system)
  • Big address space may come handy even if you do not have that much memory. For instance, you can mmap() file of any size, more memory will only cut down disk IO.
  • OTOH having unused memory can't hurt either. Kernel will use it for disk cache, dma buffers, that kind of stuff. (This does not translate to "runs faster" but may help in some operations, ie. quicksaving will be snappier if there is more disk cache to throw io into)

Moral is: baring plain bugs in drivers or Unity (read: your 64bit ksp binary does not crash much more then legacy one) native code is definitely way to go.


 

Link to comment
Share on other sites
magnemoe

magnemoe

Posted
Posted
On 12.8.2016 at 8:27 PM, Pecan said:

Leaving aside the question of available memory, no.
Therefore, leaving aside mods, no.

Want mods = need memory = 64-bit.
Apart from that, you've got them both so why wouldn't you run 64-bit?

Its pretty easy to run into memory problems even without mods if you build lots of huge bases, ships and stations. 
This tended to kill my 32 bit games even without much mods. onlky MJ. KAC, KIS/ KAS, hyperedit. 
 

Link to comment
Share on other sites
softweir

softweir

Posted
Posted
On 8/15/2016 at 9:33 PM, Bill Phil said:

Besides getting hot, every thing else is perfectly fine. It's osolated to ksp.

Might that be because KSP is the only app that uses that much memory? It's always worth getting a memory test app and running it.

Link to comment
Share on other sites
Bill Phil

Bill Phil

Posted
Posted
1 hour ago, softweir said:

Might that be because KSP is the only app that uses that much memory? It's always worth getting a memory test app and running it.

Definitely a possibility, but I'm not so sure. KSP 64 bit was remarkably unstable before Unity 5. I'm thinking it might've retained some of that instability....

Link to comment
Share on other sites
softweir

softweir

Posted
Posted
21 hours ago, Bill Phil said:

Definitely a possibility, but I'm not so sure. KSP 64 bit was remarkably unstable before Unity 5. I'm thinking it might've retained some of that instability....

That was due to Unity's very bad implementation of 64-but, which most people find has been fixed. Regardless - it won't cost you anything to test your memory, and might solve a few problems!

Link to comment
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...