Re: A question about Arch Sixty Four

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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@xxxxxxxxx>:
> On Mon, May 24, 2010 at 8:13 PM, Gary Wright <wriggary@xxxxxxxxx> wrote:
>> 2010/5/24 Frédéric Perrin <frederic.perrin@xxxxxxxx>:
>>
>>> 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
>


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux