[gentoo-amd64] Re: gcc 4.1 + CFLAGS

[Duncan]

Samir Mishra <sqmishra@×××.ae> posted 44894503.5010302@×××.ae, excerpted
below, on  Fri, 09 Jun 2006 13:53:07 +0400:

> These are the flag settings I have. My WS has >2GB RAM so I'm using
> -mcmodel=medium. But as you can see, they are hardly "safe".

> A few applications fail to compile, but so far from the >500 packages I
> currently have on my system, only the following have failed to compile
> -- glibc-2.4, gcc, sandbox, strace, transcode, libmpeg3. A few other
> applications, mainly noticed with audio applications, are behaving
> "strange". But I haven't had the opportunity to track all these problems
> down.
>
> # For GCC 4+
> CFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer -fforce-addr -ftracer
> -frename-registers -mno-tls-direct-seg-refs -mcmodel=medium"

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?

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.

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:

-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".

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.



-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list