Print

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

[Volatar]

However, I do know that 64 bit windows cannot run a 32 bit application that still has 16bit code in it

Well that would have been nice to know last week. 

I spent maybe 4 hours trying to get an old game (with 16 bit code) to run.

I could have played DF that whole time, what a waste...

[Draco18s]

However, I do know that 64 bit windows cannot run a 32 bit application that still has 16bit code in it

Well that would have been nice to know last week. 

I spent maybe 4 hours trying to get an old game (with 16 bit code) to run.

I could have played DF that whole time, what a waste...

Has to do with WoW (Windows on Windows) that allows 32bit compatibility.

[CynicalRyan]

but for some reason the mass of OS out there is for 32bit

You are speaking about the end-user market. Look at Server OSes, and you won't find anything but 64bit OSes (excluded are the SOHO servers, but even there I wouldn't be so sure).

And the reason is, that 64bits actually requires work by the hardware vendors, since you can't simply exchange all the cheap parts of the cheap PC/laptop you are selling by way of the spot market. Windows 64bit drivers, for example, have to be signed. Which means that an actual effort has to go into debugging.

Then there's the fact that few us, currently, need the features of 64bit architectures (like more than 2GB application space, or more than 4GB of addressable RAM).

[Draco18s]

Then there's the fact that few us, currently, need the features of 64bit architectures (like more than 2GB application space, or more than 4GB of addressable RAM).

3GB actually.  The windows Page File sucks up some, as well as VRAM.  32bit XP won't register more than 3GB of physical RAM.

And it's starting to be an issue for home and office workers: you can get 2x2GB ram for about $90 now.

Need it?  No.  Want it?  Yes.

[CynicalRyan]

3GB actually.  The windows Page File sucks up some, as well as VRAM.  32bit XP won't register more than 3GB of physical RAM.

Memory for applications is limited to 2GB in x86 architecture. That's a hard limit.

And it's starting to be an issue for home and office workers: you can get 2x2GB ram for about $90 now.

It becomes an issue once you want to run an application that needs more than 2GB of RAM allocated to it. Which aren't that many for the end-user. Photoshop and Premiere, maybe, need that if you want to work on an HD video, but people who does that regularly and with passion probably run a 64bit OS anyway.

What you mean, I guess, is the memory limited of x86 processors, which is at 3.5GB. The upper 512MB are used for hardware addressing, like DVD drives, the BIOS, etc. However, PAE and a PAE enabled CPU make me not care about htese 512MB, since the OS can use this space if you got PAE.

[Draco18s]

3GB actually.  The windows Page File sucks up some, as well as VRAM.  32bit XP won't register more than 3GB of physical RAM.

Memory for applications is limited to 2GB in x86 architecture. That's a hard limit.

Wasn't referring to that limit, not one I knew.

And it's starting to be an issue for home and office workers: you can get 2x2GB ram for about $90 now.

It becomes an issue once you want to run an application that needs more than 2GB of RAM allocated to it. Which aren't that many for the end-user. Photoshop and Premiere, maybe, need that if you want to work on an HD video, but people who does that regularly and with passion probably run a 64bit OS anyway.

Nuke, too.  That is, a Weapon of Mass Creation.  It's video editing software, one of the best--node based, though the program only tangentially has a timeline, as if it was added in as an afterthought.  Even with my 6GB of RAM and dual core 3 GHz machine it took ages to render out what I was working on.  And oh yes, it peaked both cores.

[SmileyMan]

Works fine on my 64-bit Windows 7 beta. 

Porting an application from x86 to x64 is non-trivial, especially if you do your own memory management (possible, given the size of some of the datasets in the game) or work with byte-packed data (which DF definitely does do), but if Toady's got a spare day, I'd rather he spent it on the game, TBH.

[Baughn]

Chiming in a bit late, but - BC works perfectly well when compiled in 64-bit mode; C++ is mostly source-compatible between 32-bit and 64-bit intel.

DF might not, but I think the largest problem here is that Toady does not have a 64-bit machine. IIRC he's still on a P3 or P4, in fact.

Oh, and the memory space might not matter, but x86_64 has twice as many registers as x86. Trust me, that would give a speedup.

[0x517A5D]

Oh, and the memory space might not matter, but x86_64 has twice as many registers as x86. Trust me, that would give a speedup.

Not as much as you would think.  Yes, having 15 registers instead of 7 is wonderful.  But for 5 years (6? 8?) x86 CPUs have had what's called a shadow register file, which is a set of 64 or more registers which silently map to the classic registers and, critically, to memory locations on the stack.  So "PUSH EAX" does make a memory reference, but "POP EAX" does not make a memory reference unless the internal CPU mini-stack has underflowed.  The shadow register which mapped to that use of EAX is automatically reused instead.  So pushes are nearly free (as no register is modified by a push except the stack register which has special hardware support) and pops at the level of leaf functions are completely free.  It's cool stuff.

Still, yes, having more registers leads to better register allocation by the compiler.  So you do get some extra speed.  More than you lose by shuffling around twice as many bits.

64-bit RIP-relative memory addressing is way-cool as well, but that is more a linker/loader thing than something that affects execution speed.

[Baughn]

Yes, I know.

Hope someone else learned something, though.

[Gertack]

32-bit Windows can use up to 64GB with PAE extensions, although Windows XP won't use more than 4GB. (You didn't spend enough $$$ for it to do that.)  If your BIOS remaps reserved memory above the 4GB barrier then you will have more memory accessible in Windows (3.7GB on my desktop that does, 3.2GB on my work laptop that doesn't). Biggest hog tends to be the AGP Aperture.

Each process (program) is limited to 2GB of memory because the kernel has a permanent map on the other 2GB.  If you use the /3GB switch then each process can use 3GB of memory and the kernel uses 1GB.  Downside is less room for the kernel to map things, which can cause problems for devices that use large IO regions, like video cards.

You don't want to use PAE if you can use 64-bit, which is complicated by spotty Windows 64-bit driver support.

Note that Windows 64-bit drivers do not necessarily have to be signed, because there is a Windows XP 64-bit that doesn't care about signing, although it isn't known to as many peopel as Vista 64-bit.

AMD chose to keep the default word (not address!) size 32-bit, unlike the DEC Alpha.

Not that any of this means you need a 64-bit Dwarf Fortress since your fort would run with almost negative FPS if you had a fort large enough to need a 64-bit address space to store it.

[mithra]

Memory for applications is limited to 2GB in x86 architecture. That's a hard limit.

I don't think this is correct.  Please elaborate.

[Baughn]

It is, of course, incorrect.

The total memory mapped at any one time is limited to 4GB, although with PAE the total possible physical memory is 64GB.

The thing is, some of those 4GB will be mapped to devices, some to kernel space, etc. Therefore you don't get the full 4GB for an application.. well, you could in theory create an OS that allowed it, but it'd be *slow*.

In Windows the default split is 2GB/2GB.
In Linux the default split is IIRC 3GB(app)/1GB, with an option to up that to 3.5G/0.5G... or it might be 2G/2G and 2.5G/1.5G. I don't quite remember.

The point is, it depends on the OS.

[macdonellba]

In Linux the default split is IIRC 3GB(app)/1GB, with an option to up that to 3.5G/0.5G... or it might be 2G/2G and 2.5G/1.5G. I don't quite remember.

Apparently, the default is 3G/1G, though alternate configurations are possible.