Poll: Primary D version

[retard]

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.