Re: [gentoo-amd64] Re: Re: Re: Wow! KDE 3.5.1 & Xorg 7.0 w/ Composite

[Simon Stelling]

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
blubb@g.o
-- 
gentoo-amd64@g.o mailing list