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

[Norman Invasion <invasivenorman@gmail.com>]

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.