Gentoo Archives: gentoo-user

From: Joseph <syscon780@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags
Date: Tue, 11 Dec 2012 20:25:12
Message-Id: 20121211202312.GB14782@syscon7.inet
In Reply to: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags by Frank Steinmetzger
1 I have: Atom(TM) CPU 330 @ 1.60GHz
2 running it with:
3
4 CFLAGS="-march=core2 -O2 -pipe"
5 CXXFLAGS="${CFLAGS}"
6 MAKEOPTS="-j5"
7 CHOST="x86_64-pc-linux-gnu"
8
9 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.
10 It runs my asterisk and hylafax in remote location so I have to keep an eye on it :-/
11
12 --
13 Joseph
14
15
16 On 12/11/12 18:36, Frank Steinmetzger wrote:
17 >Hello list
18 >
19 >Long time no read... :)
20 >
21 >It follows a verbose preamble. For the actual questions see dashed line below.
22 >TL;DR summary: it’s all about ricer-performance questions on a netbook.
23 >
24 >
25 >I have the luck of having obtained a used netbook for free (Atom N450, single-
26 >core with HT, 1 GB memory, 5400 rev HDD). During the last week I’ve been
27 >experimenting with 32 and 64 bits on it and am still quite undecided which to
28 >keep. My reasons:
29 >
30 >- They are not as far apart in CPU performance as is the Core2.
31 > I posted a 32/64 comparison for Core2 a few months ago, which showed that
32 > Lilypond speedup on 64 bit was 50%. On the Atom, it actually took 5% longer.
33 > (Sadly, Blender doesn’t build on 32 bit right now).
34 >- Startup times for hogs like Firefox and KDE are quite equal between the two
35 > (that could be attributed in parts to the fact that the 64 bit partition
36 > sits on the disk’s first sectors, while 32 bit sits at the other end, I
37 > don’t know which end is faster).
38 >- pro 64: it is very easy to use distcc, as opposed to 32 bits (see below).
39 >- con 64: it uses about 50% more memory, 32 bit builds are a little faster.
40 >
41 >The RAM argument is the most convincing one right now, since more free RAM
42 >means more cache, which means a faster system in the long run. Currently, KDE
43 >after logon needs 150 MB on 32 bit, and 250 MB on 64 bit (without akonadi for
44 >now). But awesome WM rocks on a netbook anyway.
45 >
46 >
47 >----------[ Questions begin ]------------------------------------------------
48 >
49 >So I’m interested in you opinion and own experience about the following
50 >arising questions:
51 >
52 >* From my observations, the benefit of 64 bit over 32 is much smaller for an
53 > Atom than it is for my Core2. Am I right to assume thus that the Atom
54 > architecture doesn’t have much to offer to 64 bit (such as extra registers)?
55 > I’m not talking about memory here, since it’s limited to 2 GB in any case.
56 >
57 >* The problem of distcc between different architectures:
58 > The netbook already had an older 32 bit Gentoo installed. And since I have
59 > a multilib host (march=core2), I though I could upgrade with distcc (using
60 > march=atom on the netbook). But at some point more and more stuff stopped
61 > working, eventually I got “invalid instruction” errors during emerge, hence
62 > I figured that was a dead end.
63 >
64 > So is it possible to mix architectures in this way at all with distcc?
65 > I also have crossdev for i686 installed, which even shares files with the
66 > system’s normal multilib gcc. I find that odd.
67 > I sped up the installation process for 32 bit by using a chroot on the big
68 > machine, which worked nicely. But it’s not a long-term solution, b/c it
69 > uses up too much disk space on the host.
70 >
71 >* I’m interested in the question of -O2 vs. -Os.
72 > Some sources say -Os is bad, b/c it breaks debugging and is mainly untested.
73 > I won’t do heavy developing on it anyway, and Atoms do have a puny cache.
74 > So I wonder whether -Os would improve execution time and RAM usage
75 > noticably. Diskspace itself is not an issue.
76 >
77 >* I’m also interested in comparing bin packages over self-compiled ones.
78 > E.g. I did compile icedtea, even if it’s just for TV browser. :)
79 > Can you name a Java benchmark to measure CPU performance?
80 >
81 >* The last thing I’m going to set up is filesystem encryption, at least for ~.
82 > I already know/think that AES would be the best choice due to limited CPU
83 > power, but what else is there to heed besides key size?
84 >
85 >* What other small benchmarks for CPU and memory can you recommend? So far I
86 > tested with nbench and sysbench. The results are so-and-so. Some computation
87 > stuff is much slower on 64 bit, some a bit faster. The applicability to
88 > every-day use is of course a wibbly-wobbly argument.
89 > I also tested the runtime of some application (packing and unpacking of
90 > archives, throughput with dd, mencoder). If there is interest, I can post
91 > the result of 21 runs on each platform, measured with GNU time.
92 >
93 >----------[ Questions end ]--------------------------------------------------
94 >
95 >
96 >PS.: I’m aware that benchmarks are always a bit subjective and none is
97 >perfect. I also realise that most of the questions quite belong into the
98 >ricer corner. But Netbooks are ricer devices, b/c they need to perform at
99 >their limits all the time. :-D
100 >
101 >If you read until this point, thank you very much for your time. You get a
102 >unicorn as a reward: `^nn~
103 >--
104 >Gruß | Greetings | Qapla’
105 >Please do not share anything from, with or about me with any Facebook service.
106 >
107 >“Time is money” said the waiter and put the date on the bill.