64-Bit - Explanation Please

Posted:
in Future Apple Hardware edited January 2014
I've been holding out on the purchase of a MBP for several reasons along with one that I don't fully understand, "64-bit". Not to sound like a greenhorn, but could someone fully explain 64-bit and it's advantages.



Thanks

Comments

  • Reply 1 of 13
    A 64 bit processor does operations (instructions) in groups of 64 bits rather than only 32 bits. This allows for a number of speed improvements.



    1. Instructions can make use of 32 bit constants without loading them into CPU registers first.



    2. Instructions can have beefier addressing. That is, one instruction can reference three, four, possibly five registers at once.



    3. The CPU itself can contain more registers because there is more addressing space in the instruction.



    4. The CPU can move twice as much data per clock cycle.



    Downsides: More memory (RAM, cache, etc) is needed since the instructions are twice as long. This is somewhat relieved by the fact that fewer instructions are required, and that techniques can be used to "compress" instruction data. The most prevalent example of this is the ARM, although the X86 does it too.



    At the end of the day, programs compiled for 64 bit will run a little faster on average. Memory intensive programs will run much faster.
  • Reply 2 of 13
    1. Wrong. On x86 they could do this already and on PPC 64-bit doesn't make that possible (due to all instructions being 32-bits with no room for a 32-bit constant).

    2. Wrong. The instruction size doesn't change and how many registers are used isn't affected.

    3. Wrong. PPC and x86 CPUs don't use the address space for register access. On the x86, however, they did actually increase the register counts but this was opportunistic not an inherent result of going to 64-bit.

    4. Wrong. The amount of data that can move per cycle is a function of the internal data paths of the processor, and this is independent of register size. It is true to say that the integer units in a 64-bit processor can move twice as much data per instruction, however.



    The instructions are not twice as long, the integer registers are. Slightly more memory is required because the size of pointers doubles, but this is generally less than a 5% increase.



    Performance is potentially derived from the ability to do 64-bit integer math in fewer instructions, but this only applies to applications which actually try to do this (it is fairly rare to need to). The x86-64 gains more speed from the larger architected register set, but again it is tough to determine exactly what the win here is. Probably fairly small, but varies between applications.



    The increased size of the address space is the biggest win from 64-bit for applications that need it. If your application needs more than 2-4 GB of memory you will see an improvement in performance (if you have that much physical RAM!). It also becomes possible to use sparse memory data structures for larger problems, and it is easier to implement applications that use >2-4 GB of virtual memory (i.e. you can rely on the OS to do your swapping rather than having to implement some kind of your own system).
  • Reply 3 of 13
    tony1tony1 Posts: 259member
    Thanks for the reply's. I think I've got it.



    So providing more space for additional RAM should be required, ideally, to get the full potential of the processor, correct?
  • Reply 4 of 13
    I don't really feel like getting into a jihad about this, but you're being too literal. I think you also missed the conditional part of my points 1-4, that is "the CPU [/i]can[/i] . . ." Your answers are essentially isolated to the x86, although I think arithmetic should be enough proof that a 32 bit CPU can't issue an instruction with a 32 bit immediate. I would agree that there's not a whole lot of use in branching 32bits, but the point is that it's not possible on a 32bit CPU unless it happens to have one instruction, that being subtract and branch if negative.



    The rest I don't care to harp on.
  • Reply 6 of 13
    jeffdmjeffdm Posts: 12,951member
    Quote:
    Originally Posted by Programmer




    Performance is potentially derived from the ability to do 64-bit integer math in fewer instructions, but this only applies to applications which actually try to do this (it is fairly rare to need to). The x86-64 gains more speed from the larger architected register set, but again it is tough to determine exactly what the win here is. Probably fairly small, but varies between applications.



    It may depend on the app but sometimes the difference is dramatic.



    I've seen a test of an MP3 encoder in Linux that showed something like a 60% speed increase just by recompiling it to x86-64. I don't think it is too much to suggest that you can get decent speedups with other codecs, though maybe not by that much..
  • Reply 7 of 13
    Here's an interesting bit of history for anyone who remembers about 6-7 yrs ago when the G4 was introduced..remember Apple saying that the G4 was the first "supercomputer" and it processed 128 bit data chunks or whatever... what was the deal with that? Can anyone explain that to me?
  • Reply 8 of 13
    marcukmarcuk Posts: 4,442member
    Quote:
    Originally Posted by hypoluxa


    Here's an interesting bit of history for anyone who remembers about 6-7 yrs ago when the G4 was introduced..remember Apple saying that the G4 was the first "supercomputer" and it processed 128 bit data chunks or whatever... what was the deal with that? Can anyone explain that to me?



    It processed 4 chunks of 32 bit data at a time.
  • Reply 9 of 13
    chuckerchucker Posts: 5,089member
    That was for AltiVec, which is 128-bit. This can only be used for specifically-written mathematical operations.



    Intel has a similar unit with MMX and now SSE.
  • Reply 10 of 13
    Quote:
    Originally Posted by Chucker


    That was for AltiVec, which is 128-bit. This can only be used for specifically-written mathematical operations.



    Intel has a similar unit with MMX and now SSE.



    what does MMX and SSE stand for?
  • Reply 11 of 13
    jeffdmjeffdm Posts: 12,951member
    Quote:
    Originally Posted by hypoluxa


    what does MMX and SSE stand for?



    Multi Media eXtensions and Streaming SIMD Extensions. SIMD is Single Instruction Multiple Data.



    Both are Intel instructions that are pretty similar in function to AltiVec.
  • Reply 12 of 13
    Quote:
    Originally Posted by hypoluxa


    Here's an interesting bit of history for anyone who remembers about 6-7 yrs ago when the G4 was introduced..remember Apple saying that the G4 was the first "supercomputer" and it processed 128 bit data chunks or whatever... what was the deal with that? Can anyone explain that to me?



    That really just arose because the first G4 was the first consumer level machine to crack the 1 GFLOPS level which used the US Government standard for determining if a machine should be classified as a supercomputer for export restriction purposes. The US has rules about whether you can export machines powerful enough to use them in weapons development. Rather silly nowadays given the computational power available everywhere.



    My favourite was the commercial with the tanks.









    PS: Now teraflop level isn't that far away, with things like GPUs and Cell processors becoming available.
  • Reply 13 of 13
    Quote:
    Originally Posted by Splinemodel


    I don't really feel like getting into a jihad about this, but you're being too literal. I think you also missed the conditional part of my points 1-4, that is "the CPU [/i]can[/i] . . ."



    ???



    My answers were not particluarly literal, they were accurate. And they are not x86-specific, they mention PPC several times. And they were correcting your statements where you said "can do this" but they can't, or "can do this" but so can 32-bit processors.



    Quote:

    Your answers are essentially isolated to the x86, although I think arithmetic should be enough proof that a 32 bit CPU can't issue an instruction with a 32 bit immediate. I would agree that there's not a whole lot of use in branching 32bits, but the point is that it's not possible on a 32bit CPU unless it happens to have one instruction, that being subtract and branch if negative.



    As I said, on PPC 32-bit processors cannot load 32-bit immediates... but neither can 64-bit PPC processors. The reason for this is that all PPC instructions are 32 bits in size and therefore cannot hold encoding information plus more than a 16-bit immediate. On x86 processors the instructions vary in size depending on the instruction and the encoding mode so 32-bit immediates are possible (and if I recall they do actually exist). I'm not actually sure if they extended the ISA to support 64-bit immediates in x86-64. I'll let somebody else look that up if anyone cares.



    Quote:

    The rest I don't care to harp on.



    Ah, so you know you're wrong and thus don't want to talk about it any more. Fair enough, I just want to correct misinformation.
Sign In or Register to comment.