[arch-general] A question about Arch Sixty Four

[Adriano Moura]

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
>