| 1 |
On Tue, Oct 22, 2013 at 11:45:35AM +1100, Adam Carter wrote: |
| 2 |
> If you havent already, I would first verify that its actually CPU bound, |
| 3 |
> before changing CFLAGs and recompiling everything. So take a look at top, |
| 4 |
> vmstat, mpstat etc when you're noticing slowness. If it is truely CPU bound |
| 5 |
> and you're going to recompile everything, you could consider upgrading to |
| 6 |
> the ~ version of gcc first, with the assumption that the optimizations |
| 7 |
> maybe be better. However, my gut feeling is that you wont get much or any |
| 8 |
> improvement over your current CFLAGs. |
| 9 |
> |
| 10 |
> The i686 and -Os ideas are interesting. See if you can find any benchmarks. |
| 11 |
> |
| 12 |
> Also - try diffing the kernel .configs - maybe you missed something |
| 13 |
> important on the slow system. |
| 14 |
|
| 15 |
Interestingly, I did carry out tests when I received my netbook in order |
| 16 |
to decide between 32 and 64 bit. I did the same tests when I migrated my |
| 17 |
big laptop from 32 to 64 bit, but I can't remember the results for the |
| 18 |
netbook anymore except for LUKS performance: |
| 19 |
the aforementioned hdparm -t on my encrypted /home amounts to 18 MB/s on |
| 20 |
32 bit, but reaches almost 30 MB/s with 64 bit. In the end, I went for a |
| 21 |
64 bit kernel to increase some computing performance, and 32 bit for all |
| 22 |
the rest for memory reasons. The only additional "cost" is that I have |
| 23 |
to maintain a 64 bit toolchain via crossdev. |
| 24 |
-- |
| 25 |
Gruß | Greetings | Qapla’ |
| 26 |
Please do not share anything from, with or about me with any Facebook service. |
| 27 |
|
| 28 |
Arrogance is the art of being proud of one’s own stupidity. |
Archives