Re: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.

[=?iso-8859-1?Q?Jakob_=D8stergaard?=]

On Fri, Mar 23, 2001 at 09:02:30PM -0800, Linus Torvalds wrote:
> In article <[e-mail]>,
> Kevin Buhr <[e-mail]> wrote:
> >
> >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),
> 
> Check out 2.4.3-pre7, I'd be interested to hear what the system time is
> for that one.

I was unable to compile gcc-3.0 from CVS this morning - so no tests there
for now...

First the "small" test case:
-----------------------------
2.4.2:
  gcc-2.96:  -O6 -felide-constructors -fPIC
  real    7m31.748s
  user    3m52.340s
  sys     3m38.180s
  Memory consumption:  ~200MB

2.4.3-pre7:
  gcc-2.96:  -O6 -felide-constructors -fPIC
  real    3m52.347s
  user    3m46.120s
  sys     0m3.370s

That's pretty darn impressive Linus !  3m38 -> 3sec !  Now if the GCC people
could only repeat that trick   ;)

Then the bigger one:
-----------------------------
2.4.2:
  gcc-2.96:  -O6 -felide-constructors -fPIC
  Fails compilation with "Virtual memory exhausted!" after
  real    37m28.305s
  user    23m39.930s
  sys     13m44.900s
  Memory consumption:  ~300MB before failure

Note - there are no ulimits set, and the machine has more than enough memory

2.4.3-pre7:
  gcc-2.96:  -O6 -felide-constructors -fPIC
  real    31m48.898s
  user    31m21.460s
  sys     0m26.980s
  Memory consumption:  ~400MB - successful completion

Cool !  I can work again   ;)
 
> 
> It does seem like gcc-2.96 is kind of special, but considering how easy
> it is to merge anonymous memory (most of the changes were cosmetic ones
> to get nice ordering to make the merge trivial without having to
> allocate a vma that never gets used etc), it's certainly worth doing.

Beautiful !

Also, the speedup gained here is ~70 times, which may be more than the changed
allocation in gcc-3 will buy us (was that 32 times?).  And,  after all,  there
_has_ to be some other case out there which is not as easily fixed as the GCC
one.

> 		Linus

-- 
................................................................
:   [e-mail]   : 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}...............: