Re: [gentoo-amd64] Re: gcc 4.1 + CFLAGS

[Samir Mishra]

Duncan wrote:
> A couple questions:
>
> -mcmodel=medium:  Here's the gcc 4.1.1 manpage entry:
>
> -mcmodel=medium
>   Generate code for the medium model: The program is linked in the lower 2
>   GB of the address space but symbols can be located any-where in the
>   address space.  Programs can be statically or dynamically linked, but
>   building of shared libraries are not supported with the medium model.
>
> What about that last part -- shared libraries not supported?
>
>
palladium ~ # file /bin/bash
/bin/bash: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for 
GNU/Linux 2.6.11, dynamically linked (uses shared libs), stripped
palladium ~ # file /lib/libc-2.4.so
/lib/libc-2.4.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 
(SYSV), stripped
palladium ~ # file /lib/libgcc_s.so.1
/lib/libgcc_s.so.1: ELF 64-bit LSB shared object, AMD x86-64, version 1 
(SYSV), stripped

I assume this is how to  check if a n executable or library is shared. I 
picked 3 common ones at random. I think I read somewhere that the above 
statement regarding lack of support for building shared libraries is not 
accurate. I assumed it to be inaccurate too since I get the above output 
against all files on my machine. If I tested the libraries incorrectly, 
could you indicate what would be the right way to check if GCC is 
generating shared libraries or not? Memory usage seems reasonable for 
all of the applications, but given how much I know, quite possible I got 
it wrong.
> Also...  from my understanding, the address-space references here are
> simply to the program's view of memory, from it's perspective.  More
> specifically, it's not to absolute address space (the >2 gig memory you
> mention), but to the program's virtual address space, the protected-mode
> virtual address space unique to it, and rather independent from its actual
> placement in physical memory or its placement in terms of the kernel's
> virtual address space.
>
> As I understand it, therefore, the only reason to use -mcmodel=medium
> would be if the program itself was expected to manipulate memory on the
> order of gigs at a time.  While this can legitimately happen, say with a
> big database (think Oracle, which very likely uses such an option), the
> vast majority of applications don't work with anywhere near that size of
> data, at least not directly.  While they might handle gigs of data over
> the lifetime of the program, it's megabytes not gigabytes at a time, and
> much of it may be indirectly, thru the kernel, so they have little need
> for a memory allocation model that can allocate structures of multiple
> gigs at a time or to access anything outside a two-gigabyte model.  Even
> on the big machines running apps where use of this model might be
> legitimately called for, it would be inadvisable to compile /everything/
> on the machine with it, only the specific apps that need it.
>
>
I thought otherwise. I guess I'll have to do some research on this. In 
case you do come across any interesting pointers or references, please 
do let me know.
> This would also explain why it only applies to applications, not shared
> libraries, as only the linked application would need to reference the full
> multi-gig allocations -- any library functions would presumably be working
> with much smaller sections of that dataset.
>
> Note that I'm specifically /not/ saying you are incorrect, only that it
> disagrees with what I (think I) know, which itself may be incorrect.  I'm
> running 8 gig of memory here, but it's a fairly new upgrade, so a new
> experience, and it's quite possible what I thought I knew is wrong.  If
> so, I'd like to know it, the better to make use of the memory I have here,
> as well.  So, if you have references as to why you are using that memory
> model, post 'em, as I'd certainly like to read them myself!
>
> -ftracer: Of interest here are a couple other manpage entries:
>
>
I thought -ftracer, like -fweb, automatically did the profiling and the 
optimization. I was under the impression that -ftracer not recommended 
since it increases compile times (which I wasn't worried about) but 
produces "better" executables. If the profiling has to be done manually, 
prior to optimization, I definitely need to take this one out for my CFLAGS.
> -fprofile-generate
>   Enable options usually used for instrumenting application to produce
>   profile useful for later recompilation with profile feedback based
>   optimization.  [snip]
>
> -fprofile-use
>   Enable profile feedback directed optimizations, and optimizations
>   generally profitable only with profile feedback available.
>
>   The following options are enabled: "-fbranch-probabilities", "-fvpt",
>   "-funroll-loops", "-fpeel-loops", "-ftracer", "-fno-loop-optimize".
>
>
BTW I've heard bad things about using -fbranch-probabilities and -fweb. 
In fact, I tried -fweb with -ftracer and I began experiencing numerous 
compilation failures. Everything went back to OK when I took it out.
> I don't see either of these in your CFLAGS, and you don't mention
> compiling, then profiling the program, then recompiling.  Without that,
> the -ftracer flag, which the manpage says "perform[s] tail duplication to
> enlarge superblock size", would appear to enlarge your binaries for little
> or no performance gain.
>
> That said, I've seen a couple developers that use the -ftracer flag as
> well, in various bug reports and the like, which has surprised me a bit
> since it's common for devs to complain about others using flags they don't
> understand the implications of. However, I've yet to find someone who can
> suitably explain /why/ they use it, given the above and the rather
> unlikely chance that they actually bother with that profiling and
> recompilation with every package they use the flag with, tho I don't of
> course go around posting the question to every bug where I see it used,
> and I've had limited chance to ask the question in a suitable context, so
> I've not asked that many about it.
>
> Again, if you have a good reason to choose that flag, or if you've
> actually done tests and /know/ it improves performance, please post it, so
> folks (like me! =8^) can be informed and perhaps optimize their system
> similarly. Until then, I can't reasonably defend or explain using the
> flag if I'm not going to go to the trouble of profiling and recompiling,
> and I don't think the performance gains would be enough to justify that
> (if I were compiling for use by an entire distribution, not just me, the
> effort would of course be justified) so I don't choose to use it.
>

In conclusion, I THOUGHT I had good reason, but I guess I need to do a 
bit more research.

I have not done any speed tests, From reading all the speed tests, I 
know these don't make any sense, because in a real use situation, many 
other factors matter. And anyway, I don't have the knowledge to them 
right :)


Thx.
-- 
gentoo-amd64@g.o mailing list