Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[The-Moon]

I assume right now DF is complied for 32bit.

Is it possible for toady to compile a 64bit version?

Or dose it not work like that?

I am a programmer but i don't know that much about 32-bit and 64-bit.

[Wideman]

dude wat do u mean

if ur rederrinf to the games .exe  i think it prolly is ... nut i dont rly knw newbi programmer here lol

cuz atm im running X64 Win 7 Ultimate nd it runs perfectly normal no errors like normal ones if it wasnt made to run on 64 but like i said i dunt know much nout it only newb XD

[MonkeyHead]

Dude, what do you mean?

If you are referring to the games .exe,  I think it probably is ... but I don't really know: new programmer here.

At the moment I am running X64 Win 7 Ultimate and it runs perfectly normal (none of the errors you would expect if a 32-bit .exe was running in 64-bits)... but like I said I dont know much about it, as I am new to this.

Translated free of charge... although I am not responsible for the actual answer.

[Wideman]

lollzor thnks

[tomas1297]

lol u trol?

[numerobis]

What's the advantage of a 64-bit compilation in this case?

[darius]

32 bit programs have max of 2 gb memory (or 3 if compiled with some flags) while 64 bit has limit of (very big number) also 64 bit commands usually speed up programs witch use big amounts of memory as every command is operating with twice as much data (approx)

[Fourdots]

$ file dwarfort.exe
dwarfort.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit

So current 32-bit, not that that should surprise anyone, as it runs on all computers, not just 64-bit ones (64-bit computers can run 32-bit programs, but not visa versa, as I recall - hardware compatibility mode, software emulation, or, according to wikipedia, through an integrated 32-bit core, which is somewhat unexpected, for me at least)

It would be possible for toady to compile a 64-bit version, assuming that he has a 64-bit computer sitting around to do so on. Doing so would make it somewhat faster on 64-bit computers, probably. Depending on how the code is written, this might be more or less difficult to do. Best case, it would be as simple as compiling it on a 64-bit computer with all the right flags in the compiler; worst case, a bunch of code would have to be changed, depending on how memory is addressed, though that seems a bit unlikely to me.

I would expect that if DF goes 64-bit, it would be a lot faster; seems like the sort of program which would get a pretty big speed-up from that. On the other hand, some programs don't get any significant speed-up.

[SolarShado]

As far as i know, it'd just be a matter of setting the right compiler option... assuming the compiler supports it.

Cross-compiling (building code for one architecture on a different one) is possible, so Toady wouldn't necessarily need a x64 machine of compiling. Testing, of course is another matter.

I'd thought about the possibility of a 64-bit build as well, all new computers are 64-bit now (of course, there are still plenty of 32-bit machines out there, ceasing support for them would be suicide).

I'm not terribly knowledgeable about the differences, but if it'll give DF a performance boost with possibly minimal work for Toady, I say it's worth checking into.

[numerobis]

The benefit of 64-bit compilation is that you can access more memory.  If you don't need to access more memory, that's pretty pointless.

As a side benefit, if you compile for 64-bit pointers, then you may as well assume you have all the operations available on the earliest 64-bit capable chip version; that can speed things up.  But you can also just enable MMX and SSE and etc anyway (and I gather that is the case; at least the 40d# versions were compiled assuming you had at least a Pentium 3).

[eerr]

More memory in the register (inside the motherboard, I think) could go a really, really, long way.
If it's in the register then you won't need to retrieve it from ram to work the data.

for things like: fluid dynamics, pathfinding, ect this could form a rather extreme improvement.

[Corona688]

So current 32-bit, not that that should surprise anyone, as it runs on all computers, not just 64-bit ones (64-bit computers can run 32-bit programs, but not visa versa, as I recall - hardware compatibility mode, software emulation, or, according to wikipedia, through an integrated 32-bit core, which is somewhat unexpected, for me at least)

It doesn't have a seperate 32-bit core.  It just uses 32 of the 64 bits to execute 32-bit instructions.

It would be possible for toady to compile a 64-bit version, assuming that he has a 64-bit computer sitting around to do so on. Doing so would make it somewhat faster on 64-bit computers, probably.

That's dubious.  For one thing, modern processors whether 32-bit or 64-bit fetch and store memory in blocks bigger than 32 bits all the time anyway, and 64-bit instructions for many operations have been available since the mid-90's.  Making them general-purpose makes it easier for the compiler to use them, though.

On the other hand, memory usage tends to increase when you recompile something as 64-bit too, since every pointer in the program suddenly takes up twice as much memory, meaning more data to move around all the time even if some of it can happen a bit faster.  In programs that use a ton of memory already that can be quite significant.  On the other hand, there are a ton of extra general-purpose registers in 64-bit mode which lets the optimizer do a better job.  So it's a tradeoff between whether the optimizer improvements will find enough to do to offset the extra memory use.

Given how much memory DF uses already, I'm not really convinced a 64-bit version would be worth it.  Especially when it's obvious there's so much room for improvement in the code itself(see the 40D# series, etc).

Best case, it would be as simple as compiling it on a 64-bit computer with all the right flags in the compiler; worst case, a bunch of code would have to be changed, depending on how memory is addressed, though that seems a bit unlikely to me.

Theoretically it's just recompiling.  Practically, a lot of code gets away with making assumptions about the size of variables, that you can get away with jamming a pointer into an integer etc.  In 64-bit mode some important assumptions break -- some variables increase in size and some don't.  From recent comments by toady where he was doing search/replace in thousands of pages of code, it sounds like there may be some to many places where assumptions will break.

I would expect that if DF goes 64-bit, it would be a lot faster; seems like the sort of program which would get a pretty big speed-up from that. On the other hand, some programs don't get any significant speed-up.

The main advantage of 64-bit mode is the ability to use truly monstrous amounts of memory.  It could result in a DF that's not quite as fast but will handle incredibly long worldgens etc. without crashing.

[Corona688]

More memory in the register (inside the motherboard, I think) could go a really, really, long way.
If it's in the register then you won't need to retrieve it from ram to work the data.

Not just registers but caches too, all built into the CPU, superfast hardwired RAM to reduce the number of memory fetches it needs to do.  These caches are one of the main differences between things like athlons and semprons of the same clock speed, the cache of some semprons is pretty puny.

[numerobis]

I feel like I saw that the code is 64-bit clean (maybe the linux build is 64?  I forget).  So it is just a compiler option.

There's three things that you're alluding to:
1. word size (32 or 64)
2. new instructions
3. caches, internal registers, etc

For 3: Almost no matter how dumb the compiler, you're generally benefiting when the caches grow and the number of internal registers increases and clock rates increase.  By default, compilers often assume you're running on an ancient machine (a 386, or maybe a pentium), but the relative cost of various operations has changed in the intervening 25 years; you can get marginally faster code by tuning to a more recent chip so the compiler has a more realistic view of the relative cost of operations on machines people actually use.  Your code will still run on a 386 though.

For 2: If you have the compiler use the newer instruction sets (MMX, SSE, etc etc), then it will frequently be able to produce faster code.  Chips that don't support that new instruction set are left out: they just won't be able to run your code.

For 1: If you have the compiler use 64-bit pointers rather than 32, then assuming you have OS support for it, you can access much more memory, at the cost that now your pointers take up twice as much space -- so now your caches are somewhat less effective, and you need to move more memory over the bus.  As it happens, if you ask your compiler to use 64-bit pointers, it will assume it's also OK to use newer instruction sets and to tune to a newer chip.  But you could have done that even when compiling for 32-bit pointers.

[eerr]

I'm gonna package you up and ship you to Toady.