It is so. "64 but" refers to the size of the CPU's registers... Specifically the general purpose ones used to do integer math. To store a 64bit value takes, no surprises, 64 bits... twice as much as it takes to store a 32bit value. Thus twice the memory is used to store any given register value.
It has nothing to do with single or multiple channel... It's about how much space it takes to store a given numerical value from a CPU register.
Oh, my head.... no no no no NO. I think I see what you're trying to say, 2Tired, but...no.
For clarification, 64-bit (in the terms of OS) refers to WORD sizes. A word is the largest (actually, optimal) chunk of data that a CPU can process at once. We use words for all sorts of things - instructions, registers, math, pointers...funny enough, a 64b OS doesn't even truly use much 64b code.
A 64b processor is capable of processing words of 64b length, manipulating them, and sending them to up to 64b of different memory addresses. THIS is the ONLY thing that impacts memory usage - the "page file" of memory addresses is larger and POINTERS are therefore larger - so lines of code that are jumps and routines take up a bit more space. Most of our processors aren't even TRUE 64b - they are 64b data width but still must be able to use 32b instructions to comply with the x86 instruction set. The Itanium is the only intel processor that's properly 64b all the way through, and it does not use x86 assembly at all.
This is part of why 64b OS doesn't use a lot of 64b code - why take up more space when you can instead send two 32b instructions through simultaneously? So code is reorganized a bit to be more efficient, but since the processors still support 32b instructions, there's no sense in padding an "add" or "mov" to take up double the space. That's just silly. Again, that's not universal - there ARE a few 64b instructions, but they really aren't implemented nearly as much as being able to process two 32b instructions instead.
Please note that this doesn't actually change how the numbers are stored, or how much use all of the code that ISN'T a specific pointer takes up. There are a few instructions that can be processed in one go instead of two, and a few others that ONLY 64b processors understand, but otherwise, as far as memory usage, there's NO difference. A 32b processor still can work with larger DATA (not instruction) words, it just breaks them up into chunks.
Also, since someone mentioned it, to further clarify, BUS WIDTH (32, 64, 128) refers to how much data can pass through from point A (RAM, NB, CPU, etc) to point B in one clock cycle. A 64b chip receiving a 64b word over a 32b bus actually has to wait every other cycle until it has the full instruction. This is why the "channels" of RAM, along with the motherboard chipset's throughput, matter. There's a lot of muddier topics here but this is the really simplistic explanation. Bus width != pipeline width != "channels" != storage size. All of these are different concepts that interact, but are different.
So, long story short = 8GB of RAM to a 64b OS is NOT the same as 4GB of RAM to a 32b OS. Just because pointers now take up 64b doesn't mean anything else does - that would violate the x86 instruction set and no longer be "proper" for consumer applications. A 64b OS DOES take up a bit more ram, but not THAT much...only as much as the pagefile and pointers divided by two.
Hope that helps clarify some things for anyone who reads this thread later...