It's important that you use at least -O3 to get inlining too.
>
> In all cases, the "cc1plus" processes appeared to max out around 25M
> total size. The "maps" pseudofiles for the 2.95.3 and and 3.0
> compiles never grew past 250 lines, but the "maps" pseudofiles for the
> RedHat 2.96 compile were gigantic, jumping to 3000 or 5000 lines at
> times.
25 MB doesn't count ;)
>
> The results speak for themselves:
>
> CVS gcc 3.0: Debian gcc 2.95.3: RedHat gcc 2.96:
>
> real 16m8.423s real 8m2.417s real 12m24.939s
> user 15m23.710s user 7m22.200s user 10m14.420s
> sys 0m48.730s sys 0m41.040s sys 2m13.910s
> maps: <250 lines <250 lines >3000 lines
>
> Obviously, the *real* problem is RedHat GCC 2.96. If Linus bothers to
> write this patch (he probably already has), its only proven benefit so
> far is that it improves the performance of a RedHat-specific, orphaned
> G++ development snapshot that everyone (the people of RedHat most of
> all) will be glad to be rid of as soon as possible.
No, map merging is obviously a good idea if it can be done at little cost.
There has to be other cases out there than GCC 2.96 (which is still the
best damn C++ compiler to ship on any GNU/Linux distribution in history)
As someone else already pointed out GCC-3.0 will improve it's allocation,
but it *still* allocates many maps - less than before, but still potentially
lots...
>
> The numbers above suggest that the patch is unlikely to have a
> positive impact on the performance of either officially released GCC
> versions or the upcoming 3.0 release.
It will still have the 70x performance increase on kernel memory map
handling as demonstrated in my benchmark just posted. However, it will
be 70x of much less than with 2.96.
Granted, the impact will be much smaller on GCC-3.0 in terms of wall clock
ticks, but I bet there is some other code out there that also triggers the
map-nightmare.
>
> Drifting off topic...
We can continue on /. ;)
>
> > Mozilla uses C++ mainly as "extended C" - due to compatibility concerns.
>
> This statement is potentially misleading.
>
> I think most people will believe you to mean "using C++ as a better C"
> in the sense of Stroustrup: using the small, conventional-language
> subset of C++ that looks like C but has stronger type checking,
> function and operator overloading, default arguments, "//" style
> comments, reference types, and other syntactic and semantic sugar.
Yes
>
> Mozilla does not use C++ as "extended C" in this sense. While it does
> use a *subset* of C++ for compatibility reasons, the subset includes
> extensive use of class lattices and polymorphism as well as extensive
> (albeit simple and carefully constructed) uses of templates for its
> utility classes, including string and component-autoreferencing
> template classes and functions that are used throughout the source.
> The only major C++ facilities that are not used are the standard
> library, RTTI, namespaces, and exception handling, but other than that
> it's a good, real-world C++ test case.
Ok - I just read the coding guidelines for Mozilla, that's where I got
my information from... In general (except for the exceptions I guess),
rule number one is "Don't use templates". Rule 5 is "Don't use the namespace
facility". Rule 16 is "Don't put constructors in header files". All
stuff that leads to much much shorter symbols (type names) and less code
inlining - something that makes the job a lot easier for GCC.
Putting template classes and functions in header files with heavy inlining
is something that makes GCC memory usage explode. I managed to write a
few hundred lines once I couldn't compile because GCC couldn't allocate
more than 800-900 MB (old glibc and GCC). The code was badly designed
and easily fixed, but it demonstrated this feature in GCC nicely.
--
................................................................
: jakob@unthought.net : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob Østergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/