1 |
On Tue, Dec 11, 2012 at 09:20:55PM +0100, Florian Philipp wrote: |
2 |
|
3 |
> > * From my observations, the benefit of 64 bit over 32 is much smaller for an |
4 |
> > Atom than it is for my Core2. Am I right to assume thus that the Atom |
5 |
> > architecture doesn’t have much to offer to 64 bit (such as extra registers)? |
6 |
> > I’m not talking about memory here, since it’s limited to 2 GB in any case. |
7 |
> > |
8 |
> |
9 |
> It has the same set of registers as your Core2. |
10 |
|
11 |
Incidentally, when I initially set up the netbook, the output of |
12 |
gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p' |
13 |
(which floated around the ML in the past) implied core2, IIRC. |
14 |
|
15 |
> It's just that the Atom micro-architecture is terrible with regard to |
16 |
> 64bit. That's just about the only reason that x32 was invented (and |
17 |
> now that I've said it, I'm just waiting for the flamewar about it). |
18 |
|
19 |
Terrible in what way? Inadequate memory throughput? I didn't know x32, |
20 |
but from what I've read in the last few minutes it sounds intriguing. |
21 |
|
22 |
> > So is it possible to mix architectures in this way at all with distcc? |
23 |
> > I also have crossdev for i686 installed, which even shares files with the |
24 |
> > system’s normal multilib gcc. I find that odd. |
25 |
> |
26 |
> I don't think you can mix x86_32 and x64 easily but I've never tried. |
27 |
> Did you try adding a CFLAGS="-m32"? From comparing `gcc -Q --help=target |
28 |
> -march=xxx` they should be compatible. |
29 |
|
30 |
Not yet, putting in on todo, as it would involve building, running, |
31 |
testing (or reading up on it :-p ). |
32 |
|
33 |
> > I sped up the installation process for 32 bit by using a chroot on the big |
34 |
> > machine, which worked nicely. But it’s not a long-term solution, b/c it |
35 |
> > uses up too much disk space on the host. |
36 |
> |
37 |
> I do the same using NFS, bind mounts and tmpfs. What do you mean by disk |
38 |
> space? |
39 |
|
40 |
That I don't have much space left on the host machine for the entire |
41 |
chroot. I bind-mount distfiles and portage, but I'm still running low |
42 |
on gigabytes. |
43 |
I was thinking of NFS quite early, but a friend said it would perform |
44 |
not nicely. Also, with all my cables currently occupied, the two are |
45 |
connected over a slow WiFi router. It's one of the rare cases in which |
46 |
compressing distcc traffic increases performance. :) The netbook has |
47 |
gigabit ethernet, though. Thank $DEITY for compressed tar pipes over |
48 |
SSH. I wonder what Windows people would do in such a situation. >:-] |
49 |
|
50 |
> If you can use common CFLAGS, you could try installing binary |
51 |
> packages from your build host on your netbook (use quickpkg and friends). |
52 |
|
53 |
Which brings me back to the disk space problem. Right now the 32 bit |
54 |
chroot is a direct mirror, which is rsynced to and fro when the netbook |
55 |
runs in 64 bit. Once I have a cable available I think I'll go with NFS. |
56 |
|
57 |
> > […] Can you name a Java benchmark to measure CPU performance? |
58 |
> |
59 |
> How about something from this site: |
60 |
> http://shootout.alioth.debian.org/ |
61 |
|
62 |
Will have a look-see. |
63 |
> |
64 |
> > * The last thing I’m going to set up is filesystem encryption, at least for ~. |
65 |
> > I already know/think that AES would be the best choice due to limited CPU |
66 |
> > power, but what else is there to heed besides key size? |
67 |
> |
68 |
> Nothing, you're good. Hash and key chaining method have negligible |
69 |
> impact. If you stick with an x86_32 userspace I suggest at least using |
70 |
> an x64 kernel so you can use of CRYPTO_AES_X86_64. |
71 |
|
72 |
That's an interesting idea. If I had a 32 bit userland, I would have to |
73 |
build new kernels on my big 64 laptop then, right? I don’t suppose I |
74 |
can simply mix chosts, such that I would have a multilib x86_64 |
75 |
gcc/binutils/glibc, but i686 everything else. |
76 |
|
77 |
I haven't done any comparisons of 32/64 crypto yet, I'm just reading |
78 |
docs on Luks (never used it before). Big stuff (videos, music) won't be |
79 |
encrypted anyway, just the sensitive data like mail, documents, |
80 |
passwords and personal photos. So the requirements won't be high. |
81 |
However I might expand it to /, though that would involve a more |
82 |
complicated boot process (I never needed initrds except for bootsplash). |
83 |
|
84 |
On a sidenote, While I was cleaning up unread mails in the ML, I just |
85 |
found your interesting frontswap/zcache trick. |
86 |
|
87 |
I wonder how many years I'd have to use the device to get back the time |
88 |
from improved performance that I spent setting it up in the first place. |
89 |
:-D |
90 |
|
91 |
> > * What other small benchmarks for CPU and memory can you recommend? |
92 |
> > […] |
93 |
> |
94 |
> How about trying some browser benchmarks. […] |
95 |
|
96 |
I could also use those to compare binary and source firefox (which is |
97 |
compiling in the chroot right now). |
98 |
|
99 |
> There is also a Qt render benchmark |
100 |
> http://code.google.com/p/qtperf/ |
101 |
> Check out app-admin/eselect-qtgraphicssystem and see how they compare in |
102 |
> appearance and numbers. |
103 |
|
104 |
Nice idea, since I'm a general Qt fanboy. |
105 |
|
106 |
So thanks a lot for the info so far, I'll try to digest it all tomorrow. |
107 |
Good night for now. *yaaaaawn* |
108 |
-- |
109 |
Gruß | Greetings | Qapla’ |
110 |
Please do not share anything from, with or about me with any Facebook service. |
111 |
|
112 |
Emacs is a great operating system, which only lacks a good editor. |