Le lundi 24 à 0:29, C Anthony Risinger a écrit :

On Mon, May 24, 2010 at 12:02 AM, Keith Hinton 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

2010/5/24 Frédéric Perrin :

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

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 :

On Mon, May 24, 2010 at 8:13 PM, Gary Wright wrote:

...

2010/5/24 Frédéric Perrin :

...

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:

...

On Mon, May 24, 2010 at 8:13 PM, Gary Wright wrote:

...

2010/5/24 Frédéric Perrin:

...

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