(Apologize the previous mail which is cut off badly.. I shouldn't write emails before having a sufficient amount of caffeine in my veins ;))
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? I was referring to the latter, yes. I was reading this mail because I finally found somebody who can even *explain* why he sticks to certain flags, which is pretty rare IMO, so I hoped you would also explain why -fomit-frame-pointer isn't needed when having -O? in CFLAGS. Don't get me wrong, there's no problem with having both in CFLAGS, but I know that way too many people have strange CFLAGS without having a clue what these flags actually do, and usually you can expose them by grepping their CFLAGS for -fomit-frame-pointer. > 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. AFAIK the toolchain eclass doesn't strip -Os, it replaces -O? with -O2, which also enables -fomit-frame-pointer. > 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 it doesn't have any impact. >>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. Ah, very good :) >>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? Good news ;) ferringb has been asking for testing for quite a while now and recently he sent a mail to the portage-dev mailing list, basically saying that if nobody steps up with a good reason, he will include the confcache patch with the next release. > 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>) I don't use it, but not for a certain reason, so I really can't comment on this. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- [email protected] mailing list -- [email protected] mailing list
