4 ms·

> there really shouldn't be any need to run 32bit builds on a 64bit system Maybe the 64-bit version doesn't support the Adobe Flash plugin? The another probl

by acqq 11y ago

> there really shouldn't be any need to run 32bit builds on a 64bit system Maybe the 64-bit version doesn't support the Adobe Flash plugin? The another problem with 64-bit versions is that all the pointers are twice as big. So if you have only 8 GB of physical ram, you won't necessarily be able to handle much more than with a 32-bit application. But with 16 GB or more the 64-bit version must be better.

the8472 11y ago
> Maybe the 64-bit version doesn't support the Adobe Flash plugin? 64bit flash works for me. > The another problem with 64-bit versions is that all the pointers are twice as big. You're assuming pointers dominate the footprint. if you're seeing crashes due to address space exhaustion that's more likely due to large strings/blobs of data and not a huge amount of pointers. Or to put it differently, do you really think OOM crashes are preferable to some background applications or memory-mapped files being paged out?
- acqq 11y ago
  > You're assuming pointers dominate the footprint. No, I just wrote: >> if you have only 8 GB of physical ram, you won't necessarily be able to handle much more than with a 32-bit application That means, I absolutely know applications that won't be better on a 8 GB RAM computer as 64-bit applications, and they were written using standard C++ libraries. Typically, such applications weren't optimized for cases when they use a lot of memory. If somebody competent spends enough time and energy, even such application can be made to use memory better but it's not something that "just happens." And sometimes 32-bits application is a good trade-off. See for example https://blogs.msdn.microsoft.com/ricom/2009/06/10/visual-studio-why-is-there-no-64-bit-version-yet/ https://blogs.msdn.microsoft.com/ricom/2009/06/10/visual-stu... "A 64 bit address space for the process isn’t going to help you with page faults except in maybe indirect ways, and it will definitely hurt you in direct ways because your data is bigger." What I'm trying to suggest is that the topic is more nuanced as "64 doublegood 32."
brianwawok 11y ago
I don't think all pointers are twice as big. How does Java do compressed OOPS?
- alblue 11y ago
  Java has a couple of different options for dealing with objects but is able to manage the full set of pointers and know that (for example) code doesn't try to access memory+1 for looping etc. Under 4G worth of size pointers are simply zero extended, so that the higher order bits are just zero and the lower order bits stores in 32 bits. Above 4G but below 32G it switches to "compressed oops" mode. This right-shifts the address by 3 bits and ensures/mandates that all objects are aligned to 8 bits (2^3). When converting back again to a memory address it multiplies by 8. This effectively multiplies the top address space by a factor of 8 and so you can store an object in the same 32 bits but can be wider. It's possible to shift the alignment (-XX:ObjectAlignmentInBytes=16) which will then right shift the address by 4 instead giving you 64Gb memory with 32 bit addressing. Although it's possible to go higher the advantages tend to scale out; effectively you end up padding the object space more and more so simple objects take up larger and larger slots. The bottom line is: by controlling where pointers are used, Java can use a different addressing scheme by unpacking and repacking object pointers on the fly. And for some operations (equality testing) it doesn't even need to unpack the pointers in the first place.

by acqq 11y ago

the8472 11y ago

> Maybe the 64-bit version doesn't support the Adobe Flash plugin? 64bit flash works for me. > The another problem with 64-bit versions is that all the pointers are twice as big. You're assuming pointers dominate the footprint. if you're seeing crashes due to address space exhaustion that's more likely due to large strings/blobs of data and not a huge amount of pointers. Or to put it differently, do you really think OOM crashes are preferable to some background applications or memory-mapped files being paged out?

acqq 11y ago
> You're assuming pointers dominate the footprint. No, I just wrote: >> if you have only 8 GB of physical ram, you won't necessarily be able to handle much more than with a 32-bit application That means, I absolutely know applications that won't be better on a 8 GB RAM computer as 64-bit applications, and they were written using standard C++ libraries. Typically, such applications weren't optimized for cases when they use a lot of memory. If somebody competent spends enough time and energy, even such application can be made to use memory better but it's not something that "just happens." And sometimes 32-bits application is a good trade-off. See for example https://blogs.msdn.microsoft.com/ricom/2009/06/10/visual-studio-why-is-there-no-64-bit-version-yet/ https://blogs.msdn.microsoft.com/ricom/2009/06/10/visual-stu... "A 64 bit address space for the process isn’t going to help you with page faults except in maybe indirect ways, and it will definitely hurt you in direct ways because your data is bigger." What I'm trying to suggest is that the topic is more nuanced as "64 doublegood 32."

brianwawok 11y ago

I don't think all pointers are twice as big. How does Java do compressed OOPS?

alblue 11y ago
Java has a couple of different options for dealing with objects but is able to manage the full set of pointers and know that (for example) code doesn't try to access memory+1 for looping etc. Under 4G worth of size pointers are simply zero extended, so that the higher order bits are just zero and the lower order bits stores in 32 bits. Above 4G but below 32G it switches to "compressed oops" mode. This right-shifts the address by 3 bits and ensures/mandates that all objects are aligned to 8 bits (2^3). When converting back again to a memory address it multiplies by 8. This effectively multiplies the top address space by a factor of 8 and so you can store an object in the same 32 bits but can be wider. It's possible to shift the alignment (-XX:ObjectAlignmentInBytes=16) which will then right shift the address by 4 instead giving you 64Gb memory with 32 bit addressing. Although it's possible to go higher the advantages tend to scale out; effectively you end up padding the object space more and more so simple objects take up larger and larger slots. The bottom line is: by controlling where pointers are used, Java can use a different addressing scheme by unpacking and repacking object pointers on the fly. And for some operations (equality testing) it doesn't even need to unpack the pointers in the first place.