From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 62A281381F3 for ; Tue, 11 Dec 2012 19:41:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 09EE521C05D; Tue, 11 Dec 2012 19:41:26 +0000 (UTC) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4989021C010 for ; Tue, 11 Dec 2012 19:40:17 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id 16so13944726iea.40 for ; Tue, 11 Dec 2012 11:40:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=/iGEgCrKdB435SNAy/+K55HUgoJi2M8IMkG8AMCaY5Q=; b=Iy6KXnMeOXGPJ336D5Y399z00dK8RNVf744CgmyyUKHd1rjO6p7PeXwmqNRcXbSJX+ Awbf+yCCut07rAQQigRfoUPpMojOtjqk8X2RhJf4Mfkr6VFgKSh7TNe+aUSBPZ3dHlS4 jxWJXexnIpbQIpY3SsIout0mD6ep0JLUzFidxlia99FBhT3HRf1fdBc8KY1NyLYRSgrj 26aBBLbwbJ6QWFSj8VpgB/7wosvp0QSuDWC1PdF6XLJZyC7WyqHfop6cGoXXu+Y0aIOT ZKpCbZ7H1R9nJRASDFRfjvUteEGbqv4TVtM58+iKi9ltZigqd53obxDpxcO7sV9c4jud mOxw== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.43.119.5 with SMTP id fs5mr14910958icc.14.1355254816504; Tue, 11 Dec 2012 11:40:16 -0800 (PST) Received: by 10.50.10.134 with HTTP; Tue, 11 Dec 2012 11:40:16 -0800 (PST) In-Reply-To: <20121211173647.GA32351@eisen.lan> References: <20121211173647.GA32351@eisen.lan> Date: Tue, 11 Dec 2012 14:40:16 -0500 Message-ID: Subject: Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags From: Norman Invasion To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 22f47aaf-d301-4c1e-902c-749e3be23b0d X-Archives-Hash: 594dca7b1511b1d401f248b395924027 On 11 December 2012 12:36, Frank Steinmetzger wrote: > Hello list . . . > So I=92m 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=92t have much to offer to 64 bit (such as extra regi= sters)? > I=92m not talking about memory here, since it=92s limited to 2 GB in an= y 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=3Dcore2), I though I could upgrade with distcc (= using > march=3Datom on the netbook). But at some point more and more stuff st= opped > working, eventually I got =93invalid instruction=94 errors during emerg= e, 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 t= he > system=92s 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=92s not a long-term solution, b/c= it > uses up too much disk space on the host. > > * I=92m interested in the question of -O2 vs. -Os. > Some sources say -Os is bad, b/c it breaks debugging and is mainly unte= sted. > I won=92t do heavy developing on it anyway, and Atoms do have a puny ca= che. > So I wonder whether -Os would improve execution time and RAM usage > noticably. Diskspace itself is not an issue. > > * I=92m also interested in comparing bin packages over self-compiled ones= . > E.g. I did compile icedtea, even if it=92s just for TV browser. :) > Can you name a Java benchmark to measure CPU performance? > > * The last thing I=92m going to set up is filesystem encryption, at least= for ~. > I already know/think that AES would be the best choice due to limited C= PU > power, but what else is there to heed besides key size? > > * What other small benchmarks for CPU and memory can you recommend? So f= ar I > tested with nbench and sysbench. The results are so-and-so. Some comput= ation > stuff is much slower on 64 bit, some a bit faster. The applicability t= o > 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 p= ost > the result of 21 runs on each platform, measured with GNU time. > > ----------[ Questions end ]----------------------------------------------= ---- > > > PS.: I=92m 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 a= t > 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=3Dsse, 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.