Duncan wrote: >>Athlon64 something (forgot what, but shouldn't matter anyway) with 1 MB >>L2-cache is 4% faster than an Athlon64 of the same frequency but with only >>512kB >>L2-cache. The bigger the cache sizes you compare get, the smaller the >>performance increase. Since you run a dual Opteron system with 1 MB L2 >>cache per CPU I tend to say that the actual performance increase you >>experience is about 3%. But then I didn't take into account that -Os >>leaves out a few optimizations which would be included by -O2, the >>default optimization level, which actually makes the code a bit slower >>when compared to -O2. So, the performance increase you really experience >>shrinks to about 0-2%. I'd tend to proclaim that -O2 is even faster for >>most of the code, but that's only my feeling. > > > Interesting, indeed. I'd counter that it likely has to do with how many > tasks are being juggled as well, plus the number of kernel/user context > switches, of course. I wonder under what load, and with what task-type, > the above 4% difference was measured. > > Of course, the definitive way to end the argument would be to do some > profiling and get some hard numbers, but I don't think either you or I > consider it an important enough factor in our lives to go to /that/ sort > of trouble. <g>
Indeed, I'd rather say I have no clue than go and perform tests :D >>You are referring a lot to the gcc manpage, but obviously you missed >>this part: >> >> -fomit-frame-pointer >> Don't keep the frame pointer in a register for functions that >> don't need one. This avoids the instructions to save, set up >> and restore frame pointers; it also makes an extra register >> available in many functions. It also makes debugging >> impossible on some machines. >> >> On some machines, such as the VAX, this flag has no effect, >> because the standard calling sequence automatically handles >> the frame pointer and nothing is saved by pretending it >> doesn't exist. The machine-description macro >> "FRAME_POINTER_REQUIRED" controls whether a target machine >> supports this flag. >> >> Enabled at levels -O, -O2, -O3, -Os. >> >>I have to say that I am a bit disappointed now. You seemed to be one of >>those people who actually inform themselves before sticking new flags >>into their CFLAGS. > > > ?? > > I'm not sure which way you mean this. It was in my CFLAGS list, but I > didn't discuss it as it's fairly common (from my observation, nearly as > common as -pipe) and seems fairly non-controversial on Gentoo. Did you > miss it in my CFLAGS and are saying I should be using it, or did you see > it and are saying its unnecessary and redundant because it's enabled by > the -Os? > > If the latter, yes, but as mentioned above in the context of glibc, -Os is > sometimes stripped. In that case, the redundancy of having the basic > -fomit-frame-pointer is useful, unless it's also stripped, but as I said, > it seems much less controversial than some flags and is often > specifically allowed where most are stripped. > Or, are you saying I should avoid it due to the debugging implications? I > don't quite get it. On amd64 frame-pointers aren't needed to do debugging, so that's > >>>!!! Relying on the shell to locate gcc, this may break !!! DISTCC, >>>installing gcc-config and setting your current gcc !!! profile will fix >>>this >>> >>>Another warning, likewise to stderr and thus not in the eis output. >>>This one is due to the fact that eselect, the eventual systemwide >>>replacement for gcc-config and a number of other commands, uses a >>>different method to set the compiler than gcc-config did, and portage >>>hasn't been adjusted to full compatibility just yet. Portage finds the >>>proper gcc just fine for itself, but there'd be problems if distcc was >>>involved, thus the warning. >> >>Didn't know about this. Have you filed a bug yet on the topic? Or is >>there already one? > > > There is one. I don't recall if I filed it or if it was already there, > but both JH and the portage folks know about the issue. IIRC, the portage > folks decided it was their side that needed changed, but that required > changes to the distcc package, and I don't know how that has gone since I > don't use distcc, except that I was slightly surprised to see the warning > in portage 2.1 still. > > >>>MAKEOPTS="-j4" >>> >>>The four jobs is nice for a dual-CPU system -- when it works. >>>Unfortunately, the unpack and configure steps are serialized, so the >>>jobs option does little good, there. To make most efficient use of the >>>available cycles when I have a lot to merge, therefore, I'll run as >>>many as five merges in parallel. I do this quite regularly with KDE >>>upgrades like the one to 3.5.1, where I use the split KDE ebuilds and >>>have something north of 100 packages to merge before KDE is fully >>>upgraded. >> >>I really wonder how you would paralellize unpacking and configuring a >>package. > > > That's what was nice about configcache, which was supposed to be in the > next portage, but I haven't seen or heard anything about it for awhile, > and the next portage, 2.1, is what I'm using. configcache seriously > shortened that stage of the build, leaving more of it parallelized, but... > > I was using it for awhile, patching successive versions of portage, but it > broke about the time sandbox split, the dev said he wasn't maintaining the > old version since it was going in the new portage, and I tried updating > the patch but eventually ran into what I think were unrelated issues but > decided to drop that in one of my troubleshooting steps and never picked > it up again. > > I'd certainly like to have it back again, tho. If it's working in 2.1, > I've not seen it documented or seen any hints in the emerge output, as > were there before. You seen or heard anything? > > BTW, what is your opinion on -ftracer? Several devs I've noticed use it, > but the manpage says it's not that useful without active profiling, which > means compiling, profiling, and recompiling, AFAIK. It's possible the > devs running it do that, but I doubt it, and otherwise, I don't see that > it should be that useful? I don't know if you run it, but since I've got > your attention, I thought I'd ask what you think about it. Is there > something of significance I'm missing, or are they, or are they actually > doing that compile/profile/recompile thing? It just doesn't make sense to > me. I've seen it in several user posted CFLAGS as well, but I'll bet a > good portion of them are simply because they saw it in a dev's CFLAGS and > decided it looked useful, not because they understand any implications > stated in the manpage. (Not that I always do either, but... <g>) > -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- [email protected] mailing list
