[gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags

[gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags

[Frank Steinmetzger]

[-- Attachment #1: Type: text/plain, Size: 4669 bytes --]

Hello list

Long time no read... :)

It follows a verbose preamble.  For the actual questions see dashed line below.
TL;DR summary: it’s all about ricer-performance questions on a netbook.


I have the luck of having obtained a used netbook for free (Atom N450, single-
core with HT, 1 GB memory, 5400 rev HDD).  During the last week I’ve been
experimenting with 32 and 64 bits on it and am still quite undecided which to
keep. My reasons:

- They are not as far apart in CPU performance as is the Core2.
  I posted a 32/64 comparison for Core2 a few months ago, which showed that
  Lilypond speedup on 64 bit was 50%. On the Atom, it actually took 5% longer.
  (Sadly, Blender doesn’t build on 32 bit right now).
- Startup times for hogs like Firefox and KDE are quite equal between the two
  (that could be attributed in parts to the fact that the 64 bit partition
  sits on the disk’s first sectors, while 32 bit sits at the other end, I
  don’t know which end is faster).
- pro 64: it is very easy to use distcc, as opposed to 32 bits (see below).
- con 64: it uses about 50% more memory, 32 bit builds are a little faster.

The RAM argument is the most convincing one right now, since more free RAM
means more cache, which means a faster system in the long run. Currently, KDE
after logon needs 150 MB on 32 bit, and 250 MB on 64 bit (without akonadi for
now). But awesome WM rocks on a netbook anyway.


----------[ Questions begin ]------------------------------------------------

So I’m interested in you opinion and own experience about the following
arising questions:

* From my observations, the benefit of 64 bit over 32 is much smaller for an
  Atom than it is for my Core2.  Am I right to assume thus that the Atom
  architecture doesn’t have much to offer to 64 bit (such as extra registers)?
  I’m not talking about memory here, since it’s limited to 2 GB in any case.

* The problem of distcc between different architectures:
  The netbook already had an older 32 bit Gentoo installed.  And since I have
  a multilib host (march=core2), I though I could upgrade with distcc (using
  march=atom on the netbook).  But at some point more and more stuff stopped
  working, eventually I got “invalid instruction” errors during emerge, hence
  I figured that was a dead end.

  So is it possible to mix architectures in this way at all with distcc?
  I also have crossdev for i686 installed, which even shares files with the
  system’s normal multilib gcc. I find that odd.
  I sped up the installation process for 32 bit by using a chroot on the big
  machine, which worked nicely.  But it’s not a long-term solution, b/c it
  uses up too much disk space on the host.

* I’m interested in the question of -O2 vs. -Os.
  Some sources say -Os is bad, b/c it breaks debugging and is mainly untested.
  I won’t do heavy developing on it anyway, and Atoms do have a puny cache.
  So I wonder whether -Os would improve execution time and RAM usage
  noticably.  Diskspace itself is not an issue.

* I’m also interested in comparing bin packages over self-compiled ones.
  E.g. I did compile icedtea, even if it’s just for TV browser. :)
  Can you name a Java benchmark to measure CPU performance?

* The last thing I’m going to set up is filesystem encryption, at least for ~.
  I already know/think that AES would be the best choice due to limited CPU
  power, but what else is there to heed besides key size?

* What other small benchmarks for CPU and memory can you recommend?  So far I
  tested with nbench and sysbench. The results are so-and-so. Some computation
  stuff is much slower on 64 bit, some a bit faster.  The applicability to
  every-day use is of course a wibbly-wobbly argument.
  I also tested the runtime of some application (packing and unpacking of
  archives, throughput with dd, mencoder).  If there is interest, I can post
  the result of 21 runs on each platform, measured with GNU time.

----------[ Questions end ]--------------------------------------------------


PS.:  I’m aware that benchmarks are always a bit subjective and none is
perfect.  I also realise that most of the questions quite belong into the
ricer corner.  But Netbooks are ricer devices, b/c they need to perform at
their limits all the time. :-D

If you read until this point, thank you very much for your time.  You get a
unicorn as a reward: `^nn~
-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any Facebook service.

“Time is money” said the waiter and put the date on the bill.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags

[Norman Invasion]

On 11 December 2012 12:36, Frank Steinmetzger <Warp_7@gmx.de> wrote:
> Hello list
. . .
> So I’m interested in you opinion and own experience about the following
> arising questions:
>
> * From my observations, the benefit of 64 bit over 32 is much smaller for an
>   Atom than it is for my Core2.  Am I right to assume thus that the Atom
>   architecture doesn’t have much to offer to 64 bit (such as extra registers)?
>   I’m not talking about memory here, since it’s limited to 2 GB in any case.
>
> * The problem of distcc between different architectures:
>   The netbook already had an older 32 bit Gentoo installed.  And since I have
>   a multilib host (march=core2), I though I could upgrade with distcc (using
>   march=atom on the netbook).  But at some point more and more stuff stopped
>   working, eventually I got “invalid instruction” errors during emerge, hence
>   I figured that was a dead end.
>
>   So is it possible to mix architectures in this way at all with distcc?
>   I also have crossdev for i686 installed, which even shares files with the
>   system’s normal multilib gcc. I find that odd.
>   I sped up the installation process for 32 bit by using a chroot on the big
>   machine, which worked nicely.  But it’s not a long-term solution, b/c it
>   uses up too much disk space on the host.
>
> * I’m interested in the question of -O2 vs. -Os.
>   Some sources say -Os is bad, b/c it breaks debugging and is mainly untested.
>   I won’t do heavy developing on it anyway, and Atoms do have a puny cache.
>   So I wonder whether -Os would improve execution time and RAM usage
>   noticably.  Diskspace itself is not an issue.
>
> * I’m also interested in comparing bin packages over self-compiled ones.
>   E.g. I did compile icedtea, even if it’s just for TV browser. :)
>   Can you name a Java benchmark to measure CPU performance?
>
> * The last thing I’m going to set up is filesystem encryption, at least for ~.
>   I already know/think that AES would be the best choice due to limited CPU
>   power, but what else is there to heed besides key size?
>
> * What other small benchmarks for CPU and memory can you recommend?  So far I
>   tested with nbench and sysbench. The results are so-and-so. Some computation
>   stuff is much slower on 64 bit, some a bit faster.  The applicability to
>   every-day use is of course a wibbly-wobbly argument.
>   I also tested the runtime of some application (packing and unpacking of
>   archives, throughput with dd, mencoder).  If there is interest, I can post
>   the result of 21 runs on each platform, measured with GNU time.
>
> ----------[ Questions end ]--------------------------------------------------
>
>
> PS.:  I’m aware that benchmarks are always a bit subjective and none is
> perfect.  I also realise that most of the questions quite belong into the
> ricer corner.  But Netbooks are ricer devices, b/c they need to perform at
> their limits all the time. :-D
>

I have an old N280 atom netbook, so the 64v32 is moot
for me, but with a hardware limit of 2G, I'd probably run
32-bit.  I don't use distcc, either, since I'd rather not
saturate my (802.11g) wireless network.

-Os, in my experience, makes very little difference on
amd64/x86_64/whate'er (FreeBSD 9.x amd64 clang
the final sizes of the binaries between -Os & -O3 have
very little bearing on expectations), however the atom
seems to benefit quite a lot more from the smaller
binaries, which on 32-bit (again in my experience
with gentoo gcc46 i686) are significantly smaller than
-O2 & -O3 binaries.  I would assume this has to do
with cache fit.

Some suggest using -mfpmath=sse, which I've not
studied in depth.  But if the x87 bits are particularly
slow on the atom (mind you, I have no idea), & you're
not running stuff that makes heavy use of your sse
registers I don't see a downside.

64-bit probably won't help much at all, unless you're
running really numbery stuff.  I suggest unless you're
doing video editing or scientific number crunching
(on your atom netbook) 32 will be fine.

Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 5904 bytes --]

Am 11.12.2012 18:36, schrieb Frank Steinmetzger:
> Hello list
> 
> Long time no read... :)
> 
> It follows a verbose preamble.  For the actual questions see dashed line below.
> TL;DR summary: it’s all about ricer-performance questions on a netbook.
> 
> 
> I have the luck of having obtained a used netbook for free (Atom N450, single-
> core with HT, 1 GB memory, 5400 rev HDD).  During the last week I’ve been
> experimenting with 32 and 64 bits on it and am still quite undecided which to
> keep. My reasons:
> 
> - They are not as far apart in CPU performance as is the Core2.
>   I posted a 32/64 comparison for Core2 a few months ago, which showed that
>   Lilypond speedup on 64 bit was 50%. On the Atom, it actually took 5% longer.
>   (Sadly, Blender doesn’t build on 32 bit right now).
> - Startup times for hogs like Firefox and KDE are quite equal between the two
>   (that could be attributed in parts to the fact that the 64 bit partition
>   sits on the disk’s first sectors, while 32 bit sits at the other end, I
>   don’t know which end is faster).

The first part (which actually is the outer edge of the physical disk).

> - pro 64: it is very easy to use distcc, as opposed to 32 bits (see below).
> - con 64: it uses about 50% more memory, 32 bit builds are a little faster.
> 
> The RAM argument is the most convincing one right now, since more free RAM
> means more cache, which means a faster system in the long run. Currently, KDE
> after logon needs 150 MB on 32 bit, and 250 MB on 64 bit (without akonadi for
> now). But awesome WM rocks on a netbook anyway.
> 
> 
> ----------[ Questions begin ]------------------------------------------------
> 
> So I’m interested in you opinion and own experience about the following
> arising questions:
> 
> * From my observations, the benefit of 64 bit over 32 is much smaller for an
>   Atom than it is for my Core2.  Am I right to assume thus that the Atom
>   architecture doesn’t have much to offer to 64 bit (such as extra registers)?
>   I’m not talking about memory here, since it’s limited to 2 GB in any case.
> 

It has the same set of registers as your Core2. It's just that the Atom
micro-architecture is terrible with regard to 64bit. That's just about
the only reason that x32 was invented (and now that I've said it, I'm
just waiting for the flamewar about it).

> * The problem of distcc between different architectures:
>   The netbook already had an older 32 bit Gentoo installed.  And since I have
>   a multilib host (march=core2), I though I could upgrade with distcc (using
>   march=atom on the netbook).  But at some point more and more stuff stopped
>   working, eventually I got “invalid instruction” errors during emerge, hence
>   I figured that was a dead end.
> 
>   So is it possible to mix architectures in this way at all with distcc?
>   I also have crossdev for i686 installed, which even shares files with the
>   system’s normal multilib gcc. I find that odd.

I don't think you can mix x86_32 and x64 easily but I've never tried.
Did you try adding a CFLAGS="-m32"? From comparing `gcc -Q --help=target
-march=xxx` they should be compatible.

>   I sped up the installation process for 32 bit by using a chroot on the big
>   machine, which worked nicely.  But it’s not a long-term solution, b/c it
>   uses up too much disk space on the host.
> 

I do the same using NFS, bind mounts and tmpfs. What do you mean by disk
space? If you can use common CFLAGS, you could try installing binary
packages from your build host on your netbook (use quickpkg and friends).

> * I’m interested in the question of -O2 vs. -Os.
>   Some sources say -Os is bad, b/c it breaks debugging and is mainly untested.
>   I won’t do heavy developing on it anyway, and Atoms do have a puny cache.
>   So I wonder whether -Os would improve execution time and RAM usage
>   noticably.  Diskspace itself is not an issue.
> 

I use -Os but have no data to back it up (I'm also using an older Atom).
Gentoo wiki suggests using "-O2 -fno-reorder-blocks
-fno-reorder-functions" as a compromise.

> * I’m also interested in comparing bin packages over self-compiled ones.
>   E.g. I did compile icedtea, even if it’s just for TV browser. :)
>   Can you name a Java benchmark to measure CPU performance?
> 

How about something from this site:
http://shootout.alioth.debian.org/

> * The last thing I’m going to set up is filesystem encryption, at least for ~.
>   I already know/think that AES would be the best choice due to limited CPU
>   power, but what else is there to heed besides key size?
> 

Nothing, you're good. Hash and key chaining method have negligible
impact. If you stick with an x86_32 userspace I suggest at least using
an x64 kernel so you can use of CRYPTO_AES_X86_64.

> * What other small benchmarks for CPU and memory can you recommend?  So far I
>   tested with nbench and sysbench. The results are so-and-so. Some computation
>   stuff is much slower on 64 bit, some a bit faster.  The applicability to
>   every-day use is of course a wibbly-wobbly argument.
>   I also tested the runtime of some application (packing and unpacking of
>   archives, throughput with dd, mencoder).  If there is interest, I can post
>   the result of 21 runs on each platform, measured with GNU time.
> 

How about trying some browser benchmarks. Check out the following for
different aspects:
http://ie.microsoft.com/testdrive/performance/mazesolver/default.html
http://www.webkit.org/perf/sunspider/sunspider.html
http://peacekeeper.futuremark.com/run.action

There is also a Qt render benchmark
http://code.google.com/p/qtperf/
Check out app-admin/eselect-qtgraphicssystem and see how they compare in
appearance and numbers.

Regards,
Florian Philipp



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags

[Joseph]

I have: Atom(TM) CPU  330   @ 1.60GHz
running it with:

CFLAGS="-march=core2 -O2 -pipe"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j5"
CHOST="x86_64-pc-linux-gnu"

Didn't run any test performance on it, but the only disappointing fact about this small box is that it will not reboot itself when the power goes down.
It runs my asterisk and hylafax in remote location so I have to keep an eye on it :-/

--
Joseph


On 12/11/12 18:36, Frank Steinmetzger wrote:
>Hello list
>
>Long time no read... :)
>
>It follows a verbose preamble.  For the actual questions see dashed line below.
>TL;DR summary: it’s all about ricer-performance questions on a netbook.
>
>
>I have the luck of having obtained a used netbook for free (Atom N450, single-
>core with HT, 1 GB memory, 5400 rev HDD).  During the last week I’ve been
>experimenting with 32 and 64 bits on it and am still quite undecided which to
>keep. My reasons:
>
>- They are not as far apart in CPU performance as is the Core2.
>  I posted a 32/64 comparison for Core2 a few months ago, which showed that
>  Lilypond speedup on 64 bit was 50%. On the Atom, it actually took 5% longer.
>  (Sadly, Blender doesn’t build on 32 bit right now).
>- Startup times for hogs like Firefox and KDE are quite equal between the two
>  (that could be attributed in parts to the fact that the 64 bit partition
>  sits on the disk’s first sectors, while 32 bit sits at the other end, I
>  don’t know which end is faster).
>- pro 64: it is very easy to use distcc, as opposed to 32 bits (see below).
>- con 64: it uses about 50% more memory, 32 bit builds are a little faster.
>
>The RAM argument is the most convincing one right now, since more free RAM
>means more cache, which means a faster system in the long run. Currently, KDE
>after logon needs 150 MB on 32 bit, and 250 MB on 64 bit (without akonadi for
>now). But awesome WM rocks on a netbook anyway.
>
>
>----------[ Questions begin ]------------------------------------------------
>
>So I’m interested in you opinion and own experience about the following
>arising questions:
>
>* From my observations, the benefit of 64 bit over 32 is much smaller for an
>  Atom than it is for my Core2.  Am I right to assume thus that the Atom
>  architecture doesn’t have much to offer to 64 bit (such as extra registers)?
>  I’m not talking about memory here, since it’s limited to 2 GB in any case.
>
>* The problem of distcc between different architectures:
>  The netbook already had an older 32 bit Gentoo installed.  And since I have
>  a multilib host (march=core2), I though I could upgrade with distcc (using
>  march=atom on the netbook).  But at some point more and more stuff stopped
>  working, eventually I got “invalid instruction” errors during emerge, hence
>  I figured that was a dead end.
>
>  So is it possible to mix architectures in this way at all with distcc?
>  I also have crossdev for i686 installed, which even shares files with the
>  system’s normal multilib gcc. I find that odd.
>  I sped up the installation process for 32 bit by using a chroot on the big
>  machine, which worked nicely.  But it’s not a long-term solution, b/c it
>  uses up too much disk space on the host.
>
>* I’m interested in the question of -O2 vs. -Os.
>  Some sources say -Os is bad, b/c it breaks debugging and is mainly untested.
>  I won’t do heavy developing on it anyway, and Atoms do have a puny cache.
>  So I wonder whether -Os would improve execution time and RAM usage
>  noticably.  Diskspace itself is not an issue.
>
>* I’m also interested in comparing bin packages over self-compiled ones.
>  E.g. I did compile icedtea, even if it’s just for TV browser. :)
>  Can you name a Java benchmark to measure CPU performance?
>
>* The last thing I’m going to set up is filesystem encryption, at least for ~.
>  I already know/think that AES would be the best choice due to limited CPU
>  power, but what else is there to heed besides key size?
>
>* What other small benchmarks for CPU and memory can you recommend?  So far I
>  tested with nbench and sysbench. The results are so-and-so. Some computation
>  stuff is much slower on 64 bit, some a bit faster.  The applicability to
>  every-day use is of course a wibbly-wobbly argument.
>  I also tested the runtime of some application (packing and unpacking of
>  archives, throughput with dd, mencoder).  If there is interest, I can post
>  the result of 21 runs on each platform, measured with GNU time.
>
>----------[ Questions end ]--------------------------------------------------
>
>
>PS.:  I’m aware that benchmarks are always a bit subjective and none is
>perfect.  I also realise that most of the questions quite belong into the
>ricer corner.  But Netbooks are ricer devices, b/c they need to perform at
>their limits all the time. :-D
>
>If you read until this point, thank you very much for your time.  You get a
>unicorn as a reward: `^nn~
>-- 
>Gruß | Greetings | Qapla’
>Please do not share anything from, with or about me with any Facebook service.
>
>“Time is money” said the waiter and put the date on the bill.

Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags

[Frank Steinmetzger]

[-- Attachment #1: Type: text/plain, Size: 5131 bytes --]

On Tue, Dec 11, 2012 at 09:20:55PM +0100, Florian Philipp wrote:

> > * From my observations, the benefit of 64 bit over 32 is much smaller for an
> >   Atom than it is for my Core2.  Am I right to assume thus that the Atom
> >   architecture doesn’t have much to offer to 64 bit (such as extra registers)?
> >   I’m not talking about memory here, since it’s limited to 2 GB in any case.
> > 
> 
> It has the same set of registers as your Core2.

Incidentally, when I initially set up the netbook, the output of
gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p'
(which floated around the ML in the past) implied core2, IIRC.

> It's just that the Atom micro-architecture is terrible with regard to
> 64bit. That's just about the only reason that x32 was invented (and
> now that I've said it, I'm just waiting for the flamewar about it).

Terrible in what way? Inadequate memory throughput? I didn't know x32,
but from what I've read in the last few minutes it sounds intriguing.

> >   So is it possible to mix architectures in this way at all with distcc?
> >   I also have crossdev for i686 installed, which even shares files with the
> >   system’s normal multilib gcc. I find that odd.
> 
> I don't think you can mix x86_32 and x64 easily but I've never tried.
> Did you try adding a CFLAGS="-m32"? From comparing `gcc -Q --help=target
> -march=xxx` they should be compatible.

Not yet, putting in on todo, as it would involve building, running,
testing (or reading up on it :-p ).

> >   I sped up the installation process for 32 bit by using a chroot on the big
> >   machine, which worked nicely.  But it’s not a long-term solution, b/c it
> >   uses up too much disk space on the host.
> 
> I do the same using NFS, bind mounts and tmpfs. What do you mean by disk
> space?

That I don't have much space left on the host machine for the entire
chroot. I bind-mount distfiles and portage, but I'm still running low
on gigabytes.
I was thinking of NFS quite early, but a friend said it would perform
not nicely. Also, with all my cables currently occupied, the two are
connected over a slow WiFi router.  It's one of the rare cases in which
compressing distcc traffic increases performance. :) The netbook has
gigabit ethernet, though.  Thank $DEITY for compressed tar pipes over
SSH.  I wonder what Windows people would do in such a situation. >:-]

> If you can use common CFLAGS, you could try installing binary
> packages from your build host on your netbook (use quickpkg and friends).

Which brings me back to the disk space problem.  Right now the 32 bit
chroot is a direct mirror, which is rsynced to and fro when the netbook
runs in 64 bit. Once I have a cable available I think I'll go with NFS.

> > […] Can you name a Java benchmark to measure CPU performance?
> 
> How about something from this site:
> http://shootout.alioth.debian.org/

Will have a look-see.
> 
> > * The last thing I’m going to set up is filesystem encryption, at least for ~.
> >   I already know/think that AES would be the best choice due to limited CPU
> >   power, but what else is there to heed besides key size?
> 
> Nothing, you're good. Hash and key chaining method have negligible
> impact. If you stick with an x86_32 userspace I suggest at least using
> an x64 kernel so you can use of CRYPTO_AES_X86_64.

That's an interesting idea. If I had a 32 bit userland, I would have to
build new kernels on my big 64 laptop then, right?  I don’t suppose I
can simply mix chosts, such that I would have a multilib x86_64
gcc/binutils/glibc, but i686 everything else.

I haven't done any comparisons of 32/64 crypto yet, I'm just reading
docs on Luks (never used it before).  Big stuff (videos, music) won't be
encrypted anyway, just the sensitive data like mail, documents,
passwords and personal photos. So the requirements won't be high.
However I might expand it to /, though that would involve a more
complicated boot process (I never needed initrds except for bootsplash).

On a sidenote, While I was cleaning up unread mails in the ML, I just
found your interesting frontswap/zcache trick.

I wonder how many years I'd have to use the device to get back the time
from improved performance that I spent setting it up in the first place.
:-D

> > * What other small benchmarks for CPU and memory can you recommend?
> >   […]
> 
> How about trying some browser benchmarks. […]

I could also use those to compare binary and source firefox (which is
compiling in the chroot right now).

> There is also a Qt render benchmark
> http://code.google.com/p/qtperf/
> Check out app-admin/eselect-qtgraphicssystem and see how they compare in
> appearance and numbers.

Nice idea, since I'm a general Qt fanboy.

So thanks a lot for the info so far, I'll try to digest it all tomorrow.
Good night for now. *yaaaaawn*
-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any Facebook service.

Emacs is a great operating system, which only lacks a good editor.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 4250 bytes --]

Am 12.12.2012 02:40, schrieb Frank Steinmetzger:
> On Tue, Dec 11, 2012 at 09:20:55PM +0100, Florian Philipp wrote:
> 
>>> * From my observations, the benefit of 64 bit over 32 is much smaller for an
>>>   Atom than it is for my Core2.  Am I right to assume thus that the Atom
>>>   architecture doesn’t have much to offer to 64 bit (such as extra registers)?
>>>   I’m not talking about memory here, since it’s limited to 2 GB in any case.
>>>
>>
>> It has the same set of registers as your Core2.
> 
> Incidentally, when I initially set up the netbook, the output of
> gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p'
> (which floated around the ML in the past) implied core2, IIRC.
> 
>> It's just that the Atom micro-architecture is terrible with regard to
>> 64bit. That's just about the only reason that x32 was invented (and
>> now that I've said it, I'm just waiting for the flamewar about it).
> 
> Terrible in what way? Inadequate memory throughput? I didn't know x32,
> but from what I've read in the last few minutes it sounds intriguing.
> 

Just citing Flameeyes who is citing Intel.
http://blog.flameeyes.eu/2012/06/debunking-x32-myths

[...]
>>>   I sped up the installation process for 32 bit by using a chroot on the big
>>>   machine, which worked nicely.  But it’s not a long-term solution, b/c it
>>>   uses up too much disk space on the host.
>>
>> I do the same using NFS, bind mounts and tmpfs. What do you mean by disk
>> space?
> 
> That I don't have much space left on the host machine for the entire
> chroot. I bind-mount distfiles and portage, but I'm still running low
> on gigabytes.
> I was thinking of NFS quite early, but a friend said it would perform
> not nicely. Also, with all my cables currently occupied, the two are
> connected over a slow WiFi router.  It's one of the rare cases in which
> compressing distcc traffic increases performance. :) The netbook has
> gigabit ethernet, though.  Thank $DEITY for compressed tar pipes over
> SSH.  I wonder what Windows people would do in such a situation. >:-]
> 

I see. Yep, wifi is really not a good choice for this. NFS works nice,
though. I just ran into some minor trouble when setuid bits would not
survive merging. Haven't debugged this yet as it's easy enough to find
with a script.

[...]
>>> * The last thing I’m going to set up is filesystem encryption, at least for ~.
>>>   I already know/think that AES would be the best choice due to limited CPU
>>>   power, but what else is there to heed besides key size?
>>
>> Nothing, you're good. Hash and key chaining method have negligible
>> impact. If you stick with an x86_32 userspace I suggest at least using
>> an x64 kernel so you can use of CRYPTO_AES_X86_64.
> 
> That's an interesting idea. If I had a 32 bit userland, I would have to
> build new kernels on my big 64 laptop then, right?  I don’t suppose I
> can simply mix chosts, such that I would have a multilib x86_64
> gcc/binutils/glibc, but i686 everything else.
> 

Try this.
http://www.gossamer-threads.com/lists/gentoo/user/190919

> I haven't done any comparisons of 32/64 crypto yet, I'm just reading
> docs on Luks (never used it before).  Big stuff (videos, music) won't be
> encrypted anyway, just the sensitive data like mail, documents,
> passwords and personal photos. So the requirements won't be high.
> However I might expand it to /, though that would involve a more
> complicated boot process (I never needed initrds except for bootsplash).
> 

I personally see no reason for encrypting root as there is nothing of
interest in there. I just encrypt home, certain /var/* sub-mounts and
other stuff. That way, you can use /etc/init.d/dmcrypt.Actually, I've
tweaked the setup so that I can have LVM on top of Luks. If you're
interested, I can share the change.

> On a sidenote, While I was cleaning up unread mails in the ML, I just
> found your interesting frontswap/zcache trick.
> 
> I wonder how many years I'd have to use the device to get back the time
> from improved performance that I spent setting it up in the first place.
> :-D
> 

Consider it experience. ;-)

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags

[Walter Dnes]

On Tue, Dec 11, 2012 at 06:36:47PM +0100, Frank Steinmetzger wrote

> * I???m interested in the question of -O2 vs. -Os.
>   Some sources say -Os is bad, b/c it breaks debugging and is mainly
>   untested.  I won???t do heavy developing on it anyway, and Atoms do
>   have a puny cache.  So I wonder whether -Os would improve execution
>   time and RAM usage noticably.  Diskspace itself is not an issue.

  I do builds on the netbook.  My generic make.conf CFLAGS line is...

CFLAGS="-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables"

...on my machines.  "-fno-unwind-tables -fno-asynchronous-unwind-tables"
reverses a "new and improved feature" of GCC that bloats the busybox
binary (and presumably other binaries) 15% to 20%.  See the short thread
http://lists.busybox.net/pipermail/busybox/2012-September/078326.html
for background.  The busybox developers obviously want to reduce every
bit of disk and/or ram usage, because busybox is used in a lot of ram
and disk constrained embedded systems.

  I don't know if it's possible to easily add another gig of ram.  It
would certainly help.  I have an ancient netbook.  It has 2 gigs of ram,
but is restricted to 32-bit only.

  BTW, does the netbook jave a Poulsbo GPU?  There are some hints at the
Arch wiki https://wiki.archlinux.org/index.php/Poulsbo for getting it to
work better.  I can get HD Youtube videos to play in the "large player",
but my machine has 2 gigs of ram.  If it's a relatively new Gentoo install,
I recommend...

emerge system && emerge world

...to get the most optimization.  Also, build the "ondemand" cpu
governor and enable it (emerge cpufrequtils).  This will enable the
higher CPU speeds.  I think my machine was originally stuck at its
lowest CPU frequency due to the "powersave" governor, even with the
machine plugged into the wall for power.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]

On Wed, 12 Dec 2012 09:16:58 +0100, Florian Philipp wrote:

> I personally see no reason for encrypting root as there is nothing of
> interest in there.

No passwords in /etc? The main reason I encrypt / is that wicd keeps its
passwords in /etc.


-- 
Neil Bothwick

DOS never says "EXCELLENT command or filename"...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 384 bytes --]

Am 12.12.2012 10:40, schrieb Neil Bothwick:
> On Wed, 12 Dec 2012 09:16:58 +0100, Florian Philipp wrote:
> 
>> I personally see no reason for encrypting root as there is nothing of
>> interest in there.
> 
> No passwords in /etc? The main reason I encrypt / is that wicd keeps its
> passwords in /etc.
> 
> 

I substitute with symlinks to /var/lib/*, /srv/* or similar.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

On Wed, 12 Dec 2012 18:41:03 +0100, Florian Philipp wrote:

> >> I personally see no reason for encrypting root as there is nothing of
> >> interest in there.  
> > 
> > No passwords in /etc? The main reason I encrypt / is that wicd keeps
> > its passwords in /etc.
> >  
> 
> I substitute with symlinks to /var/lib/*, /srv/* or similar.

I used to do that, although I linked to /home/etc, but I found myself
adding more and more and worried about missing something important. So I
decided to learn how to create an initramfs and now have all but /boot
(and sometimes /usr) encrypted.


-- 
Neil Bothwick

Top Oxymorons Number 5: Twelve-ounce pound cake

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags

[Volker Armin Hemmann]

Am Mittwoch, 12. Dezember 2012, 02:40:04 schrieb Frank Steinmetzger:
> On Tue, Dec 11, 2012 at 09:20:55PM +0100, Florian Philipp wrote:
> > > * From my observations, the benefit of 64 bit over 32 is much smaller
> > > for an> > 
> > >   Atom than it is for my Core2.  Am I right to assume thus that the Atom
> > >   architecture doesn’t have much to offer to 64 bit (such as extra
> > >   registers)? I’m not talking about memory here, since it’s limited to
> > >   2 GB in any case.> 
> > It has the same set of registers as your Core2.
> 
> Incidentally, when I initially set up the netbook, the output of
> gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p'
> (which floated around the ML in the past) implied core2, IIRC.
> 
> > It's just that the Atom micro-architecture is terrible with regard to
> > 64bit. That's just about the only reason that x32 was invented (and
> > now that I've said it, I'm just waiting for the flamewar about it).
> 
> Terrible in what way? Inadequate memory throughput? I didn't know x32,
> but from what I've read in the last few minutes it sounds intriguing.

terrible at dealing with 64bit numbers. Terrible at everything pretty much.
-- 
#163933

Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags

[Frank Steinmetzger]

[-- Attachment #1: Type: text/plain, Size: 2486 bytes --]

On Wed, Dec 12, 2012 at 09:16:58AM +0100, Florian Philipp wrote:

> >>> * The last thing I’m going to set up is filesystem encryption, at least for ~.
> >>>   I already know/think that AES would be the best choice due to limited CPU
> >>>   power, but what else is there to heed besides key size?
> >>
> >> Nothing, you're good. Hash and key chaining method have negligible
> >> impact. If you stick with an x86_32 userspace I suggest at least using
> >> an x64 kernel so you can use of CRYPTO_AES_X86_64.
> > 
> > That's an interesting idea.
> >> [...] 
> > I haven't done any comparisons of 32/64 crypto yet, I'm just reading
> > docs on Luks (never used it before).

Well now, I did a few comparisons yesterday. Not much---just permutated a few
of the most probable crypto combinations (aes/twofish, cbc/xts, essiv/plain).
I created the LUKS container, opened it and gave it a spin with hdparm -t.

The result was shocking and outrageous; reported throughput w/o encryption was
75 MB/s, which is your typical 5400 rev laptop HDD.  First I was disappointed
when I saw what aes-cbc-essiv gave me on 32 bit: a mere 19 and a bit.  But on
64 bit, it yielded a whopping 34 MB/s.  I had a hunch and booted the 32 bit
system with the 64 bit kernel---and throughput stayed high as expected.

So for the sake of simplicity (and to give it a rest after two weeks of ricing
to the day), I will use the 32 bit userland with a 64 bit kernel.  I will only
need to set up some magic (a multilib crossdev gcc and separate build dirs) so
I can build both kernels with their separate configs from the same source dir.

> I personally see no reason for encrypting root as there is nothing of
> interest in there.

Hm ideed, the only password I have in a plaintext config file are WiFi
passwords vor wpa and vpnc.  For those the symlink solution could be used.
Not needing an initrd is a big incentive. :)

> > On a sidenote, While I was cleaning up unread mails in the ML, I just
> > found your interesting frontswap/zcache trick.

I tried that, too, but for now will keep it disabled---simple copying of big
files was slowed down to 33 MB/s, obviously b/c the cache is constantly being
changed.  It's just not suitable for little Atoms.
-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any Facebook service.

The duration of a minute is relative.
It depends on the side of the toilet door you are standing on.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]