[arch-general] A question about Arch Sixty Four
Hi all. I had a question about the sixty four bit port of Arch in general so figured this would be an okay place besides IRC to obtain any help I needed. I wanted to find out ruffly how much memory Arch sixty four will use for any program in general, regardless of GUI/console? I have an Intel 2 core dule T9600 2.80 GHZ, 4 Gb of RAM installed, with a 320 Gb hard-drive installed in my laptop. I tend to put a lot of RAM aside for virtual machines specifically. At present due to some requirements, I'm using Arch virtually on top of a Windows Seven host. I want to put this setup later on to Linux, and for now am doing fine with this virtual stuff. However I should mention that the host is 32-bit at present, and I was curious how much RAM is used in general under pure Arch 64? I would probably attempt to alocate about 3GB from the system. Anyone using virtualization and VMs heavily on any platform is aware of the RAM requirements, surely. I was just curious if I'd be making a mistake and/or if this would be possible? Thanks! Regards, --Keith Skype: skypedude1234 MSN Messenger: keithint37@hotmail.com Yahoo messenger /AIM: keithint1234
On Sun, May 23, 2010 at 11:02 PM, Keith Hinton <keithint1234@gmail.com> wrote:
Hi all. I had a question about the sixty four bit port of Arch in general so figured this would be an okay place besides IRC to obtain any help I needed. I wanted to find out ruffly how much memory Arch sixty four will use for any program in general, regardless of GUI/console?
<snip>
However I should mention that the host is 32-bit at present, and I was curious how much RAM is used in general under pure Arch 64? I would probably attempt to alocate about 3GB from the system. Anyone using virtualization and VMs heavily on any platform is aware of the RAM requirements, surely. I was just curious if I'd be making a mistake and/or if this would be possible? Thanks!
Regards, --Keith
Well, I'd say the difference between ram usage on lean install (base,xorg,openbox,lxde-utils) between i686 and x86_64 is kilobites. In fact, after running one install, and deciding to go with the other, there was at most maybe a 1mb difference. Its not much. (with that setup, right after boot would weigh in 99mb ram used :)) As long as you keep the base system lean, 1gb is tons of free memory to play with. Hell, I have Gnome/Compiz and a ton of firefox tabs running, and only 1gb ram installed, and 380mb ram still free (cached... but free) Also, I think the benefit of being able to run x86_64 guests would outweigh any penalty you'd be paying in larger address space. Gary
On Mon, May 24, 2010 at 12:02 AM, Keith Hinton <keithint1234@gmail.com> wrote:
Hi all. I had a question about the sixty four bit port of Arch in general so figured this would be an okay place besides IRC to obtain any help I needed. I wanted to find out ruffly how much memory Arch sixty four will use for any program in general, regardless of GUI/console?
i really don't think there is a way to answer this. i'm not an expert on hardware, but 64bit applies to the CPU, nothing else. a larger bottom level cache allows the CPU to view/consume more data/bits at once, and to perform better on precision mathematics like heavy floating point operations. i don't see it having much-to-any effect on RAM usage, but again maybe i'm missing something and then someone will surely correct me :-)
I have an Intel 2 core dule T9600 2.80 GHZ, 4 Gb of RAM installed, with a 320 Gb hard-drive installed in my laptop.
plenty
I tend to put a lot of RAM aside for virtual machines specifically. At present due to some requirements, I'm using Arch virtually on top of a Windows Seven host. I want to put this setup later on to Linux, and for now am doing fine with this virtual stuff. However I should mention that the host is 32-bit at present, and I was curious how much RAM is used in general under pure Arch 64?
again don't worry about the differences. 64 bit means you don't have to deal with address space limits/etc.... its the way to go.
I would probably attempt to alocate about 3GB from the system. Anyone using virtualization and VMs heavily on any platform is aware of the RAM requirements, surely. I was just curious if I'd be making a mistake and/or if this would be possible?
do it.
Thanks!
Regards, --Keith
C Anthony
Le lundi 24 à 0:29, C Anthony Risinger a écrit :
On Mon, May 24, 2010 at 12:02 AM, Keith Hinton <keithint1234@gmail.com> wrote:
I had a question about the sixty four bit port of Arch in general so figured this would be an okay place besides IRC to obtain any help I needed. I wanted to find out ruffly how much memory Arch sixty four will use for any program in general, regardless of GUI/console?
i really don't think there is a way to answer this. i'm not an expert on hardware, but 64bit applies to the CPU, nothing else. a larger bottom level cache allows the CPU to view/consume more data/bits at once, and to perform better on precision mathematics like heavy floating point operations. i don't see it having much-to-any effect on RAM usage, but again maybe i'm missing something and then someone will surely correct me :-)
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
On Mon, 2010-05-24 at 23:48 +0200, Frédéric Perrin wrote:
Le lundi 24 à 0:29, C Anthony Risinger a écrit :
On Mon, May 24, 2010 at 12:02 AM, Keith Hinton <keithint1234@gmail.com> wrote:
I had a question about the sixty four bit port of Arch in general so figured this would be an okay place besides IRC to obtain any help I needed. I wanted to find out ruffly how much memory Arch sixty four will use for any program in general, regardless of GUI/console?
i really don't think there is a way to answer this. i'm not an expert on hardware, but 64bit applies to the CPU, nothing else. a larger bottom level cache allows the CPU to view/consume more data/bits at once, and to perform better on precision mathematics like heavy floating point operations. i don't see it having much-to-any effect on RAM usage, but again maybe i'm missing something and then someone will surely correct me :-)
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.
This is really strange. I am running a 64 bit system and after a fresh start (Including gnome, pulseaudio, dropbox, rhythmbox,uget,transmission) it consumes between 700 and 800MB ram. I never noticed any increase in ram usage between 32bit and 64bit (Have been running a 32bit version of another distro before). Therefore I would suggest you using 64bit. Greetings Benedikt
2010/5/24 Frédéric Perrin <frederic.perrin@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. Gary
On Mon, May 24, 2010 at 8:13 PM, Gary Wright <wriggary@gmail.com> wrote:
2010/5/24 Frédéric Perrin <frederic.perrin@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
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@gmail.com>:
On Mon, May 24, 2010 at 8:13 PM, Gary Wright <wriggary@gmail.com> wrote:
2010/5/24 Frédéric Perrin <frederic.perrin@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
Need to revise my text next time. Hope it's legible. 2010/5/25 Adriano Moura <adriano.lols@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@gmail.com>:
On Mon, May 24, 2010 at 8:13 PM, Gary Wright <wriggary@gmail.com> wrote:
2010/5/24 Frédéric Perrin <frederic.perrin@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
On 05/24/10 23:48, Adriano Moura wrote:
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.
Only for the memory-address part of the data (a.k.a. "pointers"). UTF-8 text will still take up the usual number of bytes for any given piece of text. Integer values will frequently take up the same amount of space. (Programmers *can*, if they're crazy, make any differences they want in their program depending on number of bits, but typically don't.) According to this logic (which is mostly correct), programs should use somewhere between 1x and 2x as much memory depending what fraction of their data is addresses. (Probably never as much as 2x because malloc() keeps some bookkeeping data that probably isn't all addresses; because executable code isn't made of addresses; because any external data such as on the disk or the Web won't be made of addresses; and so on.)
Of course you can program can be coded to use 32bit variables,
not possible for memory addresses under 64-bit binary ABI, as far as I know..
but hey, isn't the larger number representation one of the 64bits advantage?
not really, not for integers. The advantage for integers is that operations are faster on integers that can hold values up to about 2^64. Integers that hold up to about 2^32 are the same speed. (Compilers can emulate 64-bit ints with 32-bit ints.) I don't see the point of C's volatile-size integers like "long" sometimes being 32bits and sometimes 64bits (except for the purpose of being exactly the same size as an address, essentially in order to hold an address... silly programs...), because people have to write their code to be correct at all possible integer sizes, which basically means constraining possible legitimate values to the lower size anyway. The address space advantage of 64-bits is that your program can address more than 4 virtual GB of information at once (per executable, RAM+swap used = data+code+miscellaneous). If you have less than three or four gigabytes of RAM, this 32-bit limitation is unlikely to be of importance. Well, it affects 'mmap' of several-gigabyte-large files... (there are always obscure effects :-) On x86 architectures, the 64-bit code also has access to more CPU registers, which tends to make code run faster (although code can suffer when you use all your RAM, or if bigger data fills up CPU caches quicker). There are other little differences like this too.
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.
No 3 GB doesn't make memory consumption useless. Web browser with 100 tabs eats RAM. Video editing application eats RAM. Heck, even Amarok eats 80 MB RAM, and uses some CPU when it's not even playing music, these days. Also check out 'df /'. However many gigabytes you're currently using for installed software, if you were using your software all at once, well it can make your system faster for software to remain cached in RAM... But if your system is fast enough for you, don't waste time tweaking it, because if you do, it will *still* be fast enough for you! Personally, I've went back and forth between 64bit and 32bit systems several times on my 2 GB machine, and I don't think there's a very detectable performance difference. Maybe 64bit uses a bit more RAM yet uses the CPU a bit more efficiently. On the other hand, there is a binary compatibility effect (proprietary code and viruses might work a bit better on 32bit x86, I dunno, I don't try them much).
2010/5/24 Dan McGee<dpmcgee@gmail.com>:
On Mon, May 24, 2010 at 8:13 PM, Gary Wright<wriggary@gmail.com> wrote:
2010/5/24 Frédéric Perrin<frederic.perrin@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
On 24/05/10 02:32 PM, Keith Hinton wrote:
Hi all. I had a question about the sixty four bit port of Arch in general so figured this would be an okay place besides IRC to obtain any help I needed. I wanted to find out ruffly how much memory Arch sixty four will use for any program in general, regardless of GUI/console? I have an Intel 2 core dule T9600 2.80 GHZ, 4 Gb of RAM installed, with a 320 Gb hard-drive installed in my laptop. I tend to put a lot of RAM aside for virtual machines specifically. At present due to some requirements, I'm using Arch virtually on top of a Windows Seven host. I want to put this setup later on to Linux, and for now am doing fine with this virtual stuff. However I should mention that the host is 32-bit at present, and I was curious how much RAM is used in general under pure Arch 64? I would probably attempt to alocate about 3GB from the system. Anyone using virtualization and VMs heavily on any platform is aware of the RAM requirements, surely. I was just curious if I'd be making a mistake and/or if this would be possible? Thanks!
Regards, --Keith Skype: skypedude1234 MSN Messenger: keithint37@hotmail.com Yahoo messenger /AIM: keithint1234
It is barely noticeable. I wouldn't give it a second thought.
participants (9)
-
Adriano Moura
-
b1
-
C Anthony Risinger
-
Dan McGee
-
Frédéric Perrin
-
Gary Wright
-
Isaac Dupree
-
Keith Hinton
-
Ty John