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?"
Is this really a problem in the embedded space?
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Huh? On systems where RAM is at a premium, I don't see the point of using or having 64-bit pointers.
"Send an Instant Karma to me" - Yes
every object(which is everything apart from your basic int & etc) is a reference, which pretty much is a pointer with a fancy name. as to handling 4gbytes I really don't see why it couldn't, it's just a matter of the vm supporting it anyways(afaik the design, nor the bytecode, limits it).
however, can you think of any system where you had objects, sets of data, and they weren't (at least underneath) pointers to memory?
and as to the original subject one poster already said it best: if you really have the need for that extra effort of going 64bit pointers you will probably have the memory to spare, no? anyways it will only be a problem if if the the pointers are big enough in comparision to what they're pointing to.. in which case you should rethink what you're doing anyways probably if you care a squat about memory footprint.. bringing the embedded devices to the discussion at this point is totally pointless but of course cool sounding and slashdot editor catchy.
bleh I'm no expert anyways.
world was created 5 seconds before this post as it is.
By the way, the limit was from physical slots - 8 and a 2GByte DIMM memory limit, increase either of those and guess what.
Now each "process" on our box could only address 4 Gbyte of that memory, but that was a completely different question (and in fact limited by the libraries that were used - again a different story)
I remember these conversations when the 32 bit world came around - what do you mean I have to put 4 bytes into the processor. End result is that the code is a little larger, and a little slower - and Moore's law marches on and we don't even notice
I have mod points and I am not afraid to use them
Does anyone use 64 bit processors for embedded applications?
There's an interesting discussion of 64-bit immediate values at the following link: 64 bit immediates in Python
If we are already using 64 bits for our pointers, a virtual machine has the potential of exploiting a the pointer's larger footprint for other immediate values. I'm not as crazy about using the MSB of the pointer for indicating an immediate as Ian Bicking appears to be, I'd recommend using the LSB since it's easier to bias any object to an even address than halve the potential addressable space.
Then again, if the potential address space is 2 ** 64, I suppose it's not such a sacrifice.
Weapons of Mass Analysis
The truth of the matter is that your everyday user just has no need to handle numbers of that size or data of those quantities.
Now where have we heard that before...
=Smidge=
Then you whine about using an extra 4 bytes per pointer to address it. Seems to me that the number of pointers relative to the amount of RAM is so small it's not an issue. Correct me if I'm wrong.
"Eve of Destruction", it's not just for old hippies anymore...
Parent has interesting point, but it doesn't address the cache issue. 64-bit pointers will take twice as much space as 32-bit pointers. In a jump table situation, for instance, a 128-byte cache line (picking a reasonable number) could only hold 16 pointers instead of 32. Of course, as was also mentioned, when you have hardware that is designed to address more than 4 GB of memory, the amount of cache and main memory available is usually scaled up accordingly to deal with it. Bigger processor, bigger cache, more RAM, Moore's Law marches on.
So, basically, don't worry about it... it's the price of progress. Unless you're running a 64-bit platform on a pitifully small amount of RAM.
Two of the three projects using embedded devices that I wrote the code for used 4 bit processors. The third used an 8 bit processor. There are still many millions of 4 and 8-bit processors being designed into products. You can't even order a mask for said parts (the vendor won't even answer the phone, or often times even provide the emulator and tools) if you're not talking 500K+ quantities.
---
wha??? Any linkage to back this up?
If you'd pay proper attention to Sun's marketing machine, you'd remember that Java uses a just-in-time compiler. What does a compiler do? It turns all of your "object-oriented is the only valid programming paradigm" source code into a big bucket of CPU-specific opcodes, numbers and *pointers*.
In fact, it will probably have more pointers than the corresponding C or C++ program would have, due to the plethora of tiny objects you're encouraged to spawn. Naturally, the pointer size would match the CPU architecture on which the program is being run and would consume a corresponding number of cache bytes.
Now, this kind of stuff might be useful for...um...hard-core video editing...and really, really huge servers, but that's about it. The truth of the matter is that your everyday user just has no need to handle numbers of that size or data of those quantities.
What happens when "your everyday user" wants to perform "hard-core video editing" on footage she shot of her family with her miniDV camcorder?
I concur with your findings. Back in the days I was experiencing a little disconfort with the speed of my Pentium 90 running linux, I decided to buy a Digital Alpha system 266 MHz. Both systems were configured with 64 MB, and both ran Red Hat 5.2.
Although the Alpha system is obviously superior in number crunching, I noticed it ran out of physical memory on a regular basis where my P90 whould still be happy. Part of the matter it that alpha binaries tended to be much larger, as was the kernel. But I'm also quite sure that a major part is primarily due to the increased amount of "lost" bits in pointers and memory alignments of small data structures.
--
The problem with engineers is that they tend to cheat in order to get results. The problem with mathematicians is that they tend to work on toy problems in order to get results. The problem with program verifiers is that they tend to cheat at toy problems in order to get results.