View previous topic :: View next topic |
Author |
Message |
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Mon Jul 09, 2012 12:20 am Post subject: Brand new x32 gentoo install - the journey and some numbers |
|
|
Folks,
I have been running my original install from like 7 years ago and updating it on 4-6 monthly basis. Now, I think I want to do a brand new install of Gentoo in a separate partition and move my root to it.
Since this is a brand new, I am thinking of going with x32 ABI. Does anybody here have any experience doing a fresh install of Gentoo using x32 ABI? Any wikis to look at?
Thanks,
-devsk
Last edited by devsk on Wed Jul 18, 2012 3:11 am; edited 1 time in total |
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Mon Jul 09, 2012 1:44 am Post subject: |
|
|
Yeah, I had gone through it. I think converting an existing install is probably questionable but doing a fresh install makes sense to be done in x32. |
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Mon Jul 09, 2012 2:42 am Post subject: |
|
|
Downloaded the tar from gentoo.org and here is one quick run of dumb math in python3:
current amd64 install:
Code: | $ time python3 -c "import math ; l = [i + i for i in range(100000000)];"
real 0m9.605s |
x32 inside chroot:
Code: | time python3 -c "import math ; l = [i + i for i in range(100000000)];"
real 0m13.165s | I ran three times in each to rule out cache and load time effect.
So, pretty big loss there for x32. May be I need to recompile python3 with my flags and then compare. We will see. |
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Mon Jul 09, 2012 4:04 pm Post subject: |
|
|
x32 has too many build failures during @system update... Not useful at all. |
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Tue Jul 10, 2012 6:33 am Post subject: |
|
|
Code: | ~ # /etc/java-config-2/current-system-vm/bin/javac
/etc/java-config-2/current-system-vm/bin/javac: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
~ # LD_LIBRARY_PATH=/libx32 /etc/java-config-2/current-system-vm/bin/javac
/etc/java-config-2/current-system-vm/bin/javac: error while loading shared libraries: libz.so.1: wrong ELF class: ELFCLASS32
~ # file /etc/java-config-2/current-system-vm/bin/javac
/etc/java-config-2/current-system-vm/bin/javac: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped | Totally undercooked this x32 is. Many packages need to account for it. In this case, iced tea is creating 64-bit binaries explicitly but won't find the 64-bit dependent libs at run time. This won't let anything compile beyond a point in @system.
Some packages are just plain broken on x32:
Code: | dev-db/mariadb-5.1.62
x11-libs/qt-webkit-4.8.2
dev-lang/spidermonkey-1.8.5 |
|
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Wed Jul 11, 2012 4:33 am Post subject: |
|
|
I would advise people against even trying this. There is a lot of stuff which won't build. And I have a feeling that it won't build for a long time. When packages are doing silly stuff like 'oh, this is x86_64, I must pass amd64 to yasm", or "oh, this is x86_64 but the files on the link line show '32-bit', I must pass -m32 to linker"...things just won't work.
Just too many things are broken at this time. You can't get a usable desktop. Not even close. |
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Tue Jul 17, 2012 3:29 am Post subject: |
|
|
OK. I can see the logic behind memory usage. And anybody who doesn't see it is either blind or lying. Here is eog (about the only intensive GUI app I can run at this time in x32...) running (just started and sitting idle for 5 mins, and no pics loaded) from x32 chroot vs one running from native 64-bit install:
Code: |
USER PID PPID C START TT TIME RESMEM VIRTUAL PRI S COMMAND COMMAND
devsk 568 32618 0 20:11 pts/15 00:00:00 39828 229516 19 S eog eog
root 32737 28261 0 20:10 pts/26 00:00:00 16920 31796 19 S eog eog | That's more than twice the RSS and about 7 times more virtual memory used (because of all the dependent libs mapped into the process) in native amd64 install.
Once I load an image (same image):
Code: |
USER PID PPID C START TT TIME RESMEM VIRTUAL PRI S COMMAND COMMAND
devsk 568 32618 0 20:11 pts/15 00:00:01 66916 942220 19 S eog eog
root 32737 28261 0 20:10 pts/26 00:00:01 43788 99052 19 S eog eog | Now, this is interesting. RSS gap has reduced but 64-bit native is still using 50% more RSS. WOW! Look at the VM usage. Its almost 10 times!
This is a HUGE difference if you ask me! This is every ricer's wet dream...
More things are building now but I think a full functional desktop looks like a pipe dream at this time. Too much breakage! |
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Tue Jul 17, 2012 4:02 am Post subject: |
|
|
Here is another example:
Code: | USER PID PPID C START TT TIME RESMEM VIRTUAL PRI S COMMAND COMMAND
root 20268 19031 0 20:52 pts/26 00:00:00 14952 40012 19 S gnome-terminal gnome-terminal
devsk 20637 32618 0 20:57 pts/15 00:00:00 36896 302612 19 S gnome-terminal gnome-terminal | Same thing: more than twice the RSS and about 7 times the virtual memory. |
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Wed Jul 18, 2012 2:07 am Post subject: |
|
|
Now, the story continues with QT apps:
Code: |
root 6052 1 0 09:28 pts/24 00:00:03 26544 18840 19 S konsole konsole
devsk 11002 1 0 09:28 pts/15 00:00:02 41512 92780 19 S konsole konsole |
|
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Wed Jul 18, 2012 2:47 am Post subject: |
|
|
I just emerged gimp successfully in the chroot. So, here is the obligatory comparison after loading the same 4MB jpeg:
Code: | devsk 6658 4532 2 19:41 pts/15 00:00:04 199156 1512320 19 S gimp gimp
devsk 6850 6658 0 19:41 pts/15 00:00:00 23548 3076 19 S script-fu /usr/lib64/gimp/2.0/plug-ins/script-fu -gimp 11 10 -run 0
root 6909 5355 2 19:42 pts/24 00:00:02 148992 244616 19 S gimp gimp
root 7093 6909 0 19:42 pts/24 00:00:00 6008 2448 19 S script-fu /usr/libx32/gimp/2.0/plug-ins/script-fu -gimp 10 9 -run 0 |
|
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Wed Jul 18, 2012 5:31 am Post subject: |
|
|
After patching and building many many packages, I have about 100 or so packages on my desktop which won't build. And they are essential packages like firefox, thunderbird, k3b, mplayer, ffmpeg, x264, libvpx, nvidia-drivers, skype, adobe-flash,vnc, ipsec-tools, vlc, wine, mythtv, native ZFS and so on.
But about 1200 packages built and run, that's quite good for a new ABI. Most of the KDE desktop built fine after hiccups with kdelibs.
We will get there some day! |
|
Back to top |
|
|
xaviermiller Bodhisattva
Joined: 23 Jul 2004 Posts: 8708 Location: ~Brussels - Belgique
|
Posted: Wed Jul 18, 2012 8:28 am Post subject: |
|
|
Hello,
The big, big issue with x32 is that almost all assembler optimizations are disabled. So you will lose a lot of performance with x32. _________________ Kind regards,
Xavier Miller |
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Wed Jul 18, 2012 5:55 pm Post subject: |
|
|
XavierMiller wrote: | Hello,
The big, big issue with x32 is that almost all assembler optimizations are disabled. So you will lose a lot of performance with x32. | Compilers are getting better and better at optimizing C code. So, the loss compared to hand coded assembly has reduced over the last many years.
The reduced memory footprint, larger set of registers and improved CPU cache usage are a big plus for x32 in my books. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Mon Apr 08, 2013 10:58 am Post subject: |
|
|
I saw this interesting thread only now, but something with the presented memory numbers is very strange:
Given that all memory usage is only pointers or int, then, and only then - in this unrealistic case - you can reduce the memory with x32 by the factor 2. In practice, this factor should be much lower, especially with loaded pictures in gimp. I expect that in practice you should see a difference in memory usage of 10-20% at most, even much less for programs like gimp or multimedia whose memory usage comes from "real" data and not from pointers and administration overhead.
So somehow the results presented here cannot be "true" in the sense that they cannot be for the same programs with the same useflags: I suppose that you had to drop a lot of bloated useflags (due to unable to compile otherwise) and what you measure is essentially the difference when omitting bloat and not between the architectures (which - as mentioned above - can in no case be more than the factor 2). |
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Mon Apr 08, 2013 2:46 pm Post subject: |
|
|
@mv: you are right. I did realize that soon after last posting but never came back to this thread. It was indeed because of the opengl bloat from nvidia (which I could not compile on x32), which was getting pulled into each X binary and getting mapped in RAM. |
|
Back to top |
|
|
gsra99 Tux's lil' helper
Joined: 06 Jan 2008 Posts: 104
|
Posted: Thu Jun 13, 2013 3:01 pm Post subject: |
|
|
How did you solve the issue with java? Nothing still compiles when the java use flag is enabled. |
|
Back to top |
|
|
|