Poll: Primary D version

retard re at tard.com.invalid
Sat May 22 14:46:00 PDT 2010

Sat, 22 May 2010 16:23:35 -0500, Andrei Alexandrescu wrote:

> On 05/22/2010 02:38 PM, retard wrote:
>> Sat, 22 May 2010 15:28:54 -0400, Adam Ruppe wrote:
>>> On 5/22/10, retard<re at tard.com.invalid>  wrote:
>>>> On a 4 GB system you lose 600+ MB of memory when using a 32-bit
>>>> operating system without PAE support.
>>> You can run 32 bit programs on a 64 bit operating system. The point
>>> isn't that 64 bits is useless in general, it is just that most
>>> *applications* work just fine as 32 bit binaries.
>> I can't believe the 64-bit processes are twice as large. Typically the
>> binary size is only a fraction of the amount of data processed by the
>> application. Moreover, most of the memory allocations contain array
>> like structures for storing bitmaps, I/O buffers etc. For example, if
>> you're storing 8-bit pixels in a game, you're not forced to use int64
>> data type on a 64-bit architecture.
> It all depends on what the largest payload is. One of my apps' largest
> structures was a hash, which was almost twice as large in the 64-bit
> version.

Ah, good to know. I haven't really seen many comparisons of 32-bit code 
vs 64-bit code. Haven't researched to topic much, either. But it makes 
sense when the payload is small vs the size of the pointer. I think some 
VMs deal with the issue by compressing pointers ( http://wikis.sun.com/
display/HotSpotInternals/CompressedOops ). In JVM, the maximum size of 
compressed pointer heap is only 32 GB, though, so we need to invent 
something new for desktop systems in 2020.

More information about the Digitalmars-d mailing list