64-bit machine

[Pedro Falcão]

I'm using a 64-bit machine now, so i was wondering if there aren't any 64-bit version of the game (as 64 bit versions generally have better performaces) or if i have to use the emulated 32-bit version? I don't care at all about it, but the installer seems to emphasize it is 32-bit and i've not found any other versions for windows, so just to ask will not hurt, uh?

[Ykkrosh]

The game can't compile as 64-bit on Windows currently - it'll take quite a bit of effort to set that up (particularly recompiling all the third-party libraries we use), and the difference in performance is likely to be negligible, so it doesn't seem worthwhile.

(We do support 64-bit builds on Linux, so the game itself should be portable, but it's more of a pain to set up on Windows.)

[shnbwmn]

The game can't compile as 64-bit on Windows currently - it'll take quite a bit of effort to set that up (particularly recompiling all the third-party libraries we use), and the difference in performance is likely to be negligible, so it doesn't seem worthwhile.

(We do support 64-bit builds on Linux, so the game itself should be portable, but it's more of a pain to set up on Windows.)

I'm currently running 0 A.D. on 64 bit Windows, and I get a slight bit of lag. Perhaps a 64 bit build might be worth it

[Almin]

Are you sure, that there is much difference in the performance between 32 and 64 bit machines? Because I can't really imagine, that there is one. I don't have 32bit system running, but 'generally' most of the games(and not just games, I think) that are published, are still 32bit, aren't they? Maybe even parts of Windows itself?

[Ykkrosh]

Yeah, 64-bit Windows applications seem pretty rare, because it's rarely worth the cost of maintaining both 32-bit and 64-bit versions. It only really matters for applications that want to use more than about 3GB of RAM (or virtual address space). When they don't need that much (which 0 A.D. doesn't), 64-bit just provides a mixture of minor advantages and disadvantages for performance. (More CPU registers is good; SSE2-by-default is good; 64-bit arithmetic is occasionally good; bigger pointers use up more cache so they're bad). Won't make much difference either way, so it's better to spend the effort on optimising the 32-bit version of the code which'll help everyone on both 32-bit and 64-bit Windowses

[janwas]

A minor note on telling whether apps are 32-bit: you can see the Task Manager process listing. If "Image Name" ends in "*32", it's running in 32-bit mode.

That applies to about half of the processes I currently have running, so we're in good company

[Pedro Falcão]

Are you sure, that there is much difference in the performance between 32 and 64 bit machines? Because I can't really imagine, that there is one. I don't have 32bit system running, but 'generally' most of the games(and not just games, I think) that are published, are still 32bit, aren't they? Maybe even parts of Windows itself?

A processor being 64-bit means it receives a bundle of 64 bits of data (each 8 bits = 1 byte) per tick, instead of the common 32-bit bundles (independent of the processor speed). The more bits the processor can process per tick, the more expensive it becomes, so simpler tasks may require simpler processors (some microwave monitors, that one which calculates the time of the food inside, have 8-bit processors, for a sample).

Knowing this, we can come to the conclusion that a 64-bit processor, having the same speed of a 32-bit one, will have a better performance if anf ONLY IF the programs ran on it are properly designed for 64-bit bundles of data.

Also the same thinking applies to multi-core processors, the performance of a 9999999-core processor will only be better than yours if and only if the programs ran on it are properly designed for multi-threading.

[Ykkrosh]

A processor being 64-bit means it receives a bundle of 64 bits of data (each 8 bits = 1 byte) per tick

I think that's not really accurate . 32-bit processors can already add 128-bit values in about one cycle (using SSE), and read data from RAM in 64-bit groups, etc. "32-bit" doesn't mean everything is limited to 32 bits - lots of stuff (especially where performance matters) is larger than that, and stays basically the same on 64-bit processors.

[Pedro Falcão]

I think that's not really accurate . 32-bit processors can already add 128-bit values in about one cycle (using SSE), and read data from RAM in 64-bit groups, etc. "32-bit" doesn't mean everything is limited to 32 bits - lots of stuff (especially where performance matters) is larger than that, and stays basically the same on 64-bit processors.

I know that, but these details are processor-specific. Not meaning they aren't important, but let's take in account i was speaking with someone who hasn't much knowledge about these technical info and the general rule is that some part of the processor is limited to that X value.