On Sun, Dec 18, 2011 at 12:45:27PM +0200, Nikos Chantziaras wrote > > On 12/18/2011 12:34 PM, Walter Dnes wrote: > > > > This was only recently installed. Is it possible that the generic x86 > > code from the initial install was the problem? And that emerging > > system+world got me full optimization? > > Could be. It could also be it's because of "-mfpmath=sse". That's only > used by default on 64-bit. On 32-bit, the FPU is used for floating > point operations by default, which gives better precision (80 bit vs 64 > bit) but slower speed. > > But then again, that sounds too much of a performance difference. So if > I had to guess, I'd say it's because of the world rebuild that made sure > everything was built with proper optimizations.
It's probably the sum total of the effect of all the flags. I've renamed the thread, to be more accurate. Here's how things went... * right after the install (presumably with generic i686 code) the PC could not handle streaming 1080i video from my HDHomerun TV tuner * I misinterpreted output from gcc diagnostics, and concluded that "march=-native" left several flags disabled that shouldn't be * acting on that (mis)information), I emerged system+world+kernel and found that not only could my system handle 1080i, it could handle a 1080p Youtube clip without problems, after a lot of buffering. My 5 megabit ADSL connection was the limiting factor there. It's supposed to be upgraded to 6 megabits one of these days, for some minor improvement. * I mistakenly thought that it was the additional flags in CFLAGS during the emerge system+world that boosted the video. Actually, the emerge would've done the trick. The lesson from this is that, before doing any benchmarking or heavy-duty usage, one should emerge system+world, to replace the generic code from the install CD with fully optimized code. It's easiest to so right after the initial install, so that there are as few packages to emerge as possible. -- Walter Dnes <[email protected]>
