Gentoo Archives: gentoo-user

From: Norman Invasion <invasivenorman@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags
Date: Tue, 11 Dec 2012 19:41:41
Message-Id: CAJoTvCt8cR+XbmdMHKDD0UHBsmjEcQ_2VUnzRknQrfavkE-Azw@mail.gmail.com
In Reply to: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags by Frank Steinmetzger
1 On 11 December 2012 12:36, Frank Steinmetzger <Warp_7@×××.de> wrote:
2 > Hello list
3 . . .
4 > So I’m interested in you opinion and own experience about the following
5 > arising questions:
6 >
7 > * From my observations, the benefit of 64 bit over 32 is much smaller for an
8 > Atom than it is for my Core2. Am I right to assume thus that the Atom
9 > architecture doesn’t have much to offer to 64 bit (such as extra registers)?
10 > I’m not talking about memory here, since it’s limited to 2 GB in any case.
11 >
12 > * The problem of distcc between different architectures:
13 > The netbook already had an older 32 bit Gentoo installed. And since I have
14 > a multilib host (march=core2), I though I could upgrade with distcc (using
15 > march=atom on the netbook). But at some point more and more stuff stopped
16 > working, eventually I got “invalid instruction” errors during emerge, hence
17 > I figured that was a dead end.
18 >
19 > So is it possible to mix architectures in this way at all with distcc?
20 > I also have crossdev for i686 installed, which even shares files with the
21 > system’s normal multilib gcc. I find that odd.
22 > I sped up the installation process for 32 bit by using a chroot on the big
23 > machine, which worked nicely. But it’s not a long-term solution, b/c it
24 > uses up too much disk space on the host.
25 >
26 > * I’m interested in the question of -O2 vs. -Os.
27 > Some sources say -Os is bad, b/c it breaks debugging and is mainly untested.
28 > I won’t do heavy developing on it anyway, and Atoms do have a puny cache.
29 > So I wonder whether -Os would improve execution time and RAM usage
30 > noticably. Diskspace itself is not an issue.
31 >
32 > * I’m also interested in comparing bin packages over self-compiled ones.
33 > E.g. I did compile icedtea, even if it’s just for TV browser. :)
34 > Can you name a Java benchmark to measure CPU performance?
35 >
36 > * The last thing I’m going to set up is filesystem encryption, at least for ~.
37 > I already know/think that AES would be the best choice due to limited CPU
38 > power, but what else is there to heed besides key size?
39 >
40 > * What other small benchmarks for CPU and memory can you recommend? So far I
41 > tested with nbench and sysbench. The results are so-and-so. Some computation
42 > stuff is much slower on 64 bit, some a bit faster. The applicability to
43 > every-day use is of course a wibbly-wobbly argument.
44 > I also tested the runtime of some application (packing and unpacking of
45 > archives, throughput with dd, mencoder). If there is interest, I can post
46 > the result of 21 runs on each platform, measured with GNU time.
47 >
48 > ----------[ Questions end ]--------------------------------------------------
49 >
50 >
51 > PS.: I’m aware that benchmarks are always a bit subjective and none is
52 > perfect. I also realise that most of the questions quite belong into the
53 > ricer corner. But Netbooks are ricer devices, b/c they need to perform at
54 > their limits all the time. :-D
55 >
56
57 I have an old N280 atom netbook, so the 64v32 is moot
58 for me, but with a hardware limit of 2G, I'd probably run
59 32-bit. I don't use distcc, either, since I'd rather not
60 saturate my (802.11g) wireless network.
61
62 -Os, in my experience, makes very little difference on
63 amd64/x86_64/whate'er (FreeBSD 9.x amd64 clang
64 the final sizes of the binaries between -Os & -O3 have
65 very little bearing on expectations), however the atom
66 seems to benefit quite a lot more from the smaller
67 binaries, which on 32-bit (again in my experience
68 with gentoo gcc46 i686) are significantly smaller than
69 -O2 & -O3 binaries. I would assume this has to do
70 with cache fit.
71
72 Some suggest using -mfpmath=sse, which I've not
73 studied in depth. But if the x87 bits are particularly
74 slow on the atom (mind you, I have no idea), & you're
75 not running stuff that makes heavy use of your sse
76 registers I don't see a downside.
77
78 64-bit probably won't help much at all, unless you're
79 running really numbery stuff. I suggest unless you're
80 doing video editing or scientific number crunching
81 (on your atom netbook) 32 will be fine.