digitalmars.D.learn - Is build a 64 bit version worth if I'm looking for better perfomance?
Dr.No <jckj33 gmail.com> writes:
Looking for make application run fast as possible, aside optimization in the source code, is using 64 bit over 32 really worth?
May 01 2018
Uknown <sireeshkodali1 gmail.com> writes:
On Tuesday, 1 May 2018 at 22:48:08 UTC, Dr.No wrote:Looking for make application run fast as possible, aside optimization in the source code, is using 64 bit over 32 really worth?With the GC yes, since false pointers become less of an issue. Also you get to take full advantage of the target CPU. The vast majority of home computers today use 64 bit. You'll also be able to take advantage of more optimizations since the compiler can assume more features are available. But you will *probably* get better performance from profiling + optimizing than 32 bit -> 64 bit.
May 01 2018
Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, May 01, 2018 22:48:08 Dr.No via Digitalmars-d-learn wrote:Looking for make application run fast as possible, aside optimization in the source code, is using 64 bit over 32 really worth?That would heavily depend on the program. The big win for D code and 64-bit that doesn't necessarily apply to other languages would be that the GC won't end up with false pointers like it does with 32-bit code (i.e. because the address space is small enough, when scanning, it can easily think that a 32-bit integer value is a pointer and thus not free that memory, because it thinks that you have a pointer to it; the 64-bit address space is large enough that that doesn't happen enough to really matter). But aside from that, as I understand it, it's not an obvious gain one way or the other and is really going to depend on what you're doing. In general, it's better to match the architecture of the machine, which would almost certainly mean 64-bit at this point, but modern x86_64 machines are highly optimized for 32-bit code as well, and 64-bit programs tend to use more memory, because stuff like pointers are twice as large (the program won't use double the memory, because it's not like everything that gets pointed to doubles in size - just the pointers and other types whose size depends on the size of pointers - but you'll use more memory, which can slow things down). So, some stuff will be faster with 32-bit and other stuff will be faster with 64-bit. In general, at this point, talking about whether you should be writing 32-bit or 64-bit programs is kind of silly outside of Windows. Everywhere else, you just target what the OS is running, which is probably 64-bit, and with Windows, whether 32-bit or 64-bit is better probably has more to do with what you're trying to do with your program than anything (e.g. whether you have to worry about supporting folks with 32-bit Windows installs). D in general is designed to be architecture-independent. It doesn't always succeed at that, but most D code is going to work just fine as both 32-bit and 64-bit (especially if auto and size_t are used properly). And it's generally bad practice to target one or the other. As such, you can just write your program and then see how it performs as 32-bit and how it performs as 64-bit. If performance is then your biggest concern for choosing 32-bit or 64-bit, then you can just go with whichever performs better. Either way, I would strongly discourage you from making it so that your program only works as 32-bit or only works as 64-bit - not unless it's doing something that requires enough memory that it has to be 64-bit, and most programs don't need that. - Jonathan M Davis
May 01 2018