4 ms·

> 64-bit software, a geeky term that, for now, pretty much means “faster.” Ouch. In general there's way too much fanboyishness in this article. I mean, serio

by wheels 17y ago

> 64-bit software, a geeky term that, for now, pretty much means “faster.” Ouch. In general there's way too much fanboyishness in this article. I mean, seriously, it closes on a note of, "You can't see any improvements so JUST IMAGINE how much they've done under the hood!"

brandnewlow 17y ago
Can someone explain what it does mean? Every time I download a Windows update and it asks me to pick from one of 10 options to download, I get angry. How am I supposed to know what bit of Windows I'm using?
- wheels 17y ago
  What 64-bit means? This is a good start: http://en.wikipedia.org/wiki/64-bit#Architectural_implications http://en.wikipedia.org/wiki/64-bit#Architectural_implicatio... The most obvious improvement is that 64-bit programs can address more memory -- more than 4 gigabytes of virtual memory in the same process. The less obvious bit that sometimes makes things faster is that when an x86_64 CPU is running in 64-bit mode it has access to more registers (basically the ultra-mega-low-latency memory for numbers and memory addresses and stuff that everything computed must pass through). However, since pointers to blocks of memory are twice as large on 64-bit programs and many programs use lots of them, 64-bit programs usually use more memory, which means that there are more cache (the slightly less, but still ultra-low-latency memory that's between the registers and usual memory) "misses" -- i.e. things have to be grabbed more often from main memory, which relative to registers and cache is slow ... meaning that it eats some of the performance benefits of the extra registers. In a nutshell, 64-bit programs are different. They're not "faster". The difference in bit-width really isn't something that makes a lot of sense if you don't know how CPUs work and can't be reduced to "faster".
bbb 17y ago
x86_64 == more registers available than on i386 more registers == fewer spills For the average compiled program, fewer spills == faster. => Average programs run faster under x86_64.
- litewulf 17y ago
  I believe in practice register renaming (http://en.wikipedia.org/wiki/Register_renaming http://en.wikipedia.org/wiki/Register_renaming) largely negates the difference in performance. Notice the mention of some CPUs having MORE registers than are nameable in the instruction set. I am not a hardware engineer though, so YMMV.
- axod 17y ago
  And use about twice as much Ram. Personally I think 8 bytes for every single pointer seems wasteful for most programs.
  - jrockway 17y ago
    4 extra bytes for a pointer is wasteful, but having an entire separate vector CPU just to make the windows transparent isn't?
    - axod 17y ago
      Depends on what your bottleneck is. For me, it's usually been memory rather than CPU. I was using 64bit, then switched to 32bit and saw a gigantic improvement in mem usage. (See slicehost vs linode comparisons etc)
      - chancho 17y ago
        Your argument refutes itself handedly because 32bit processes are limited to 4GB of address space. You've maxed out 1Gb now, how long before you max out 4Gb? Memory concerns are clearly the reason to go 64bit, the stuff about registers is icing on the cake. Look at the big picture, whether it be pointers or integers into an array: the size of the index grows with the log of the number of things being indexed. You can't avoid this growth, but it matters less and less as you grow.
  - gjm11 17y ago
    Evidence that it's really "about twice as much"? Much of what any given program stores will be things other than pointers. According to http://www.springerlink.com/content/h6803610u1124354/ http://www.springerlink.com/content/h6803610u1124354/ (actual article is behind a paywall; but the information I'm referring to is on the first page, which is shown) the typical increase in size for Java objects is 40%. I strongly suspect that most programs that use a lot of memory (which are the ones that matter) do so because they have big wodges of non-pointer data (long strings, images, matrices, ...) and therefore get a smaller-than-average size increase, but I have no actual evidence for this. Anyway, you'd only get a 2x increase if every single byte of memory used by your program were either a pointer or an integer that changed from 32 to 64 bits on switching to 64-bit code (e.g., a long in C or C++, for gcc at least). That's gotta be far from the truth.

by wheels 17y ago

brandnewlow 17y ago

Can someone explain what it does mean? Every time I download a Windows update and it asks me to pick from one of 10 options to download, I get angry. How am I supposed to know what bit of Windows I'm using?

wheels 17y ago
What 64-bit means? This is a good start: http://en.wikipedia.org/wiki/64-bit#Architectural_implications http://en.wikipedia.org/wiki/64-bit#Architectural_implicatio... The most obvious improvement is that 64-bit programs can address more memory -- more than 4 gigabytes of virtual memory in the same process. The less obvious bit that sometimes makes things faster is that when an x86_64 CPU is running in 64-bit mode it has access to more registers (basically the ultra-mega-low-latency memory for numbers and memory addresses and stuff that everything computed must pass through). However, since pointers to blocks of memory are twice as large on 64-bit programs and many programs use lots of them, 64-bit programs usually use more memory, which means that there are more cache (the slightly less, but still ultra-low-latency memory that's between the registers and usual memory) "misses" -- i.e. things have to be grabbed more often from main memory, which relative to registers and cache is slow ... meaning that it eats some of the performance benefits of the extra registers. In a nutshell, 64-bit programs are different. They're not "faster". The difference in bit-width really isn't something that makes a lot of sense if you don't know how CPUs work and can't be reduced to "faster".

bbb 17y ago

x86_64 == more registers available than on i386 more registers == fewer spills For the average compiled program, fewer spills == faster. => Average programs run faster under x86_64.

litewulf 17y ago
I believe in practice register renaming (http://en.wikipedia.org/wiki/Register_renaming http://en.wikipedia.org/wiki/Register_renaming) largely negates the difference in performance. Notice the mention of some CPUs having MORE registers than are nameable in the instruction set. I am not a hardware engineer though, so YMMV.
axod 17y ago
And use about twice as much Ram. Personally I think 8 bytes for every single pointer seems wasteful for most programs.
- jrockway 17y ago
  4 extra bytes for a pointer is wasteful, but having an entire separate vector CPU just to make the windows transparent isn't?
  - axod 17y ago
    Depends on what your bottleneck is. For me, it's usually been memory rather than CPU. I was using 64bit, then switched to 32bit and saw a gigantic improvement in mem usage. (See slicehost vs linode comparisons etc)
    - chancho 17y ago
      Your argument refutes itself handedly because 32bit processes are limited to 4GB of address space. You've maxed out 1Gb now, how long before you max out 4Gb? Memory concerns are clearly the reason to go 64bit, the stuff about registers is icing on the cake. Look at the big picture, whether it be pointers or integers into an array: the size of the index grows with the log of the number of things being indexed. You can't avoid this growth, but it matters less and less as you grow.
- gjm11 17y ago
  Evidence that it's really "about twice as much"? Much of what any given program stores will be things other than pointers. According to http://www.springerlink.com/content/h6803610u1124354/ http://www.springerlink.com/content/h6803610u1124354/ (actual article is behind a paywall; but the information I'm referring to is on the first page, which is shown) the typical increase in size for Java objects is 40%. I strongly suspect that most programs that use a lot of memory (which are the ones that matter) do so because they have big wodges of non-pointer data (long strings, images, matrices, ...) and therefore get a smaller-than-average size increase, but I have no actual evidence for this. Anyway, you'd only get a 2x increase if every single byte of memory used by your program were either a pointer or an integer that changed from 32 to 64 bits on switching to 64-bit code (e.g., a long in C or C++, for gcc at least). That's gotta be far from the truth.