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

[Frank Steinmetzger <Warp_7@gmx.de>]

[-- 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 --]