Slashdot Mirror
Effect of Using 64-bit Pointers?
An anonymous reader queries: "Most 64-bit processors provide a 32-bit mode for compatibility, but 64-bit pointers are becoming essential as systems move beyond 4GB of RAM. Also, the large virtual address space is very useful for several reasons - allowing large files to be memory-mapped, and allowing pages of memory to be remapped without ever requiring the virtual address space to be defragmented. However, 64-bit pointers take up twice as much memory, which immediately affects memory footprint. This is especially an issue on embedded platforms where RAM is at a premium, but even on systems where RAM is plentiful and cheap the extra memory footprint reduces cache performance. Have Slashdot readers done any research into the actual effect of using 64-bit pointers in a 'typical' application? What proportion of a real program's data is actually pointers?"
It's not that 32bit processors are a problem, it's that their virtual address space is not very big. 64bit processors can mmap anything you want, even block devices >> a few terabytes. (So if the HURD ever gets ported to AMD64, they can support filesystems > 2GiB, which they don't last I checked because they mmap the device, and the HURD only runs on i386!)
Being able to mmap anything you want is something you just plain can't do on a 32bit CPU. If you want to write programs that don't worry about address space limitations, you need 64bit. Anything that simplifies programming is good, since programmer time is valuable.
Besides that, even if you have 1GB of RAM on i386, Linux needs highmem support to use it all. (It reserves 3GB of virtual address space for user space, and the kernel maps as much RAM as it can with the address space that's left over after mapping PCI and AGP space. So 64bit is useful even on good desktop machines right now. (using highmem slows the kernel down, so might not even be worth it to map the last ~100MiB if you have 1GiB installed.)
Stupid crap like highmem is exactly why we should be using 64bit CPUs.
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes ,
There's a lot of modern medical equipment which can definitely use the 4GB. MRI machines, CT scanners, ultrasound machines ("sonographs" if you prefer the term) and so on do tend to chew up memory. Particularly the first two, because you often need to hold whole voxel sets in memory while you compute a bunch of cross-sections at odd angles.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Java does not care about memory limits, the JVM does. The stock Sun JVM for x86 machines will address a maximum of 3-4 GiB (dependent on operating system). However, the IBM JVM on an AIX machine has no practical limit and can easily access >16 GiB memory, if available. If a JVM is so designed, there is no reason a Java program can access as much memory as a program written in C.
I run very large simulations on various platforms, and some of my simulations have to be run on a 64-bit machine because of the memory requirements. Sun's Java forums have several posts asking for various maximum heap (maximum memory accessable) for various platforms and you can find more exact numbers for specific platforms and operating systems there.
An object is an object, not a pointer. However, objects are accessed through a reference, which in implementation, is typically a pointer.