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 360D11381F3 for ; Tue, 11 Dec 2012 20:22:29 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4A34F21C07B; Tue, 11 Dec 2012 20:22:14 +0000 (UTC) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id EE2B321C040 for ; Tue, 11 Dec 2012 20:21:03 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8EFAF203BF for ; Tue, 11 Dec 2012 15:21:03 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 11 Dec 2012 15:21:03 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=binarywings.net; h=message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type; s=mesmtp; bh=r1ulVGhPWMvfgsIXz1KlJ2jw og8=; b=dhV+RW5Oj1pkfiWNYamp4SvFGIYDXquy755BUzXLFZzpjhV2r1YzEwm6 JeKczZsiKZXvEuia5rsKIfzNg3DVpzSH/KZtd/J7Rpl3ux0dSG5WicwBx7u/rUbX Afde+3h4RfCgBagrewM5KFGSQL6FW/zheU6FhD49DWpM3OLg8WE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type; s=smtpout; bh=r1ul VGhPWMvfgsIXz1KlJ2jwog8=; b=q/NdC2Cv9MuUvTfhXvlVIAPfSHzdjc4NYVD/ YKKvgyrkzc5SLe/OMEAx0e3pjkfa+6npPLRXn/NJmmKLAn0uwR3MeWV8y3385BL1 SJnEE8EILId6ZmzFrkyGcJSkXllA4myCgOiuRU5qfNKi+dMLAUT8RvEDdieAgpw/ W3nFu0Q= X-Sasl-enc: 26Gx4DwMoWHt/ttGYqOBFAXtclbn5N41wJHGsYRHZBsH 1355257262 Received: from [192.168.5.18] (unknown [83.169.5.6]) by mail.messagingengine.com (Postfix) with ESMTPA id C706C4827CB for ; Tue, 11 Dec 2012 15:21:01 -0500 (EST) Message-ID: <50C795A7.4070501@binarywings.net> Date: Tue, 11 Dec 2012 21:20:55 +0100 From: Florian Philipp User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121130 Thunderbird/10.0.11 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 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Intel Atom: architecture, distcc, crossdev and compile flags References: <20121211173647.GA32351@eisen.lan> In-Reply-To: <20121211173647.GA32351@eisen.lan> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig594A2441A91E97FFDEA7B1A0" X-Archives-Salt: b0ddaba0-e371-43d8-9c4b-1408c4c0ff6b X-Archives-Hash: 96a61b316bf70bc2df8cdd050b64fabd This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig594A2441A91E97FFDEA7B1A0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 11.12.2012 18:36, schrieb Frank Steinmetzger: > Hello list >=20 > Long time no read... :) >=20 > It follows a verbose preamble. For the actual questions see dashed lin= e below. > TL;DR summary: it=E2=80=99s all about ricer-performance questions on a = netbook. >=20 >=20 > I have the luck of having obtained a used netbook for free (Atom N450, = single- > core with HT, 1 GB memory, 5400 rev HDD). During the last week I=E2=80= =99ve been > experimenting with 32 and 64 bits on it and am still quite undecided wh= ich to > keep. My reasons: >=20 > - They are not as far apart in CPU performance as is the Core2. > I posted a 32/64 comparison for Core2 a few months ago, which showed = that > Lilypond speedup on 64 bit was 50%. On the Atom, it actually took 5% = longer. > (Sadly, Blender doesn=E2=80=99t build on 32 bit right now). > - Startup times for hogs like Firefox and KDE are quite equal between t= he two > (that could be attributed in parts to the fact that the 64 bit partit= ion > sits on the disk=E2=80=99s first sectors, while 32 bit sits at the ot= her end, I > don=E2=80=99t know which end is faster). The first part (which actually is the outer edge of the physical disk). > - pro 64: it is very easy to use distcc, as opposed to 32 bits (see bel= ow). > - con 64: it uses about 50% more memory, 32 bit builds are a little fas= ter. >=20 > The RAM argument is the most convincing one right now, since more free = RAM > means more cache, which means a faster system in the long run. Currentl= y, KDE > after logon needs 150 MB on 32 bit, and 250 MB on 64 bit (without akona= di for > now). But awesome WM rocks on a netbook anyway. >=20 >=20 > ----------[ Questions begin ]------------------------------------------= ------ >=20 > So I=E2=80=99m interested in you opinion and own experience about the f= ollowing > arising questions: >=20 > * From my observations, the benefit of 64 bit over 32 is much smaller f= or an > Atom than it is for my Core2. Am I right to assume thus that the Ato= m > architecture doesn=E2=80=99t have much to offer to 64 bit (such as ex= tra registers)? > I=E2=80=99m not talking about memory here, since it=E2=80=99s limited= to 2 GB in any case. >=20 It has the same set of registers as your Core2. It's just that the Atom micro-architecture is terrible with regard to 64bit. That's just about the only reason that x32 was invented (and now that I've said it, I'm just waiting for the flamewar about it). > * 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 = stopped > working, eventually I got =E2=80=9Cinvalid instruction=E2=80=9D error= s during emerge, hence > I figured that was a dead end. >=20 > 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=E2=80=99s normal multilib gcc. I find that odd. I don't think you can mix x86_32 and x64 easily but I've never tried. Did you try adding a CFLAGS=3D"-m32"? From comparing `gcc -Q --help=3Dtar= get -march=3Dxxx` they should be compatible. > I sped up the installation process for 32 bit by using a chroot on th= e big > machine, which worked nicely. But it=E2=80=99s not a long-term solut= ion, b/c it > uses up too much disk space on the host. >=20 I do the same using NFS, bind mounts and tmpfs. What do you mean by disk space? If you can use common CFLAGS, you could try installing binary packages from your build host on your netbook (use quickpkg and friends).= > * I=E2=80=99m interested in the question of -O2 vs. -Os. > Some sources say -Os is bad, b/c it breaks debugging and is mainly un= tested. > I won=E2=80=99t 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. >=20 I use -Os but have no data to back it up (I'm also using an older Atom). Gentoo wiki suggests using "-O2 -fno-reorder-blocks -fno-reorder-functions" as a compromise. > * I=E2=80=99m also interested in comparing bin packages over self-compi= led ones. > E.g. I did compile icedtea, even if it=E2=80=99s just for TV browser.= :) > Can you name a Java benchmark to measure CPU performance? >=20 How about something from this site: http://shootout.alioth.debian.org/ > * The last thing I=E2=80=99m 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? >=20 Nothing, you're good. Hash and key chaining method have negligible impact. If you stick with an x86_32 userspace I suggest at least using an x64 kernel so you can use of CRYPTO_AES_X86_64. > * 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 comp= utation > 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. >=20 How about trying some browser benchmarks. Check out the following for different aspects: http://ie.microsoft.com/testdrive/performance/mazesolver/default.html http://www.webkit.org/perf/sunspider/sunspider.html http://peacekeeper.futuremark.com/run.action There is also a Qt render benchmark http://code.google.com/p/qtperf/ Check out app-admin/eselect-qtgraphicssystem and see how they compare in appearance and numbers. Regards, Florian Philipp --------------enig594A2441A91E97FFDEA7B1A0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDHlasACgkQqs4uOUlOuU/LFgCeJiGPiyaIL/kZf7uxRN9WrqVu UyIAnRuZD8LdgrE43Ph6YBiZ3fO9MoxI =YJyB -----END PGP SIGNATURE----- --------------enig594A2441A91E97FFDEA7B1A0--