32bit vs 64bit OS

[ThE_JacO]

More of a programming than hw question probably.
The answer would be: "yes and no".
Certain allocations and alignments might end up requiring more memory in 64bit. Double in the specific, often only slightly larger in the bigger picture.
Pointers are larger in size, so are ints, some scalars, some symbols and so on.

Given the average dataset and its use in most aspects of a 3D app though, the footprint difference is usually negligible (especially in the context of how much ram you're likely to have on a 64bit system), but depending on what you're doing, might not always be so negligible.

[trv06kviper]

While it is true 64-bit does take up more memory (because it can run both 32 and 64 side by side and has to load up both 32 bit and 64 bit libraries etc). The memory usage is only slightly higher if any. Thats more of the operating system than the actual program's fault. Now the important part really boils down to the processor; dual core, quad core, core i5, core i7...etc and how that uses memory. The newer processors usually don't have a FSB and will directly access the ram which is DDR3. If you have say a core i5 and i7 you'll be using DDR3 and usually will have a LOT of ram, so in that case there really is no difference at all as there is no middle man to access the memory when it needs it. Thats how its been explained to me, hope that helps a little bit?

[ThE_JacO]

**double post**

[ThE_JacO]

You need to consider cockpunching whoever explained it to you that way :)
The processor and how it accesses the memory has hardly anything to do with memory footprint of an application, only the width of the addressing does in this case.
If you need a pointer, you need a pointer. If you're on 32bit, the pointer is 32bit big because that's the required amount of bits required to describe how to retrieve a block of memory. If you're on 64bit, the descriptor is twice as large.
Same for a long, it's one width big. That means 32bit big on 32bit platforms, 64bit big on 64bit platforms.

If you store a table of 100x100 longs, and get a pointer for each address, on 64bit, solely because of the architecture, you will be using exactly twice the memory regardless of whether you use ddr2, 3, 4 or 5 and regardless of os flavour. That is because of how the program needs to be compiled.

[trv06kviper]

...He worked for IBM on the new video graphics processor....

[ThE_JacO]

Then maybe you misunderstood the explanation, or maybe you're discussing something slightly different from the thread's OP's question :)
What I'm talking about is rather factual (pointers being sized depending on width etc.), and along with longer text and beefier symbols they are the main reasons for a difference in footprint of the same data between 32 and 64bit architectures.
It's not really opinable or up for discussion that it has nothing to do with the bus gates positioning or the memory's interface to the CPU, and anybody who's ever dealt with even rudimentary memory management can tell you all of this :)

[imashination]

Short version: 64bit apps and OS' use an insignificant amount of extra memory, their advantages massively outweigh any disadvantages.

[ThE_JacO]

Short version: 64bit apps and OS' use an insignificant amount of extra memory, their advantages massively outweigh any disadvantages.
Just to play devli's advocate: There can be exceptions to that, some notable :)

In the context of our field and the popular commercial apps, the difference is a lot smaller than the amount of additional RAM you can address.

From a non devil's advocacy point of view, there really isn't a reason to stick to 32bits and there wouldn't be even if all datasets constantly took twice the ram, since you can have a lot more than twice the ram per process in 64 than you'd have in 32.
I don't think that was really up for discussion though, except maybe by some crazy people ;p

[InfernalDarkness]

If you need a pointer, you need a pointer. If you're on 32bit, the pointer is 32bit big because that's the required amount of bits required to describe how to retrieve a block of memory. If you're on 64bit, the descriptor is twice as large.

While I agree with your general statement and position, I have to disagree with your math a bit here. You say the descriptor is twice as large, but we're talking about 32-bit vs. 64-bit, and so the memory addressing goes...

32-bit (2^32) = 4,294,967,296 (4 billion)

64-bit (2^64) = 18,446,744,073,709,551,616 (18 krillion or whatever)

So it's not twice as large, but literally 4,294,967,296 times as large. 2^64 / 2^32 = 2^32. But that's just the math behind the numbers.

I don't know (you probably do), but do the OS's cap the pointer length before the 64-bit length? Seems like I read that somewhere... For example, I don't believe OS 10 or Win7 have an upper memory limit which is 18 krillion or whatever. Just tossing out my ideas; I could be way off.

[imashination]

Computers are binary, 64bit is literally, exactly precisely twice as large as 32bit if you count in binary.

[InfernalDarkness]

Computers are binary, 64bit is literally, exactly precisely twice as large as 32bit if you count in binary.

Okay, I think I'm with you folks now.

So a 64-bit path would be twice as long... 64 0/1 "switches" in a row, as opposed to 32 0/1 switches.

The difference mathematically doesn't necessarily relate, then? Since the CPU is only dealing with 32 more switches? Kinda makes sense, if that's correct...

[ThE_JacO]

Okay, I think I'm with you folks now.

So a 64-bit path would be twice as long... 64 0/1 "switches" in a row, as opposed to 32 0/1 switches.

The difference mathematically doesn't necessarily relate, then? Since the CPU is only dealing with 32 more switches? Kinda makes sense, if that's correct...
The difference does relate, but not to the size.
The data is made of 32 or 64 bits (the number of binary state switches, you got that).
The numbers you mentioned are how many unsigned integers you can produce (reference) with a piece of data that is 32 or 64bit long. The space in memory of a pointer remains as big as the data, how much it can describe is irrelevant.
That is also the reason behind the difference in memory that can be addressed by the two different widths.

[Gurki]

It's no special proberty of a digital system. It's a proberty of a positional numeral system (Hindu-Arabic system).

Say you're planning a new street and need house numbers for your buildings. Take one decimal digit and you can build 10 buildings (No. 0 to No. 9), if you double the digits, you can create ten times more house numbers (0-99).

In contrast look at Roman numbers: I II III IV V VI VII VIII IX X XI XII etc. It's more of an additional system where length and value don't correlate.

Quite offtopic: the Romans where not very good at math, just because the system was a mess to do complex calculations. There is no usable, simple scheme to do addition/substraction or multiplication or even division with this number system.

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.