[arch-general] A question about Arch Sixty Four

[Adriano Moura]

Need to revise my text next time. Hope it's legible.

2010/5/25 Adriano Moura <adriano.lols at gmail.com>:
> This is actually normal. 64 bits systems uses 64bits per memory
> address, by default.
>
> That alone would make 64bits systems eat twice as much memory than a
> 32bit systems. Of course you can program can be coded to use 32bit
> variables, but hey, isn't the larger number representation one of the
> 64bits advantage?
>
> Also, if you want 64bit systems, you may want huge quantities of
> memory. More than 3GB, which makes most of the memory consumption
> somewhat useless.
>
> 2010/5/24 Dan McGee <dpmcgee at gmail.com>:
>> On Mon, May 24, 2010 at 8:13 PM, Gary Wright <wriggary at gmail.com> wrote:
>>> 2010/5/24 Frédéric Perrin <frederic.perrin at resel.fr>:
>>>
>>>> On a 64 bit machine, in « char *p; », p will use 64 bits (8 bytes),
>>>> instead of 4 bytes in a 32 bits machine [I'm talking about p, not about
>>>> *p which doesn't look like it exists]. Gary Wright seems to be saying
>>>> that the impact is negligible. Nicky726 seems to be saying that there
>>>> is a difference of up to 80%. I am surprised by such a claim, but there
>>>> seems to be anecdotes on Google of people seeing the same thing. As I
>>>> don't have a 64 bits machine, I can't test for myself.
>>>> --
>>>> Fred
>>>
>>> Well, heres something vaguely empirical.  Just downloaded the two
>>> latest netinstall medias and threw them on a usb stick.  I ran
>>> precisely four commands after logging in as root on each netinstall
>>> arch:
>>>
>>> 1) mkdir /mnt/tmp
>>> 2) mount /dev/sda3 /mnt/tmp  #my home partition
>>> 3) uname -a >> /mnt/tmp/gary/memcomp
>>> 4) free -m >> /mnt/tmp/gary/memcomp
>>>
>>> results to be seen here:
>>> http://aur.pastebin.com/YwTJA6cR
>>>
>>> short story:  ~29 MB more used on x86_64... or about 30 percent.
>>>
>>> But when installing a whole system, many more variables come into
>>> play.  It might have just been my dumb luck that ram usage ended up
>>> within 1-2 mb of eachother.
>>
>> 47 MB - 21 MB (for a difference of 26 MB) is what you want to be
>> looking at and nothing else. Throw buffers and cache out the window.
>> Of course, that now skews the percentage a lot higher than what you
>> stated to (47 - 21) / 21 = 123%. I'm not buying those numbers though
>> as you didn't capture near enough information and not all that much
>> was running.
>>
>> More useful are probably things like pmap comparison of the same
>> binaries, etc. after doing as close to identical operations. I'm not
>> sure even that would help, see the following pastebin to see those
>> deceiving results: http://aur.pastebin.com/GzjTZYMe
>>
>> -Dan
>>
>