| 1 |
On Fri, Feb 24, 2012 at 03:13:07AM +0200, Nikos Chantziaras wrote |
| 2 |
|
| 3 |
> The speed gains of building for specific submodels of CPUs might |
| 4 |
> be there, but they're minimal. Benchmarks have shown (can't find |
| 5 |
> the article, it was on Phoronix) that after -march=i686 you get |
| 6 |
> diminishing returns. |
| 7 |
|
| 8 |
In that case, the benchmarks are useless. From my personal |
| 9 |
experience... a fresh i686 install on a 4 and 1/2 year old Dell with |
| 10 |
onboard Intel GPU was not able to keep up with the slowest available |
| 11 |
speed on NHL Gamecenter Live. Ditto for 1080i TV from my HDHomerun |
| 12 |
tuner box. After rebuilding system+world+kernel with "march=native", |
| 13 |
it works just fine for the above tasks. I'm not the only one to see |
| 14 |
this. See thread... |
| 15 |
"Slow not in sync movie playing with mplayer2, ffmpeg, x264 with intel core i5" |
| 16 |
starting Sun, 12 Feb 2012 on this list. |
| 17 |
|
| 18 |
As I mentioned in that thread |
| 19 |
> Optimizing one library may seem very minor, but it all adds up when |
| 20 |
> you optimize every library on your system. |
| 21 |
|
| 22 |
To get the full benefit of optimization, you need to optimize your |
| 23 |
entire system. The i686 code used for the install CD has to be generic |
| 24 |
lowest-common-denominator i686 code, in order to run on every 6-year-old |
| 25 |
i686 cpu out there. The tradeoff is that you lose the benefits of |
| 26 |
optimisation. |
| 27 |
|
| 28 |
-- |
| 29 |
Walter Dnes <waltdnes@××××××××.org> |
Archives