On Mon, Jul 27, 2020 at 12:48 PM Jan Hubicka <hubi...@ucw.cz> wrote:
>
> > Yes, I verified that.
> >
> > > I guess I can try
> > > to do some profiling since this problem did not show on Firefox (that i
> > > find odd given that Firefox is just about half of the size).
> >
> > Yep, I'm also surprised about it.
> >
> > > Perhaps glibc has some stupid limit in realloc that makes it to behave
> > > in a silly way for very large arrays?
> >
> > Dunno :P
> Seems like glibc issue. On my debian testing box:
I'm sure in your actual testcase you run into fragmentation and
eventually fall out of cache which should make things worse by
an order of magnitude.
> hubicka@lomikamen-jh:~$ cat t.c
> #include <stdlib.h>
> main(int argc, char **argv)
> {
> char *a = malloc (1);
> int i,n=atoi(argv[1]);
> for (i=2;i<n;i++)
> a = realloc (a,i);
> }
>
> hubicka@lomikamen-jh:~$ time ./a.out 1000000000
>
> real 0m10.057s
> user 0m9.696s
> sys 0m0.356s
>
> And kunlun (which is a lot faster than my 2013 buldozer):
>
>
> abuild@kunlun:~> time ./a.out 1000000000
>
> real 0m59.808s
> user 0m58.703s
> sys 0m1.080s
>
> GDB stops at:
> (gdb) bt
> #0 0x00007ffff7e70bfe in realloc () from /lib/x86_64-linux-gnu/libc.so.6
> #1 0x00005555555550bf in main ()
> on debian while:
> (gdb) bt
> #0 0x00007ffff7e7d6d0 in mem2mem_check () from /lib64/libc.so.6
> #1 0x00007ffff7e81c7d in realloc_check () from /lib64/libc.so.6
> #2 0x00005555555550bf in main ()
> on kunlun.
>
> Perhaps someone enabled some cool security harnessing feature without
> much of benchmarking :) (but even debian numbers seems like they can be
> improved)
>
> Honza
> >
> > Martin
> >
> > >
> > > Honza
> > > >
> > > > Martin
> >
