On Mon, Dec 19, 2011 at 12:15 AM, Dale <[email protected]> wrote: > Pandu Poluan wrote: >> >> >> Kind of like what I always do when I switch from -march=nocona to >> -march=native. (Usually I use -march=nocona to ensure seamless VM migration >> on my XenServer-equipped boxen, but for some VMs, i.e., those requiring me >> to wring out every last drop of performance, I go native.) >> >> That said, if you want to experience fully the "GCC Graphite" >> optimizations, you'll also want to do emerge -ev ;-) >> >> Rgds, >> > > > Is Graphite worthwhile on a desktop system or is it better suited for > servers or both? I found this but still not sure what it is intended for: > > http://gcc.gnu.org/wiki/Graphite/4.5 > > Are there any reasons to leave this be for a while? You know, bugs or > packages that don't work with it?
I used it for @world and ran into a couple times when things were broken with it enabled... Don't really remember specifics. I didn't notice any perceivable speed difference, so I stopped using it just to simplify things in the future. :) In general,I have changed my CFLAGS to be less aggressive over the past years. I started with the most aggressive optimizations, and using -march=whatever... At some point I researched compile times for different optimizations and realized some packages were taking tens of minutes longer to compile! Surely whatever potential speed increase of -O3 vs -O2 was not going to give me tens of minutes cumulatively. If there is a package that really benefits from some specific optimization (and doesn't already set those flags itself in the ebuild), I'll set the CFLAGS for that individual package but leave the rest of world very simplistic. Same with -march, I've gone to using -mtune instead, after having to move hard drives into a system with different CPU feature set. And for virtual machines (in hosts I don't control, especially), they could be migrated to some other machine without my knowledge, and i don't want it to stop working if that happens.
