From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <hubicka@kam.mff.cuni.cz>
Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16])
 by sourceware.org (Postfix) with ESMTPS id ABD7B3858D35
 for <gcc-patches@gcc.gnu.org>; Mon, 27 Jul 2020 10:48:18 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org ABD7B3858D35
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=ucw.cz
Authentication-Results: sourceware.org;
 spf=none smtp.mailfrom=hubicka@kam.mff.cuni.cz
Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202)
 id 4393028254D; Mon, 27 Jul 2020 12:48:17 +0200 (CEST)
Date: Mon, 27 Jul 2020 12:48:17 +0200
From: Jan Hubicka <hubicka@ucw.cz>
To: Martin =?iso-8859-2?Q?Li=B9ka?= <mliska@suse.cz>
Cc: Richard Biener <richard.guenther@gmail.com>,
 GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Use vec::reserve before vec_safe_grow_cleared is called
Message-ID: <20200727104817.GC84462@kam.mff.cuni.cz>
References: <8bf8b90a-6d10-90e3-62aa-633f7bbf71be@suse.cz>
 <CAFiYyc349NfxrDgLHZMFUrmpxcUpipmxn+eo_J8v6NXRVzV_VA@mail.gmail.com>
 <34bd3626-39c0-2516-208d-0ebf5a736b1c@suse.cz>
 <20200727095139.GA84823@kam.mff.cuni.cz>
 <39155424-06f5-a3e9-b66e-c27c7b354aae@suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <39155424-06f5-a3e9-b66e-c27c7b354aae@suse.cz>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Status: No, score=-16.0 required=5.0 tests=BAYES_00,
 HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY,
 RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE,
 TXREP autolearn=no autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2020 10:48:19 -0000

> 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:

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
>