64-BIT M$ Version?

[crash893]

Any idea when a release version of
Bitcoin will come out in a 64-bit version?

thanks

[SmokeTooMuch]

There already are some 64-bit windows builds of bitcoin.
use the board search machine.
(afaik there isn't a 64-bit build of 0.3.20, but lower versions)

[BitterTea]

Is there a reason you want to run a version compiled for 64 bit? The normal client works fine on 64 bit Windows 7.

[SmokeTooMuch]

Just one example of the various custom 64-bit builds (all unofficial, just so you know)
->https://www.bitcoin.org/smf/index.php?topic=866.msg10330#msg10330

[jgarzik]

Any idea when a release version of
Bitcoin will come out in a 64-bit version?

There is no reason why Windows users need a 64-bit version, really.  Bitcoin does not need the address space, nor does it need to be uber-optimized.

The 64-bit version would benefit you for CPU mining... but if you are CPU mining, you will get better performance from ufasoft's CPU miner or my cpuminer.

[crash893]

Is there a reason you want to run a version compiled for 64 bit? The normal client works fine on 64 bit Windows 7.

because i have the 64 bit os. My hope is that if its .net (which i think it is) that it would reduce some of the burden on the os displaying and doing work on the framework even if the hash algorithm isn't optimized for 64bits yet.4 b

in anycase 64bit is the way of the future might as well start programing for it now. I have seen several reports that windows 8 will have a build for 128bit architecture

[BitterTea]

The main Bitcoin client is actually written in C++. Other than generation (which is next to useless on the CPU anyway) and importing/scanning the block chain, nothing about the client should take up a whole lot of processor time. Until there's a full client port to another language, I don't think we'll see a 64 bit build (but I'm willing to be proved wrong ).

[jgarzik]

It is naive to simply think "64 bits is better."

64-bit code uses more memory for data -- pointers and long integers are twice the size of 32-bit code.   64-bit code instructions tend to be larger as well (though this is mitigated on x86-64, as x86/CISC is essentially a compressed instruction set and x86-64 adds many more general purpose registers).

This is why many non-x86 platforms ship 32-bit userland with 64-bit kernel.  Code and data are more compact on 32-bit, which is far more cache-efficient.

Thus, on the same machine, 32-bit code might actually use fewer CPU cycles than 64-bit code.

[crash893]

why not go back to 16-bit programs then?  they are still backwards comparable.

Memory is not that big a deal when new desktops come with 6-8gigs from the factory.

I also see that someone compiled a 64bit version with a different (64bit optimized hash algorithm)


I think we can all agree that an official 64bit option is on the way its just a matter of when

[theymos]

why not go back to 16-bit programs then?  they are still backwards comparable.

64-bit versions of Windows don't have support for 16-bit programs. And the limitations for 16-bit programs are significant, whereas the limitations for 32-bit programs are usually not significant.