public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Frank Steinmetzger <Warp_7@gmx.de>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] cflags for atom
Date: Tue, 22 Oct 2013 04:20:12 +0200	[thread overview]
Message-ID: <20131022022011.GN2497@nukleus.Speedport_W723_V_Typ_A_1_00_098> (raw)
In-Reply-To: <CAC=wYCHQgRGz4OesY-3Z-99npurEmZRVhGQMe4gUVb1nrg_jGA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]

On Tue, Oct 22, 2013 at 11:45:35AM +1100, Adam Carter wrote:
> If you havent already, I would first verify that its actually CPU bound,
> before changing CFLAGs and recompiling everything. So take a look at top,
> vmstat, mpstat etc when you're noticing slowness. If it is truely CPU bound
> and you're going to recompile everything, you could consider upgrading to
> the ~ version of gcc first, with the assumption that the optimizations
> maybe be better. However, my gut feeling is that you wont get much or any
> improvement over your current CFLAGs.
> 
> The i686 and -Os ideas are interesting. See if you can find any benchmarks.
> 
> Also - try diffing the kernel .configs - maybe you missed something
> important on the slow system.

Interestingly, I did carry out tests when I received my netbook in order
to decide between 32 and 64 bit. I did the same tests when I migrated my
big laptop from 32 to 64 bit, but I can't remember the results for the
netbook anymore except for LUKS performance:
the aforementioned hdparm -t on my encrypted /home amounts to 18 MB/s on
32 bit, but reaches almost 30 MB/s with 64 bit. In the end, I went for a
64 bit kernel to increase some computing performance, and 32 bit for all
the rest for memory reasons. The only additional "cost" is that I have
to maintain a 64 bit toolchain via crossdev.
-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any Facebook service.

Arrogance is the art of being proud of one’s own stupidity.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2013-10-22  2:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-21 14:09 [gentoo-user] cflags for atom Silvio Siefke
2013-10-21 14:33 ` thegeezer
2013-10-21 15:08   ` Silvio Siefke
2013-10-21 15:15 ` Frank Steinmetzger
2013-10-21 16:09   ` Silvio Siefke
2013-10-21 16:40     ` Frank Steinmetzger
2013-10-21 16:54       ` housegregory299
2013-10-21 15:20 ` Joseph
2013-10-21 15:40   ` Frank Steinmetzger
2013-10-22  0:31 ` Alecks Gates
2013-10-22  0:45   ` Adam Carter
2013-10-22  2:20     ` Frank Steinmetzger [this message]
2013-10-22 12:40     ` [gentoo-user] " James

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131022022011.GN2497@nukleus.Speedport_W723_V_Typ_A_1_00_098 \
    --to=warp_7@gmx.de \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox