3 ms·

Heap growth moving from 32b to 64b is rarely on the order of 50-100% larger. 20-30% is much more common (100% would imply that your application stores no actua

Heap growth moving from 32b to 64b is rarely on the order of 50-100% larger. 20-30% is much more common (100% would imply that your application stores no actual data, only pointers and sizes; I know that pointer-chasing is very much in style these days, but that's ridiculous. Even the 1:1 ratio implied by a 50% figure is an extreme outlier). Further, raw heap size typically has marginal impact on performance; locality of reference and size of working set are far more important. It doesn't matter if your raw heap usage grows by 30% if the majority of your accesses are to the same working set of data either way. At the same time, a well-crafted interpreter or JIT (which people seem to think is important in browsers) benefits heavily from increasing the size of the register set. Even in more typical use cases, even without aggressive optimization, speedups of 10-20% are common in moving from x86 to x86_64.

kevingadd 14y ago
You can tell me what your think the behavior is actually like, but I can point you to a HTML5 game that uses 50-100% more JS heap and runs slower in 64-bit builds of Firefox :) You say a larger heap has marginal impact on performance and that locality and working set size are what matter. If larger pointers make the heap bigger, then the working set is going to grow as well, and locality will be worse because the larger pointers mean less objects fit into a cache line.
- stephencanon 14y ago
  I'm not saying 50-100% growth doesn't happen, I'm saying that it's an outlier (based on complete system data from multiple platforms). If it's really a common issue with firefox's JS implementation for some reason, there's nothing to stop them from using a compressed pointer scheme for JS that uses 32b pointers and a known offset; it's a common technique. You give up one register to keep the offset around, but you've still netted 7 registers from the switch to the 64b ISA, and adding the offset is either a simple OR or can be folded into an LEA (nearly free or free). Let's not confuse "they haven't had a chance to tune the 64b JS engine, and the 32b one has been worked on for years" with "x86_64 is slower than x86_32".
  - nuje 14y ago
    Is your "complete system data from multiple platforms" from JS apps? Let's also not confuse "a sufficiently smart compiler..." with real-world observed performance :) BTW data layout transformations like compressed fields would also be useful on 32-bit. The vast majority of object graphs would be happy with 16 or even 8-bit identifiers, not to mention JS numbers which are all 64-bit floats even on 32-bit platforms.
    - Dylan16807 14y ago
      Let's also not confuse differences caused by 32 bit engines having more developers with differences caused by the platform.
- brigade 14y ago
  Please don't assert logical fallacies as the truth. "x86-64 is slower because pointers are larger" does not follow from "Firefox's JavaScript engine is slower and uses more memory on x86-64"
  - kevingadd 14y ago
    I never said anything of the sort. Maybe read my posts before replying to them?

kevingadd 14y ago

You can tell me what your think the behavior is actually like, but I can point you to a HTML5 game that uses 50-100% more JS heap and runs slower in 64-bit builds of Firefox :) You say a larger heap has marginal impact on performance and that locality and working set size are what matter. If larger pointers make the heap bigger, then the working set is going to grow as well, and locality will be worse because the larger pointers mean less objects fit into a cache line.

stephencanon 14y ago
I'm not saying 50-100% growth doesn't happen, I'm saying that it's an outlier (based on complete system data from multiple platforms). If it's really a common issue with firefox's JS implementation for some reason, there's nothing to stop them from using a compressed pointer scheme for JS that uses 32b pointers and a known offset; it's a common technique. You give up one register to keep the offset around, but you've still netted 7 registers from the switch to the 64b ISA, and adding the offset is either a simple OR or can be folded into an LEA (nearly free or free). Let's not confuse "they haven't had a chance to tune the 64b JS engine, and the 32b one has been worked on for years" with "x86_64 is slower than x86_32".
- nuje 14y ago
  Is your "complete system data from multiple platforms" from JS apps? Let's also not confuse "a sufficiently smart compiler..." with real-world observed performance :) BTW data layout transformations like compressed fields would also be useful on 32-bit. The vast majority of object graphs would be happy with 16 or even 8-bit identifiers, not to mention JS numbers which are all 64-bit floats even on 32-bit platforms.
  - Dylan16807 14y ago
    Let's also not confuse differences caused by 32 bit engines having more developers with differences caused by the platform.
brigade 14y ago
Please don't assert logical fallacies as the truth. "x86-64 is slower because pointers are larger" does not follow from "Firefox's JavaScript engine is slower and uses more memory on x86-64"
- kevingadd 14y ago
  I never said anything of the sort. Maybe read my posts before replying to them?