Hi all,
I wondered last question on Frodo. There is a 32-bit and 64-bit.
What are the advantages of 32 and 64?
Why choose one or the other?
Are there any drawbacks?
Thank you for your feedback.
one is 2x the bits of the other
That's like choosing gasoline for the car... If the engine supports the higher octane, you should take it...
In theory it should be faster and have more access to RAM (among other things). I actually haven't noticed any performance difference yet, but I doubt I've pushed XBMC to "the limits". Meh.
OK.
So there is not much interest to choose 64bits
In general and for the personal use 64bit seems to be a marketing ploy.
Anyway the 64bit version does not give me a better picture!
Well, in the long term it will likely be useful or even required. It's just that XBMC is fairly efficient in various things that it does, so it doesn't need to use the full power of your computer to do those things. In the future it might be useful if there are really demanding video codecs that are being software decoded, or maybe someone will make some really demanding skin that does some crazy/demanding stuff for the CPU.
yes I understand.
If XBMC eventually evolves to be, for example, a video scaller it will take 64bit
64 bit, on desktop, refers to how much address space an application can use. Generally, it does not make much difference.
Pardon me, but it's more than just address space that effected by using a 64-bit application. The CPU instructions are also capable of using full 64-bit registers. Otherwise, address space over a 32-bit range would never be reachable. Instructions that perform block moves of memory will also likely use 64-bit transfers, making them marginally more efficient compared to a 32-bit version of the same move.
When compiling programs, especially in C/C++, compiling for 64-bit makes the "int" variable type default to a 64-bit range rather than 32-bit. This often results in the same program using more memory to store is internal data (aka variables), unless expressly written to use a shorter size. Case in point, I saw a roughly 50% increase in addon memory use when I switched from the 32-bit World of Warcraft client to the 64-bit client. The application still made no effort to use any addition code space that was otherwise unavailable to 32-bit mode.
End result is that 64-bit will allow for a larger address space, but that isn't the sole purpose of compiling for 64-bit.
You are oh, so wrong with OSX, apps already use 64 bit registers for computation. it's mainly address space. Instructions that perform block moves of memory also don't use general purpose CPU registers, they use SSE registers as these are much, much wider in length.
I'm a seasoned Darwin dev, and have been programming in high and low level code for probably longer than you have lived on this earth so I think I have a clue what's going on.
@
davilla
So, let me see if I'm following you. You're saying that the 4GB of address space for a 32-bit app wasn't large enough for XBMC to function properly, so a 64-bit version is compiled only to open up more address space while still using the exact same instruction code as the 32-bit version? Note: I don't mean source code that gets compiled. I mean the literal instruction code used by the CPU.
As I recall, even the 80386 couldn't use it's 32-bit registers without being put in 32-bit mode while running DOS. While in 16-bit mode, a pair of registers were used (a segment:offset pair, which technically overlapped to form a 20-bit address range) to address more memory than the 16-bit registers could directly point to (0-65535 is the 16-bit limit, of course). Somehow, I just don't see Intel or AMD changing the rules on register size when 64-bit support was added. Let's not forget that additional instructions are enabled when the CPU is put into higher modes of operation. So, I was dare say that OSX apps, if compiled for 32-bit, are not enabling 64-bit mode, thus they simply cannot be using 64-bit hardware registers/instructions. Technically instructions might be the same with a different operand size prefix added, just like in the 16/32 days. Back then, no prefix was a 16-bit operand, and a prefix was available in 32-bit mode to enable a 32-bit operand (16-bit register access was still available in 32-bit mode).
Just FYI, it doesn't take much digging to know how old I am. Any log that I've posted was done via my personal server (my personal domain name, even if GoDaddy is being stupid about that). Before guessing my age and risking being wrong, you could have looked at my about page and known how old I am (and more). To save you from the apparent burden of looking something up, I'm 42. Are you an older developer? Possible, but that sort of comment is usually used by someone with very little fact to back them up.
To sum up: Yes, more address is available, but that is only 1 aspect of difference between 32-bit and 64-bit modes.
Oh, and I'm assuming that OSX compiles are specifically enabling and selecting a version of SIMD instructions to use. With various SIMD versions available (2 MMX versions, 2 3DNow! versions, and at least 4 SSE versions), it is simply wrong to assume that any specific version is automatically being used, assuming that any are being used at all. The assumption of SSE being used is potentially correct, but not necessarily correct.
Clearly, the only way to settle this is with a dance-off.
