• Dr.No (3/3) May 01 2018 Looking for make application run fast as possible, aside
• Uknown (8/11) May 01 2018 With the GC yes, since false pointers become less of an issue.
• Jonathan M Davis (36/39) May 01 2018 That would heavily depend on the program. The big win for D code and 64-...

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?

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.

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