Expected behavior of 32-bit bitcoind when running on AMD x64?

[Furyan]

I just have a quick question... as an experiment I've tried running the stock 32-bit bitcoind binary from bitcoin.org, on a 64-bit windows machine. The block chain at this point has taken well over 24 hours to download and is still not finished (has about 3000 blocks to go).  Typically it takes ~3 hours on my other machines.

The one key piece of information might be that the box is dual-IP.  It has two IP addresses assigned to its NIC.  What's interesting to me about this is that when I do something like "bitcoind getinfo", it takes several minutes to respond.

Is this expected behavior?  I can simply download and recompile the source for 64-bit, I'm just wondering why I'm seeing this. It doesn't seem to be related to open/closed ports. I do see high-ish CPU usage (average ~30%) but I've always seen this on any machine downloading the block chain.  The debug.log file reveals no interesting messages that might suggest why this is taking so long.

Details:

Bitcoind = 0.5.2 beta
server=1

Machine details:
AMD 2.9 GHz Dual Core Athlon 2
OS: Windows Server 2008 R2
4 GB RAM

Input appreciated.

[Revalin]

32-bit doesn't matter much.  Bitcoind doesn't use a lot of memory.

The long download time is because Bitcoin verifies all transactions (computationally expensive) as it downloads the blockchain.  If you want to skip this you can download the blockchain here: http://eu1.bitcoincharts.com/blockchain/

[grue]

It shouldn't matter on windows. syswow64 handles the conversion between the two architectures no problem. If you have lot of ram (over 4 gb), you can try setting bitcoin's data directory to a ram drive. You will be able do download the blockchain in less than 1 hour.

[Furyan]

It shouldn't matter on windows. syswow64 handles the conversion between the two architectures no problem. If you have lot of ram (over 4 gb), you can try setting bitcoin's data directory to a ram drive. You will be able do download the blockchain in less than 1 hour.

I'd have thought the same thing, esp. since the machine is on a gigabit network.  Seems the problem was the dual-IP.. it confused the pool server too, so that was probably it.

All fixed now just thought it was odd..