Can 32bit actually address 4GB RAM?

dyscoria · 2010-12-17 12:10:58

kokoko3k wrote:

64 bit also means increased binaries size, which could lead to a less responsive desktop, at least when launching apps due to more time needed load them from disk.

This is probably negligible, unless your hard drive is from 20 years ago or your binary is gigantic.

kokoko3k · 2010-12-19 14:27:38

It's not only the single executable binary, but also all the dependancies, and if we're talking about responsiveness, every centisec counts to me.

dyscoria · 2010-12-19 15:00:41

kokoko3k wrote:

It's not only the single executable binary, but also all the dependancies, and if we're talking about responsiveness, every centisec counts to me.

Let's take for example a commonly used desktop application: the web browser. Using chromium as an example, let's say that i686 binary and dependencies take up 100MB of space, and that x86_64 binary and dependencies take up 110MB. Assuming a read spead of around 60MB/s (which is around the usual for a desktop hard drive), that's a sixth of a second greater time for x86_64 occurring once at startup. If that matters to you then great!

kokoko3k · 2010-12-19 18:06:37

60MBps is an optimistic value, considering that there are chances that the data isn't contiguous on disk , and that those chances are higher for higher file sizes.
Of course other things like pixmap data are far more important than binary sizes, so the footprint isn't that great at all (tends to zero for bloated apps, but if responsiveness matters, it is unlikely they will be ever installed...) but just to answer your question, speaking about responsiveness, even 166ms lag is important to me.
Btw, I just made a quick test with liblapack right from archlinux repos, 64bit binary is about 15% more:
liblapack.so.3.2.2 32bit: 4598052K
liblapack.so.3.2.2 64bit: 5320320K

Kirurgs · 2010-12-20 08:38:10

Hi!

Hi, I'm preparing a bit for mem change, so I tested couple of things about mem usage. Results were surprising, but I'm not sure I can compare them very nicely, so I'll be testing more in coming days. What I can tell now is that console apps take about 15% more memory while GUI apps take a lot more, even 100% more, but as I said not sure about setup. There are some example for everyday apps: OpenOffice took 30% more while gnome-power-manager took 200% more.
As I was not able to find memory usage ANYWHERE on the web for 32bit compared to 64bit, I'll try to make some good comparison so folks can benefit from it.

So I have a plan how to test this properly:
*) make some clean test user for 32bit installation and 64bit installation (updated to latest)
*) run some meaningful apps on every of the installation
*) measure mem usage with this (latest ver to the date) => https://github.com/pixelb/scripts/commi … r/scripts/
*) compare
*) post here
*)

Currently I have not decided the final list of the apps, but these will include the following:
CLI: mc, ncftp, tar, syslog-ng, agetty, rtorrent
GUI: OpenOffice, Tux Commander, Calculator, Banshee, Skype, Gnome-Do, Gimp, FireFox, Chromium, Eclipse, Scite, RapidSVN, Notepad (wine), Metacity, Xorg

The list is not final, if You want some app in, please comment and edit You own post (I don't want to ruin the thread with app names like 5pages long if there will be any feedback of course...)

I'll try to get couple of apps of every sort, like couple java apps, couple QT, couple GTK, Python etc.

regards
Kirurgs

Last edited by Kirurgs (2010-12-20 08:52:41)

Zom · 2010-12-20 10:09:26

Kirurgs wrote:

Is there any serious issues why not use PAE with > 4G RAM?

PAE will let your computer use all the available RAM, but a single process still can't access more than 3.25 or whatever the limit is.

If this is a problem or not is up to the application I suppose.

Right now, I see no reason to use a 32-bit OS on a 64-bit CPU. Since the multilib support on arch is very good, things "just work" in my experience. That said, it was a whole different case some years ago.

Kirurgs · 2010-12-20 11:40:02

Multilib is excellent, everyting works, no complains...
The reason is - mem usage, just that

Kirurgs · 2010-12-26 19:06:44

Hi!

I did some measuring of process memory using x86 and x86_64 archs. Results were nice and predictable. At least I now I will know how many more RAM 64bit swallows and approx how many more RAM I will get using PAE

So, testing...
I used ArchLinux updated to max at the moment of testing for each arch, I created user test on each of them with default configuration, nothing more. Installed the same applications and fired up tests. Memory consumption was measured by ps_mem.py script from the link above.
I used self compiled 2.6.35.8 kernels. Config is all the same except for x86 I enabled PAE (highmem64g).

Initially when I booted into Gnome, I checked initial memory usage and it was as follows.
x86:

Mem:   4050352k total,   494192k used,  3556160k free,    33844k buffers
Swap:  6834204k total,        0k used,  6834204k free,   189600k cached

x86_64:

Mem:   3985472k total,   736652k used,  3248820k free,    64300k buffers
Swap:  6834204k total,        0k used,  6834204k free,   210584k cached

So right after boot, x86_64 used about 30% more.

The rest of the results are pretty interesting, but not surprising except couple of things.
First: X used less memory in x86_64 by about 19%
Second: on x86 java was shown as one process but on x86_64 they were two for the same 2 applications I ran (eclipse and sqldeveloper)
Third: it seems that on x86_64 wineserver used 2x more memory, probably due to supporting both 32bit and 64bit for x86_64

Legend: processes are ordered by name, number after process name means how many more RAM x86_64 swallows compared to x86.

There are non-gui processes that were taken and measured:

acpid    23.0%
agetty(5)    29.0%
gnome-power-manager    25.9%
mc    21.1%
ncftp    18.3%
rtorrent    20.0%
wpa_supplicant    18.1%

In average x86_64 used 22% more ram.

These are apps that have gui elements, these are majority for common desktop:

applet.py    39.4%
banshee-1    28.9%
blueman-applet    31.1%
chromium(5)    34.7%
clock-applet    30.6%
firefox    26.7%
gimp-2.6    33.0%
gnome-calculato    28.3%
gnome-do(2)    32.8%
gnome-terminal    25.0%
java    50.7%
metacity    37.5%
nm-applet    27.0%
python2.7    36.4%
rapidsvn    24.8%
scite    22.0%
skype    11.2%
soffice.bin    22.8%
tuxcmd    29.7%
Xorg    -19.4%

explorer.exe    45.8%    
services.exe    33.9%
plsqldev.exe    6.6%
TOTALCMD.EXE    17.2%
winedevice.exe    29.2%
wineserver    57.6%

So GUI on average used about 28% more RAM. If we take away java and wineserver we get about 26%, be rough and 25% it is

So for 8G usage I loose about 2G when using x86_64 for the same stuff as in x86.

Hope people will find this useful.

regards
Kirurgs

Last edited by Kirurgs (2010-12-26 19:22:11)

Kirurgs · 2010-12-29 19:52:03

A little update: PAE and hibernate using TOI is complete garbage, when hibernating using near full or full + swap memory, resume always fails... In short - no go... I hope this will change with 2.6.37.

mhertz · 2010-12-31 17:29:14

When measuring ram usage after bootup on arch64 vs arch32, then also keep in mind that on intel 64bit system with over 3gb, then by default 64mb is reserved for a software io tlb.

I would also recommend using arch64 on compatible hardware, so as to utilize the 64 bit register size, double amount of registers, improved sse implementation and additionally, then arch64 packages has sse/sse2 enabled, whereas arch32 packages dosen't.

Also this phoronix benchmark is pretty impressive imho: http://www.phoronix.com/scan.php?page=a … _pae&num=1

kokoko3k · 2010-12-31 18:13:14

then arch64 packages has sse/sse2 enabled, whereas arch32 packages dosen't.
Also this phoronix benchmark is pretty impressive imho: http://www.phoronix.com/scan.php?page=a … _pae&num=1

Yeah, it would be interesting to see a benchmark comparing 32bit apps running with the same instruction set as 64bit ones.

R00KIE · 2010-12-31 18:23:56

On a subjective note, for me a clean and "new" 64bit install seemed to pack more punch than a 32bit "old" install on the exact same machine.

Everything else was the same after changing to 64bit, 32bit only apps still run fine when installing the lib32 dependencies. If for nothing else you will not need to recompile the 32bit kernel to enable pae. If you have enough ram to worry about the 32bit kernel and apps being able to access it then you have more than enough ram to use 64bit, you will get the added benefit of extra cpu registers and the peace of mind that you are not incurring in any possible speed penalties of using pae.

Zom · 2011-01-01 10:50:10

mhertz wrote:

arch64 packages has sse/sse2 enabled, whereas arch32 packages dosen't.

Just a foot note here, I think you meant sse3. I think 32-bit mplayer at least has sse/sse2 enabled in arch32, but I could be wrong.

vvv⁻⁻⁻ Oh, I see then.

Last edited by Zom (2011-01-01 18:08:26)

mhertz · 2011-01-01 13:54:16

What I was reffering to, was that all arch32 packages is compiled with "-march=i686 -mtune=generic", and with those flags then sse/sse2 optimization isn't enabled, whereas arch64 packages does have it enabled with it's flags: -march=x86-64 -mtune=generic.

From the gcc spec:

For the i386 compiler, you need to use -march=cpu-type, -msse or -msse2 switches to enable SSE extensions and make this option effective. For the x86-64 compiler, these extensions are enabled by default.
The resulting code should be considerably faster in the majority of cases and avoid the numerical instability problems of 387 code, but may break some existing code that expects temporaries to be 80bit.
This is the default choice for the x86-64 compiler.

However, you do have a point with e.g. mplayer, as I can see from it's PKGBUILD that it's configured with '--enable-runtime-cpudetection'. I must admit that I don't know how that specifically works, since I find it confusing how the runtime cpu detection e.g. can enable sse2 if sse2 hasen't been "compiled-in"?

Anyway, I would still preffer to have sse/se2 specifically enabled for all packages like it is in arch64...

Gusar · 2011-01-01 14:35:38

mhertz wrote:

However, you do have a point with e.g. mplayer, as I can see from it's PKGBUILD that it's configured with '--enable-runtime-cpudetection'. I must admit that I don't know how that specifically works, since I find it confusing how the runtime cpu detection e.g. can enable sse2 if sse2 hasen't been "compiled-in"?

It *has* been compiled in. That's the whole point. You compile in everything under the sun, then you check at runtime which stuff the processor supports and run those. You'll see in MPlayer's output which extensions are used, if you use -v:

$ mplayer -v
[...]
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNowExt: 0 SSE: 1 SSE2: 1 SSSE3: 0
[...]

And as for MMX, SSE, etc in general, those bring very little, if any speedup to compiled code, unless you write code to specifically use them. Multimedia stuff (audio/video/image codecs) is the biggest user of that. Outside of that, specifying -msse and company to gcc will not bring you a visible speed-up.

mhertz · 2011-01-01 17:00:05

Obviously it's only multimedia stuff which benefit from it, and it's nice that mplayer has runtime cpu detection, but for all the rest of the multimedia apps which dosen't, then I would preffer to have support for sse/sse2 compiled in, as the code is probably optimized for that in many cases, in this particular app-group.

About the runtime cpu detection, then thanks for the correction; I was a bit slow there

Gusar · 2011-01-01 18:22:04

mhertz wrote:

Obviously it's only multimedia stuff which benefit from it, and it's nice that mplayer has runtime cpu detection, but for all the rest of the multimedia apps which dosen't, then I would preffer to have support for sse/sse2 compiled in, as the code is probably optimized for that in many cases, in this particular app-group.

Pretty much all multimedia in Linux is based on ffmpeg and some other libraries. They *all* have handwritten MMX/SSE etc assembly and runtime detection.

mhertz · 2011-01-01 21:33:04

I'm just relying on the gcc spec which specifically states again:

"The resulting code should be considerably faster in the majority of cases and avoid the numerical instability problems of 387 code, but may break some existing code that expects temporaries to be 80bit."

Note, i'm not disagreeing with you, but just argumenting that the above must hold some truth some way or another

Last edited by mhertz (2011-01-01 21:35:45)

Kirurgs · 2011-01-03 20:33:59

Hi!

Finally I have got my hands on 8G, YES
And I tested hibernate a bit, so with 8G RAM and 6.5G swap I have now, I can hibernate PAE successfully when memory usage is about 7.5Gb. This is possible with neat TOI feature called compression
For PAE and x86_64 I have tried to hibernate and resume like 10 times and it worked like a charm.

For the final solution I will try to use x86_64, if memory will be enough I'll continue to use it, if not I think I'll switch to PAE...

regards
Kirurgs

Arch Linux

#26 2010-12-17 12:10:58

Re: Can 32bit actually address 4GB RAM?

#27 2010-12-19 14:27:38

Re: Can 32bit actually address 4GB RAM?

#28 2010-12-19 15:00:41

Re: Can 32bit actually address 4GB RAM?

#29 2010-12-19 18:06:37

Re: Can 32bit actually address 4GB RAM?

#30 2010-12-20 08:38:10

Re: Can 32bit actually address 4GB RAM?

#31 2010-12-20 10:09:26

Re: Can 32bit actually address 4GB RAM?

#32 2010-12-20 11:40:02

Re: Can 32bit actually address 4GB RAM?

#33 2010-12-26 19:06:44

Re: Can 32bit actually address 4GB RAM?

#34 2010-12-29 19:52:03

Re: Can 32bit actually address 4GB RAM?

#35 2010-12-31 17:29:14

Re: Can 32bit actually address 4GB RAM?

#36 2010-12-31 18:13:14

Re: Can 32bit actually address 4GB RAM?

#37 2010-12-31 18:23:56

Re: Can 32bit actually address 4GB RAM?

#38 2011-01-01 10:50:10

Re: Can 32bit actually address 4GB RAM?

#39 2011-01-01 13:54:16

Re: Can 32bit actually address 4GB RAM?

#40 2011-01-01 14:35:38

Re: Can 32bit actually address 4GB RAM?

#41 2011-01-01 17:00:05

Re: Can 32bit actually address 4GB RAM?

#42 2011-01-01 18:22:04

Re: Can 32bit actually address 4GB RAM?

#43 2011-01-01 21:33:04

Re: Can 32bit actually address 4GB RAM?

#44 2011-01-03 20:33:59

Re: Can 32bit actually address 4GB RAM?

Board footer