Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PATCH] sv_grow: performance improvement for short strings #14047

Closed
p5pRT opened this issue Aug 27, 2014 · 34 comments
Closed

[PATCH] sv_grow: performance improvement for short strings #14047

p5pRT opened this issue Aug 27, 2014 · 34 comments
Labels

Comments

@p5pRT
Copy link

p5pRT commented Aug 27, 2014

Migrated from rt.perl.org#122629 (status was 'open')

Searchable as RT122629$

@p5pRT
Copy link
Author

p5pRT commented Aug 27, 2014

From @rurban

This is a bug report for perl from rurban@​cpanel.net,
generated with the help of perlbug 1.40 running under perl 5.21.4.


sv_grow​: performance improvement for short strings

Rationale​:
Empty COW strings with CUR=0 ended up allocated with LEN=10.
Now with the small part +2 they are rounded up to 4 or 8.
Overallocation of larger strings (esp. windows realloc) is
not affected by the small part. +10 stroke me as very odd.
 
Timings with different numbers​:
  +0 16.394324103 +-0.27%
  +2 16.114379842 +-0.01%
  +4 16.305622265 +-1.03%
  +8 16.337438609 +-1.30%
  +10 16.675009468 +-0.59%
with LD_LIBRARY_PATH=`pwd` perf stat -r2 ./perl t/harness t/op/*.t
 
  +2 was consistently the best number, and +10 the worst.
  +0,+4,+8 was about the same.

All tests​:
+10​: (u=7.09 s=1.38 cu=336.32 cs=10.59)
+8​: (u=6.86 s=1.72 cu=335.03 cs=10.48)
+2​: (u=6.46 s=1.11 cu=331.08 cs=10.28)
+0​: (u=6.67 s=1.35 cu=338.26 cs=10.74)



Flags​:
  category=core
  severity=medium
  Type=Patch
  PatchStatus=HasPatch


Site configuration information for perl 5.21.4​:

Configured by rurban at Wed Aug 27 11​:43​:16 CDT 2014.

Summary of my perl5 (revision 5 version 21 subversion 4) configuration​:
  Derived from​: f410e80
  Platform​:
  osname=linux, osvers=3.14-2-amd64, archname=x86_64-linux
  uname='linux reini 3.14-2-amd64 #1 smp debian 3.14.13-2 (2014-07-24) x86_64 gnulinux '
  config_args='-des -Dusedevel -Uversiononly -Dinstallman1dir=none -Dinstallman3dir=none -Dinstallsiteman1dir=none -Dinstallsiteman3dir=none -Uuseithreads -Accflags=-msse4.2 -Accflags=-march=corei7 -Dcf_email=rurban@​cpanel.net -Dperladmin=rurban@​cpanel.net -Duseshrplib -Dcc=gcc-4.9 -Dld=gcc-4.9'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=undef, usemultiplicity=undef
  use64bitint=define, use64bitall=define, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='gcc-4.9', ccflags ='-msse4.2 -march=corei7 -fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2',
  optimize='-O2',
  cppflags='-msse4.2 -march=corei7 -fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.9.1', gccosandvers=''
  intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16, longdblkind=3
  ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='gcc-4.9', ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /lib64 /usr/lib64
  libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
  perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
  libc=libc-2.19.so, so=so, useshrplib=true, libperl=libperl.so
  gnulibc_version='2.19'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/local/lib/perl5/5.21.4/x86_64-linux/CORE'
  cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector'

Locally applied patches​:
  uncommitted-changes


@​INC for perl 5.21.4​:
  lib
  /usr/local/lib/perl5/site_perl/5.21.4/x86_64-linux
  /usr/local/lib/perl5/site_perl/5.21.4
  /usr/local/lib/perl5/5.21.4/x86_64-linux
  /usr/local/lib/perl5/5.21.4
  /usr/local/lib/perl5/site_perl/5.21.3
  /usr/local/lib/perl5/site_perl/5.21.2
  /usr/local/lib/perl5/site_perl/5.21.1
  /usr/local/lib/perl5/site_perl/5.21.0
  /usr/local/lib/perl5/site_perl/5.20.1
  /usr/local/lib/perl5/site_perl/5.20.0
  /usr/local/lib/perl5/site_perl/5.19.11
  /usr/local/lib/perl5/site_perl/5.19.10
  /usr/local/lib/perl5/site_perl/5.19.9
  /usr/local/lib/perl5/site_perl/5.19.8
  /usr/local/lib/perl5/site_perl/5.19.7
  /usr/local/lib/perl5/site_perl/5.19.6
  /usr/local/lib/perl5/site_perl/5.19.5
  /usr/local/lib/perl5/site_perl/5.19.4
  /usr/local/lib/perl5/site_perl/5.19.3
  /usr/local/lib/perl5/site_perl/5.19.2
  /usr/local/lib/perl5/site_perl/5.19.1
  /usr/local/lib/perl5/site_perl/5.19.0
  /usr/local/lib/perl5/site_perl/5.18.2
  /usr/local/lib/perl5/site_perl/5.18.1
  /usr/local/lib/perl5/site_perl/5.18.0
  /usr/local/lib/perl5/site_perl/5.17.11
  /usr/local/lib/perl5/site_perl/5.17.10
  /usr/local/lib/perl5/site_perl/5.17.8
  /usr/local/lib/perl5/site_perl/5.17.7
  /usr/local/lib/perl5/site_perl/5.17.6
  /usr/local/lib/perl5/site_perl/5.17.5
  /usr/local/lib/perl5/site_perl/5.17.4
  /usr/local/lib/perl5/site_perl/5.17.3
  /usr/local/lib/perl5/site_perl/5.17.2
  /usr/local/lib/perl5/site_perl/5.17.1
  /usr/local/lib/perl5/site_perl/5.17.0
  /usr/local/lib/perl5/site_perl/5.17
  /usr/local/lib/perl5/site_perl/5.16.3
  /usr/local/lib/perl5/site_perl/5.16.2
  /usr/local/lib/perl5/site_perl/5.16.1
  /usr/local/lib/perl5/site_perl/5.16.0
  /usr/local/lib/perl5/site_perl/5.15.9
  /usr/local/lib/perl5/site_perl/5.15.8
  /usr/local/lib/perl5/site_perl/5.15.7
  /usr/local/lib/perl5/site_perl/5.15.6
  /usr/local/lib/perl5/site_perl/5.15.5
  /usr/local/lib/perl5/site_perl/5.15.4
  /usr/local/lib/perl5/site_perl/5.15.3
  /usr/local/lib/perl5/site_perl/5.15.2
  /usr/local/lib/perl5/site_perl/5.14.4
  /usr/local/lib/perl5/site_perl/5.14.3
  /usr/local/lib/perl5/site_perl/5.14.2
  /usr/local/lib/perl5/site_perl/5.14.1
  /usr/local/lib/perl5/site_perl/5.12.5
  /usr/local/lib/perl5/site_perl/5.12.4
  /usr/local/lib/perl5/site_perl/5.10.1
  /usr/local/lib/perl5/site_perl/5.8.9
  /usr/local/lib/perl5/site_perl/5.8.8
  /usr/local/lib/perl5/site_perl/5.8.7
  /usr/local/lib/perl5/site_perl/5.8.6
  /usr/local/lib/perl5/site_perl/5.8.5
  /usr/local/lib/perl5/site_perl/5.8.4
  /usr/local/lib/perl5/site_perl/5.8.3
  /usr/local/lib/perl5/site_perl/5.8.2
  /usr/local/lib/perl5/site_perl/5.8.1
  /usr/local/lib/perl5/site_perl/5.6.2
  /usr/local/lib/perl5/site_perl
  .


Environment for perl 5.21.4​:
  HOME=/home/rurban
  LANG=en_US.utf8
  LANGUAGE (unset)
  LD_LIBRARY_PATH=/usr/src/perl/blead/perl-git
  LOGDIR (unset)
  PATH=/home/rurban/bin​:/usr/local/bin​:/usr/bin​:/bin​:/usr/local/games​:/usr/games
  PERL_BADLANG (unset)
  SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented Aug 27, 2014

From @rurban

0001-sv_grow-performance-improvement-for-short-strings.patch
From 32818149be28edd2a58ea345eea388bf0d3dc329 Mon Sep 17 00:00:00 2001
From: Reini Urban <rurban@x-ray.at>
Date: Wed, 27 Aug 2014 12:48:35 -0500
Subject: [PATCH] sv_grow: performance improvement for short strings

Empty COW strings with CUR=0 ended up allocated as LEN=10.
Now they are rounded up to 4 or 8.

Timings:
+0   16.394324103 0.27%
+2   16.114379842 0.01%
+4   16.305622265 1.03%
+8   16.337438609 1.30%
+10  16.675009468 0.59%
with LD_LIBRARY_PATH=`pwd` perf stat -r2 ./perl t/harness t/op/*.t

+2 was consistently the best number, and +10 the worst.
---
 sv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git sv.c sv.c
index 7c334d0..3c27303 100644
--- sv.c
+++ sv.c
@@ -1553,7 +1553,7 @@ Perl_sv_grow(pTHX_ SV *const sv, STRLEN newlen)
 
 #ifdef PERL_NEW_COPY_ON_WRITE
     /* the new COW scheme uses SvPVX(sv)[SvLEN(sv)-1] (if spare)
-     * to store the COW count. So in general, allocate one more byte than
+     * to store the CowREFCNT. So in general, allocate one more byte than
      * asked for, to make it likely this byte is always spare: and thus
      * make more strings COW-able.
      * If the new size is a big power of two, don't bother: we assume the
@@ -1569,7 +1569,7 @@ Perl_sv_grow(pTHX_ SV *const sv, STRLEN newlen)
 
     if (newlen > SvLEN(sv)) {		/* need more room? */
 	STRLEN minlen = SvCUR(sv);
-	minlen += (minlen >> PERL_STRLEN_EXPAND_SHIFT) + 10;
+	minlen += (minlen >> PERL_STRLEN_EXPAND_SHIFT) + 2;
 	if (newlen < minlen)
 	    newlen = minlen;
 #ifndef PERL_UNWARANTED_CHUMMINESS_WITH_MALLOC
-- 
2.1.0

@p5pRT
Copy link
Author

p5pRT commented Aug 28, 2014

From @cpansprout

On Wed Aug 27 11​:03​:24 2014, rurban@​cpanel.net wrote​:

This is a bug report for perl from rurban@​cpanel.net,
generated with the help of perlbug 1.40 running under perl 5.21.4.

-----------------------------------------------------------------
sv_grow​: performance improvement for short strings

Rationale​:
Empty COW strings with CUR=0 ended up allocated with LEN=10.
Now with the small part +2 they are rounded up to 4 or 8.
Overallocation of larger strings (esp. windows realloc) is
not affected by the small part. +10 stroke me as very odd.

Timings with different numbers​:
+0 16.394324103 +-0.27%
+2 16.114379842 +-0.01%
+4 16.305622265 +-1.03%
+8 16.337438609 +-1.30%
+10 16.675009468 +-0.59%
with LD_LIBRARY_PATH=`pwd` perf stat -r2 ./perl t/harness t/op/*.t

+2 was consistently the best number, and +10 the worst.
+0,+4,+8 was about the same.

All tests​:
+10​: (u=7.09 s=1.38 cu=336.32 cs=10.59)
+8​: (u=6.86 s=1.72 cu=335.03 cs=10.48)
+2​: (u=6.46 s=1.11 cu=331.08 cs=10.28)
+0​: (u=6.67 s=1.35 cu=338.26 cs=10.74)

Thank you. Applied as 880c169.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Aug 28, 2014

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Aug 28, 2014

@cpansprout - Status changed from 'open' to 'pending release'

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2014

@khwilliamson - Status changed from 'pending release' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2014

From @khwilliamson

I am reopening this ticket and raising its priority because this patch breaks blead under ASAN. Attached is an output of ASAN on t/op/attrs.t (uni/attrs.t is also broken)

880c169 is the first bad commit
commit 880c169
Author​: Reini Urban <rurban@​x-ray.at>
Date​: Wed Aug 27 12​:48​:35 2014 -0500

  sv_grow​: performance improvement for short strings
 
  Empty COW strings with CUR=0 ended up allocated as LEN=10.
  Now they are rounded up to 4 or 8.
 
  Timings​:
  +0 16.394324103 0.27%
  +2 16.114379842 0.01%
  +4 16.305622265 1.03%
  +8 16.337438609 1.30%
  +10 16.675009468 0.59%
  with LD_LIBRARY_PATH=`pwd` perf stat -r2 ./perl t/harness t/op/*.t
 
  +2 was consistently the best number, and +10 the worst.

:100644 100644 5a77d6bd438396bd06e58ed4685d57eca178541b 2940942fc6333dd91dcd2acb17bbd558171680ee M sv.c
bisect run success
That took 3158 seconds

--
Karl Williamson

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2014

From @khwilliamson

attrs.out

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2014

From @khwilliamson

On Sat Aug 30 21​:11​:52 2014, khw wrote​:

I am reopening this ticket and raising its priority because this patch
breaks blead under ASAN. Attached is an output of ASAN on
t/op/attrs.t (uni/attrs.t is also broken)

880c169 is the first bad commit
commit 880c169
Author​: Reini Urban <rurban@​x-ray.at>
Date​: Wed Aug 27 12​:48​:35 2014 -0500

sv_grow​: performance improvement for short strings

Empty COW strings with CUR=0 ended up allocated as LEN=10.
Now they are rounded up to 4 or 8.

Timings​:
+0 16.394324103 0.27%
+2 16.114379842 0.01%
+4 16.305622265 1.03%
+8 16.337438609 1.30%
+10 16.675009468 0.59%
with LD_LIBRARY_PATH=`pwd` perf stat -r2 ./perl t/harness t/op/*.t

+2 was consistently the best number, and +10 the worst.

:100644 100644 5a77d6bd438396bd06e58ed4685d57eca178541b
2940942fc6333dd91dcd2acb17bbd558171680ee M sv.c
bisect run success
That took 3158 seconds

--
Karl Williamson

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2014

From @khwilliamson

attrs.out

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2014

From [Unknown Contact. See original ticket]

On Sat Aug 30 21​:11​:52 2014, khw wrote​:

I am reopening this ticket and raising its priority because this patch
breaks blead under ASAN. Attached is an output of ASAN on
t/op/attrs.t (uni/attrs.t is also broken)

880c169 is the first bad commit
commit 880c169
Author​: Reini Urban <rurban@​x-ray.at>
Date​: Wed Aug 27 12​:48​:35 2014 -0500

sv_grow​: performance improvement for short strings

Empty COW strings with CUR=0 ended up allocated as LEN=10.
Now they are rounded up to 4 or 8.

Timings​:
+0 16.394324103 0.27%
+2 16.114379842 0.01%
+4 16.305622265 1.03%
+8 16.337438609 1.30%
+10 16.675009468 0.59%
with LD_LIBRARY_PATH=`pwd` perf stat -r2 ./perl t/harness t/op/*.t

+2 was consistently the best number, and +10 the worst.

:100644 100644 5a77d6bd438396bd06e58ed4685d57eca178541b
2940942fc6333dd91dcd2acb17bbd558171680ee M sv.c
bisect run success
That took 3158 seconds

--
Karl Williamson

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2014

From @cpansprout

On Sat Aug 30 21​:11​:52 2014, khw wrote​:

I am reopening this ticket and raising its priority because this patch
breaks blead under ASAN. Attached is an output of ASAN on
t/op/attrs.t (uni/attrs.t is also broken)

How do I translate this into file and line number?

0x60200004dbd5 is located 0 bytes to the right of 5-byte region [0x60200004dbd0,0x60200004dbd5)
allocated by thread T0 here​:
  #0 0x480459 (/home/khw/perl/asan/perl+0x480459)
  #1 0xd416d2 (/home/khw/perl/asan/perl+0xd416d2)
  #2 0x10815a8 (/home/khw/perl/asan/perl+0x10815a8)
  #3 0x10e0e2b (/home/khw/perl/asan/perl+0x10e0e2b)
  #4 0x1224229 (/home/khw/perl/asan/perl+0x1224229)
  #5 0x84a864 (/home/khw/perl/asan/perl+0x84a864)
  #6 0x9cbfeb (/home/khw/perl/asan/perl+0x9cbfeb)
  #7 0x15df4d1 (/home/khw/perl/asan/perl+0x15df4d1)
  #8 0x15f1c04 (/home/khw/perl/asan/perl+0x15f1c04)
  #9 0xd3de89 (/home/khw/perl/asan/perl+0xd3de89)
  #10 0x687310 (/home/khw/perl/asan/perl+0x687310)
  #11 0x682f68 (/home/khw/perl/asan/perl+0x682f68)
  #12 0x496bd7 (/home/khw/perl/asan/perl+0x496bd7)
  #13 0x7f5dd2e3cec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2014

From @khwilliamson

offlist, I have no idea, except to google it

On 08/31/2014 07​:29 AM, Father Chrysostomos via RT wrote​:

On Sat Aug 30 21​:11​:52 2014, khw wrote​:

I am reopening this ticket and raising its priority because this patch
breaks blead under ASAN. Attached is an output of ASAN on
t/op/attrs.t (uni/attrs.t is also broken)

How do I translate this into file and line number?

0x60200004dbd5 is located 0 bytes to the right of 5-byte region [0x60200004dbd0,0x60200004dbd5)
allocated by thread T0 here​:
#0 0x480459 (/home/khw/perl/asan/perl+0x480459)
#1 0xd416d2 (/home/khw/perl/asan/perl+0xd416d2)
#2 0x10815a8 (/home/khw/perl/asan/perl+0x10815a8)
#3 0x10e0e2b (/home/khw/perl/asan/perl+0x10e0e2b)
#4 0x1224229 (/home/khw/perl/asan/perl+0x1224229)
#5 0x84a864 (/home/khw/perl/asan/perl+0x84a864)
#6 0x9cbfeb (/home/khw/perl/asan/perl+0x9cbfeb)
#7 0x15df4d1 (/home/khw/perl/asan/perl+0x15df4d1)
#8 0x15f1c04 (/home/khw/perl/asan/perl+0x15f1c04)
#9 0xd3de89 (/home/khw/perl/asan/perl+0xd3de89)
#10 0x687310 (/home/khw/perl/asan/perl+0x687310)
#11 0x682f68 (/home/khw/perl/asan/perl+0x682f68)
#12 0x496bd7 (/home/khw/perl/asan/perl+0x496bd7)
#13 0x7f5dd2e3cec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)

@p5pRT
Copy link
Author

p5pRT commented Sep 1, 2014

From @demerphq

On 31 August 2014 15​:29, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

On Sat Aug 30 21​:11​:52 2014, khw wrote​:

I am reopening this ticket and raising its priority because this patch
breaks blead under ASAN. Attached is an output of ASAN on
t/op/attrs.t (uni/attrs.t is also broken)

How do I translate this into file and line number?

0x60200004dbd5 is located 0 bytes to the right of 5-byte region
[0x60200004dbd0,0x60200004dbd5)
allocated by thread T0 here​:
#0 0x480459 (/home/khw/perl/asan/perl+0x480459)
#1 0xd416d2 (/home/khw/perl/asan/perl+0xd416d2)
#2 0x10815a8 (/home/khw/perl/asan/perl+0x10815a8)
#3 0x10e0e2b (/home/khw/perl/asan/perl+0x10e0e2b)
#4 0x1224229 (/home/khw/perl/asan/perl+0x1224229)
#5 0x84a864 (/home/khw/perl/asan/perl+0x84a864)
#6 0x9cbfeb (/home/khw/perl/asan/perl+0x9cbfeb)
#7 0x15df4d1 (/home/khw/perl/asan/perl+0x15df4d1)
#8 0x15f1c04 (/home/khw/perl/asan/perl+0x15f1c04)
#9 0xd3de89 (/home/khw/perl/asan/perl+0xd3de89)
#10 0x687310 (/home/khw/perl/asan/perl+0x687310)
#11 0x682f68 (/home/khw/perl/asan/perl+0x682f68)
#12 0x496bd7 (/home/khw/perl/asan/perl+0x496bd7)
#13 0x7f5dd2e3cec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)

I think this patch should be reverted.

The timing differences were in the noise, and not backed up by robust
benchmarking. Possibly this can be saved with use of dumbbench, but I would
like to see more use cases examined.

Specifically, this logic is part of the overallocation logic that made a
*huge* performance difference on Win32 and other platforms that have an
inefficient realloc().

If this patch is to live the magic number involved should be a compile time
setting that builders can make their own decision about.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

@p5pRT
Copy link
Author

p5pRT commented Sep 1, 2014

From @cpansprout

On Mon Sep 01 00​:14​:55 2014, demerphq wrote​:

I think this patch should be reverted.

The timing differences were in the noise, and not backed up by robust
benchmarking. Possibly this can be saved with use of dumbbench, but I would
like to see more use cases examined.

Specifically, this logic is part of the overallocation logic that made a
*huge* performance difference on Win32 and other platforms that have an
inefficient realloc().

I have reverted it for now in 3c239be.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Sep 1, 2014

From @rurban

On Mon, Sep 1, 2014 at 9​:14 AM, demerphq <demerphq@​gmail.com> wrote​:

On 31 August 2014 15​:29, Father Chrysostomos via RT
<perlbug-followup@​perl.org> wrote​:

On Sat Aug 30 21​:11​:52 2014, khw wrote​:

I am reopening this ticket and raising its priority because this patch
breaks blead under ASAN. Attached is an output of ASAN on
t/op/attrs.t (uni/attrs.t is also broken)

How do I translate this into file and line number?

set ASAN_SYMBOLIZER

I use​:
$ export |grep ASAN
declare -x ASAN_OPTIONS="malloc_context_size=1 symbolize=1"
declare -x ASAN_SYMBOLIZER_PATH="/usr/bin/llvm-symbolizer-3.4"

READ of size 6 at 0x60200004ec15 thread T0
  #0 0x454c58 in __interceptor_memcmp
(/home/rurban/Perl/src/build-5.21.4d-nt-asan@​32818149/perl+0x454c58)
  #1 0x7f7f605aebc0 in modify_SV_attributes
/home/rurban/Perl/src/build-5.21.4d-nt-asan@​32818149/ext/attributes/attributes.xs​:100
  #2 0x7f7f605a0042 in XS_attributes__modify_attrs
/home/rurban/Perl/src/build-5.21.4d-nt-asan@​32818149/ext/attributes/attributes.xs​:134
  #3 0x7f7f64c97653 in Perl_pp_entersub
/home/rurban/Perl/src/build-5.21.4d-nt-asan@​32818149/pp_hot.c​:2784
  #4 0x7f7f6498ac8a in Perl_runops_debug
/home/rurban/Perl/src/build-5.21.4d-nt-asan@​32818149/dump.c​:2358
  #5 0x7f7f642d077b in S_run_body
/home/rurban/Perl/src/build-5.21.4d-nt-asan@​32818149/perl.c​:2408
  #6 0x7f7f642cc3f2 in perl_run
/home/rurban/Perl/src/build-5.21.4d-nt-asan@​32818149/perl.c​:2336
  #7 0x47b95f in main
/home/rurban/Perl/src/build-5.21.4d-nt-asan@​32818149/perlmain.c​:114
  #8 0x7f7f63114b44 (/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
  #9 0x47b2dc in _start
(/home/rurban/Perl/src/build-5.21.4d-nt-asan@​32818149/perl+0x47b2dc)

This is caused by a wrong memcmp in attributes.xs​:100
patch attached

[0x60200004dbd0,0x60200004dbd5)
allocated by thread T0 here​:
#0 0x480459 (/home/khw/perl/asan/perl+0x480459)
#1 0xd416d2 (/home/khw/perl/asan/perl+0xd416d2)
#2 0x10815a8 (/home/khw/perl/asan/perl+0x10815a8)
#3 0x10e0e2b (/home/khw/perl/asan/perl+0x10e0e2b)
#4 0x1224229 (/home/khw/perl/asan/perl+0x1224229)
#5 0x84a864 (/home/khw/perl/asan/perl+0x84a864)
#6 0x9cbfeb (/home/khw/perl/asan/perl+0x9cbfeb)
#7 0x15df4d1 (/home/khw/perl/asan/perl+0x15df4d1)
#8 0x15f1c04 (/home/khw/perl/asan/perl+0x15f1c04)
#9 0xd3de89 (/home/khw/perl/asan/perl+0xd3de89)
#10 0x687310 (/home/khw/perl/asan/perl+0x687310)
#11 0x682f68 (/home/khw/perl/asan/perl+0x682f68)
#12 0x496bd7 (/home/khw/perl/asan/perl+0x496bd7)
#13 0x7f5dd2e3cec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)

I think this patch should be reverted.

The timing differences were in the noise, and not backed up by robust
benchmarking. Possibly this can be saved with use of dumbbench, but I would
like to see more use cases examined.

Sorry, I used more robust benchmarking than dumbbench, but on a noisy machine.
perf stat -r2 error rates < 1% are stable, not noisy. > 5% would be noisy.

Specifically, this logic is part of the overallocation logic that made a
*huge* performance difference on Win32 and other platforms that have an
inefficient realloc().

Not really. The wrong realloc overallocation logic which caused
another performance regression is caused by the
minlen >> PERL_STRLEN_EXPAND_SHIFT, not by the +10.
The +10 was the linear part causing overallocation from 0 to 10 for
empty strings,
the right shift by 2 was for the windows realloc problem,
which caused the overallocation regressions pointed out 2010 in "All
gone", but was ignored.

The current scheme is still very bad, as it does not round properly
and thus causes realloc problems.
But I tried to explain realloc to you before, and you dismissed it, so
I remain silent.
Summary​: Only realloc manually if the system realloc is bad. It is
only with the win32 runtime.

Discussion with my problem​:
https://groups.google.com/forum/#!topic/perl.perl5.porters/44PTHwefYUk

Perf. regression measured​:
http​://grokbase.com/t/perl/perl5-porters/109dqy8ya2/all-gone/oldest

If this patch is to live the magic number involved should be a compile time
setting that builders can make their own decision about.

No magic numbers. 2 is the space needed for the cow refcount of an
empty string. 0>>2 = 0

--
Reini Urban
http​://cpanel.net/ http​://www.perl-compiler.org/

--
Reini Urban
http​://phpwiki.org/ http​://murbreak.at/

@p5pRT
Copy link
Author

p5pRT commented Sep 1, 2014

From @rurban

0001-fix-attributes-memcmp-without-len-6-asan-catch.patch
From 57c11c30d34df080365281180c0228801f408d89 Mon Sep 17 00:00:00 2001
From: Reini Urban <rurban@x-ray.at>
Date: Mon, 1 Sep 2014 13:50:12 +0200
Subject: [PATCH] fix attributes memcmp without len<6 (asan catch)

also tune the sv_grow overallocation from 10 to 8, to avoid realloc stress
---
 ext/attributes/attributes.xs | 2 +-
 sv.c                         | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git ext/attributes/attributes.xs ext/attributes/attributes.xs
index dbb644d..56e7762 100644
--- ext/attributes/attributes.xs
+++ ext/attributes/attributes.xs
@@ -97,7 +97,7 @@ modify_SV_attributes(pTHX_ SV *sv, SV **retlist, SV **attrlist, int numattrs)
 	    }
 	    break;
 	default:
-	    if (memEQs(name, 6, "shared")) {
+	    if (len == 6 && memEQs(name, 6, "shared")) {
 			if (negated)
 			    Perl_croak(aTHX_ "A variable may not be unshared");
 			SvSHARE(sv);
diff --git sv.c sv.c
index 7d4c964..1c4e9ec 100644
--- sv.c
+++ sv.c
@@ -1534,7 +1534,7 @@ Perl_sv_grow(pTHX_ SV *const sv, STRLEN newlen)
 	sv_backoff(sv);
 	s = SvPVX_mutable(sv);
 	if (newlen > SvLEN(sv))
-	    newlen += 10 * (newlen - SvCUR(sv)); /* avoid copy each time */
+	    newlen += 8 * (newlen - SvCUR(sv)); /* avoid copy each time */
     }
     else
     {
-- 
2.0.4

@p5pRT
Copy link
Author

p5pRT commented Sep 9, 2014

From @demerphq

On 1 September 2014 09​:14, demerphq <demerphq@​gmail.com> wrote​:

On 31 August 2014 15​:29, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

On Sat Aug 30 21​:11​:52 2014, khw wrote​:

I am reopening this ticket and raising its priority because this patch
breaks blead under ASAN. Attached is an output of ASAN on
t/op/attrs.t (uni/attrs.t is also broken)

How do I translate this into file and line number?

0x60200004dbd5 is located 0 bytes to the right of 5-byte region
[0x60200004dbd0,0x60200004dbd5)
allocated by thread T0 here​:
#0 0x480459 (/home/khw/perl/asan/perl+0x480459)
#1 0xd416d2 (/home/khw/perl/asan/perl+0xd416d2)
#2 0x10815a8 (/home/khw/perl/asan/perl+0x10815a8)
#3 0x10e0e2b (/home/khw/perl/asan/perl+0x10e0e2b)
#4 0x1224229 (/home/khw/perl/asan/perl+0x1224229)
#5 0x84a864 (/home/khw/perl/asan/perl+0x84a864)
#6 0x9cbfeb (/home/khw/perl/asan/perl+0x9cbfeb)
#7 0x15df4d1 (/home/khw/perl/asan/perl+0x15df4d1)
#8 0x15f1c04 (/home/khw/perl/asan/perl+0x15f1c04)
#9 0xd3de89 (/home/khw/perl/asan/perl+0xd3de89)
#10 0x687310 (/home/khw/perl/asan/perl+0x687310)
#11 0x682f68 (/home/khw/perl/asan/perl+0x682f68)
#12 0x496bd7 (/home/khw/perl/asan/perl+0x496bd7)
#13 0x7f5dd2e3cec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)

I think this patch should be reverted.

The timing differences were in the noise, and not backed up by robust
benchmarking. Possibly this can be saved with use of dumbbench, but I would
like to see more use cases examined.

Specifically, this logic is part of the overallocation logic that made a
*huge* performance difference on Win32 and other platforms that have an
inefficient realloc().

If this patch is to live the magic number involved should be a compile
time setting that builders can make their own decision about.

My concern is use cases like this​:

on systems with a poor implementation of realloc the following program
becomes very very slow​: perl -MData​::Dumper -le'sub recurse { my $d= shift;
my @​ret; if ($d>0) {push @​ret, recurse($d-1), recurse($d-1)} return \@​ret};
print Dumper(recurse(10))'

--
perl -Mre=debug -e "/just|another|perl|hacker/"

@p5pRT
Copy link
Author

p5pRT commented Sep 9, 2014

From @rurban

On 09/09/2014 10​:40 AM, yves orton via RT wrote​:

On 1 September 2014 09​:14, demerphq <demerphq@​gmail.com> wrote​:

On 31 August 2014 15​:29, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

On Sat Aug 30 21​:11​:52 2014, khw wrote​:

I am reopening this ticket and raising its priority because this patch
breaks blead under ASAN. Attached is an output of ASAN on
t/op/attrs.t (uni/attrs.t is also broken)

How do I translate this into file and line number?

0x60200004dbd5 is located 0 bytes to the right of 5-byte region
[0x60200004dbd0,0x60200004dbd5)
allocated by thread T0 here​:
#0 0x480459 (/home/khw/perl/asan/perl+0x480459)
#1 0xd416d2 (/home/khw/perl/asan/perl+0xd416d2)
#2 0x10815a8 (/home/khw/perl/asan/perl+0x10815a8)
#3 0x10e0e2b (/home/khw/perl/asan/perl+0x10e0e2b)
#4 0x1224229 (/home/khw/perl/asan/perl+0x1224229)
#5 0x84a864 (/home/khw/perl/asan/perl+0x84a864)
#6 0x9cbfeb (/home/khw/perl/asan/perl+0x9cbfeb)
#7 0x15df4d1 (/home/khw/perl/asan/perl+0x15df4d1)
#8 0x15f1c04 (/home/khw/perl/asan/perl+0x15f1c04)
#9 0xd3de89 (/home/khw/perl/asan/perl+0xd3de89)
#10 0x687310 (/home/khw/perl/asan/perl+0x687310)
#11 0x682f68 (/home/khw/perl/asan/perl+0x682f68)
#12 0x496bd7 (/home/khw/perl/asan/perl+0x496bd7)
#13 0x7f5dd2e3cec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)

I think this patch should be reverted.

The timing differences were in the noise, and not backed up by robust
benchmarking. Possibly this can be saved with use of dumbbench, but I would
like to see more use cases examined.

Specifically, this logic is part of the overallocation logic that made a
*huge* performance difference on Win32 and other platforms that have an
inefficient realloc().

If this patch is to live the magic number involved should be a compile
time setting that builders can make their own decision about.

My concern is use cases like this​:

on systems with a poor implementation of realloc the following program
becomes very very slow​: perl -MData​::Dumper -le'sub recurse { my $d= shift;
my @​ret; if ($d>0) {push @​ret, recurse($d-1), recurse($d-1)} return \@​ret};
print Dumper(recurse(10))'

Sure, and I already debunked this claim of yours in my original patch
and my 2nd answer.

In this patch I only reverted the initial +10 overallocation for short
strings (0 => 10), the linear part, not the unneccessary exponential
overallocation on big strings - as opposed in 2010 for working realloc's.

And the benchmarks (with command-line to repro) showed that's a win.

Reverting the initial overallocation change was also a win for your
use-case, as benchmarked in 2010. ("All lost")

Let's do it again with my original ackerman one-liner (with better op
distribution than yours, and no IO), all 3 cases.

LD_LIBRARY_PATH=`pwd` perf stat -r5 ./perl -e'sub f{my($n)=@​_;$n==8 and
bless{1..4}and$a=~s/$/../;$n<2 and
return$n;f($n-1)+f($n-2)}f(30)'

now with c4c61c6​:
1.100361293 s +-0.47%

with +2 linear overalloc (and +8 for OOK)
1.105047687 s +-0.95%

without any overalloc at all (as with 5.12) on a sane libc pure-realloc​:
1.100582432 s +-0.62%

your sample (without IO)​:

m -s libperl.so
LD_LIBRARY_PATH=`pwd` perf stat -r5 ./perl -Ilib -MData​::Dumper -e'sub
recurse { my $d= shift; my @​ret; if ($d>0) {push @​ret, recurse($d-1),
recurse($d-1)} return \@​ret}; Dumper(recurse(20));'

blead​:
7.922071728 +-0.12%
my patch +2 overalloc​:
8.039188177 +-0.27%
without any overalloc at all (as with 5.12) on a sane libc pure-realloc​:
7.931262581 +-0.22%

with print and recurse 12​: (print buffering skews the result too much)
blead​:
0.164692397 +-1.10%
my patch +2 overalloc​:
0.169309153 +-4.58%
without any overalloc at all (as with 5.12) on a sane libc pure-realloc​:
0.174200999 +-4.53%

testing big string realloc​:
LD_LIBRARY_PATH=`pwd` perf stat -r5 ./perl -e'sub f{my($n)=@​_;$s.="
"x$n;$n<2 and return $n;f($n-1)+f($n-2)}f(31)'

blead​:
1.973937279 +-1.44%
my patch +2 overalloc​:
1.934518693 +-0.92%
without any overalloc at all (as with 5.12) on a sane libc pure-realloc​:
1.985311144 +-1.27%

bigger strings​:
LD_LIBRARY_PATH=`pwd` perf stat -r5 ./perl -e'sub f{my($n)=@​_;$s.="
"x(16*$n);$n<2 and return $n;f($n-1)+f($n-2)}f(31)'

blead​:
2.145765569 +-1.01%
my patch +2 overalloc​:
2.128943007 +-0.75%
without any overalloc at all (as with 5.12) on a sane libc pure-realloc​:
2.160022970 +-1.07%

Now compare that to the overall results testing all t/op/*.t
  +0 16.394324103 0.27%
  +2 16.114379842 0.01%
  +4 16.305622265 1.03%
  +8 16.337438609 1.30%
  +10 16.675009468 0.59%
with LD_LIBRARY_PATH=`pwd` perf stat -r2 ./perl t/harness t/op/*.t

I'd say the original 5.12 version was the best on non-broken realloc
systems and if you insist in doing your own realloc +2 is the best.

--
Reini

Working towards a true Modern Perl.
Slim, functional, unbloated, compile-time optimizable

@p5pRT
Copy link
Author

p5pRT commented Sep 9, 2014

From @rurban

+2overalloc.patch
diff --git sv.c sv.c
index 748d3e6..4b4d890 100644
--- sv.c
+++ sv.c
@@ -1534,7 +1534,7 @@ Perl_sv_grow(pTHX_ SV *const sv, STRLEN newlen)
 	sv_backoff(sv);
 	s = SvPVX_mutable(sv);
 	if (newlen > SvLEN(sv))
-	    newlen += 10 * (newlen - SvCUR(sv)); /* avoid copy each time */
+	    newlen += 8 * (newlen - SvCUR(sv)); /* avoid copy each time */
     }
     else
     {
@@ -1560,7 +1560,7 @@ Perl_sv_grow(pTHX_ SV *const sv, STRLEN newlen)
 
     if (newlen > SvLEN(sv)) {		/* need more room? */
 	STRLEN minlen = SvCUR(sv);
-	minlen += (minlen >> PERL_STRLEN_EXPAND_SHIFT) + 10;
+	minlen += (minlen >> PERL_STRLEN_EXPAND_SHIFT) + 2;
 	if (newlen < minlen)
 	    newlen = minlen;
 #ifndef PERL_UNWARANTED_CHUMMINESS_WITH_MALLOC

@p5pRT
Copy link
Author

p5pRT commented Sep 9, 2014

From @rurban

no-overalloc.patch
diff --git sv.c sv.c
index 748d3e6..eabe276 100644
--- sv.c
+++ sv.c
@@ -1534,7 +1534,7 @@ Perl_sv_grow(pTHX_ SV *const sv, STRLEN newlen)
 	sv_backoff(sv);
 	s = SvPVX_mutable(sv);
 	if (newlen > SvLEN(sv))
-	    newlen += 10 * (newlen - SvCUR(sv)); /* avoid copy each time */
+	    newlen += 8 * (newlen - SvCUR(sv)); /* avoid copy each time */
     }
     else
     {
@@ -1555,22 +1555,22 @@ Perl_sv_grow(pTHX_ SV *const sv, STRLEN newlen)
 #endif
 
 #if defined(PERL_USE_MALLOC_SIZE) && defined(Perl_safesysmalloc_size)
-#define PERL_UNWARANTED_CHUMMINESS_WITH_MALLOC
+#undef PERL_UNWARANTED_CHUMMINESS_WITH_MALLOC
 #endif
 
     if (newlen > SvLEN(sv)) {		/* need more room? */
+#if 0
 	STRLEN minlen = SvCUR(sv);
-	minlen += (minlen >> PERL_STRLEN_EXPAND_SHIFT) + 10;
+	minlen += (minlen >> PERL_STRLEN_EXPAND_SHIFT) + 2;
 	if (newlen < minlen)
 	    newlen = minlen;
-#ifndef PERL_UNWARANTED_CHUMMINESS_WITH_MALLOC
-
+/*#ifndef PERL_UNWARANTED_CHUMMINESS_WITH_MALLOC */
+#endif
         /* Don't round up on the first allocation, as odds are pretty good that
          * the initial request is accurate as to what is really needed */
         if (SvLEN(sv)) {
             newlen = PERL_STRLEN_ROUNDUP(newlen);
         }
-#endif
 	if (SvLEN(sv) && s) {
 	    s = (char*)saferealloc(s, newlen);
 	}

@p5pRT
Copy link
Author

p5pRT commented Oct 7, 2014

From @tonycoz

On Mon Sep 01 12​:43​:17 2014, rurban wrote​:

READ of size 6 at 0x60200004ec15 thread T0
#0 0x454c58 in __interceptor_memcmp
(/home/rurban/Perl/src/build-5.21.4d-nt-asan@​32818149/perl+0x454c58)
#1 0x7f7f605aebc0 in modify_SV_attributes
/home/rurban/Perl/src/build-5.21.4d-nt-
asan@​32818149/ext/attributes/attributes.xs​:100
#2 0x7f7f605a0042 in XS_attributes__modify_attrs
/home/rurban/Perl/src/build-5.21.4d-nt-
asan@​32818149/ext/attributes/attributes.xs​:134
#3 0x7f7f64c97653 in Perl_pp_entersub
/home/rurban/Perl/src/build-5.21.4d-nt-asan@​32818149/pp_hot.c​:2784
#4 0x7f7f6498ac8a in Perl_runops_debug
/home/rurban/Perl/src/build-5.21.4d-nt-asan@​32818149/dump.c​:2358
#5 0x7f7f642d077b in S_run_body
/home/rurban/Perl/src/build-5.21.4d-nt-asan@​32818149/perl.c​:2408
#6 0x7f7f642cc3f2 in perl_run
/home/rurban/Perl/src/build-5.21.4d-nt-asan@​32818149/perl.c​:2336
#7 0x47b95f in main
/home/rurban/Perl/src/build-5.21.4d-nt-asan@​32818149/perlmain.c​:114
#8 0x7f7f63114b44 (/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
#9 0x47b2dc in _start
(/home/rurban/Perl/src/build-5.21.4d-nt-asan@​32818149/perl+0x47b2dc)

This is caused by a wrong memcmp in attributes.xs​:100
patch attached

That patch also includes a change unrelated to attributes.xs.

I plan to apply the attached subset of that patch.

That said, that little change did seem to make a difference in performance on both Linux and darwin, but the problem is without knowing why, we can't tell if it will degrade performance on other operating systems, or even on different versions of the same operating systems.

As to your original patch, I got the impression from the "All gone" thread that you'd prefer that we only did our own exponential allocation growth on systems that require it - Win32 in particular.

Can you think of a Configure test we could do to detect systems that need that?

I tried a simple program​:

int main() {
  size_t sz = 100;
  void *p = malloc(sz);
  void *g = malloc(sz);
  size_t schanges = 0, bchanges = 0;

  for (; sz < 1000; ++sz) {
  void *np = realloc(p, sz);
  if (np == NULL)
  exit(1);
  if (np != p) {
  ++schanges;
  p = np;
  free(g);
  g = malloc(sz);
  }
  }

  for (;sz < 10000; ++sz) {
  void *np = realloc(p, sz);
  if (np == NULL)
  exit(1);
  if (np != p) {
  ++bchanges;
  p = np;
  free(g);
  g = malloc(sz);
  }
  }
  free(p);

  printf("s %lu b %lu\n", (unsigned long)schanges,
  (unsigned long)bchanges);
  return 0;
}

which produced​:

Win32​: s 1 b 7
Cygwin​: s 1 b 0
Linux (Debian)​: s 3 b 0

With larger sizes the results were a bit less slanted towards Win32 being bad, and Cygwin/Linux being good, eg. for start 1000, second 100000, third 1000000​:

Win32​: s 16 b 17
Cygwin​: s 3 b 14
Linux​: s 1 b 5

but I suspect the larger sizes gets into sizes where the implementation uses page mapping rather than memcpy() to move memory around when the block needs to be moved.

Tony

@p5pRT
Copy link
Author

p5pRT commented Oct 7, 2014

From @tonycoz

0001-fix-attributes-memcmp-without-len-6-asan-catch.patch
From 695ce2ba362b7e35d71f857e4e38581dbab936eb Mon Sep 17 00:00:00 2001
From: Reini Urban <rurban@x-ray.at>
Date: Tue, 7 Oct 2014 15:44:27 +1100
Subject: [PATCH] fix attributes memcmp without len<6 (asan catch)

---
 ext/attributes/attributes.pm |    2 +-
 ext/attributes/attributes.xs |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/ext/attributes/attributes.pm b/ext/attributes/attributes.pm
index ebca214..6ca9ce5 100644
--- a/ext/attributes/attributes.pm
+++ b/ext/attributes/attributes.pm
@@ -1,6 +1,6 @@
 package attributes;
 
-our $VERSION = 0.23;
+our $VERSION = 0.24;
 
 @EXPORT_OK = qw(get reftype);
 @EXPORT = ();
diff --git a/ext/attributes/attributes.xs b/ext/attributes/attributes.xs
index 6b36812..c131734 100644
--- a/ext/attributes/attributes.xs
+++ b/ext/attributes/attributes.xs
@@ -97,7 +97,7 @@ modify_SV_attributes(pTHX_ SV *sv, SV **retlist, SV **attrlist, int numattrs)
 	    }
 	    break;
 	default:
-	    if (memEQs(name, len, "shared")) {
+	    if (len == 6 && memEQs(name, len, "shared")) {
 			if (negated)
 			    Perl_croak(aTHX_ "A variable may not be unshared");
 			SvSHARE(sv);
-- 
1.7.10.4

@p5pRT
Copy link
Author

p5pRT commented Oct 7, 2014

From @iabyn

On Mon, Oct 06, 2014 at 10​:48​:12PM -0700, Tony Cook via RT wrote​:

That said, that little change did seem to make a difference in performance on both Linux and darwin, but the problem is without knowing why, we can't tell if it will degrade performance on other operating systems, or even on different versions of the same operating systems.

I'm currently working on looking at the whole sv_grow() and COW and
everything interaction. I'll be making a posting soon on the sv_grow()
thread.

--
The Enterprise successfully ferries an alien VIP from one place to another
without serious incident.
  -- Things That Never Happen in "Star Trek" #7

@p5pRT
Copy link
Author

p5pRT commented Oct 7, 2014

From @tonycoz

On Mon Oct 06 22​:48​:11 2014, tonyc wrote​:

On Mon Sep 01 12​:43​:17 2014, rurban wrote​:

This is caused by a wrong memcmp in attributes.xs​:100
patch attached

That patch also includes a change unrelated to attributes.xs.

I plan to apply the attached subset of that patch.

I've applied that subset to blead as ff5314c.

Tony

@p5pRT
Copy link
Author

p5pRT commented Oct 8, 2014

From @doughera88

On Tue, Oct 07, 2014 at 04​:32​:28PM -0700, Tony Cook via RT wrote​:

On Mon Oct 06 22​:48​:11 2014, tonyc wrote​:

On Mon Sep 01 12​:43​:17 2014, rurban wrote​:

This is caused by a wrong memcmp in attributes.xs​:100
patch attached

That patch also includes a change unrelated to attributes.xs.

I plan to apply the attached subset of that patch.

I've applied that subset to blead as ff5314c.

Sorry I didn't catch this sooner. This should be reverted (though it's
really no big deal) since I already fixed that problem more succinctly
in commit dd36996. That was in [perl #122701], which is marked
as resolved (thanks to FC for wrangling the bug tracker!). The
memEQs macro is designed for just this sort of thing, when called correctly,
and the extra len check is redundant.

--
  Andy Dougherty doughera@​lafayette.edu

@p5pRT
Copy link
Author

p5pRT commented Jan 10, 2015

From @steve-m-hay

On Tue Oct 07 17​:39​:43 2014, doughera wrote​:

On Tue, Oct 07, 2014 at 04​:32​:28PM -0700, Tony Cook via RT wrote​:

On Mon Oct 06 22​:48​:11 2014, tonyc wrote​:

On Mon Sep 01 12​:43​:17 2014, rurban wrote​:

This is caused by a wrong memcmp in attributes.xs​:100
patch attached

That patch also includes a change unrelated to attributes.xs.

I plan to apply the attached subset of that patch.

I've applied that subset to blead as
ff5314c.

Sorry I didn't catch this sooner. This should be reverted (though
it's
really no big deal) since I already fixed that problem more succinctly
in commit dd36996. That was in [perl #122701], which is marked
as resolved (thanks to FC for wrangling the bug tracker!). The
memEQs macro is designed for just this sort of thing, when called
correctly,
and the extra len check is redundant.

Now reverted in commit 46fa4d9.

@p5pRT
Copy link
Author

p5pRT commented Jan 10, 2015

@steve-m-hay - Status changed from 'open' to 'pending release'

@p5pRT
Copy link
Author

p5pRT commented Jun 2, 2015

From @khwilliamson

Thanks for submitting this ticket

The issue should be resolved with the release today of Perl v5.22. If you find that the problem persists, feel free to reopen this ticket

--
Karl Williamson for the Perl 5 porters team

@p5pRT
Copy link
Author

p5pRT commented Jun 2, 2015

@khwilliamson - Status changed from 'pending release' to 'resolved'

@p5pRT p5pRT closed this as completed Jun 2, 2015
@p5pRT
Copy link
Author

p5pRT commented Jun 2, 2015

From @rurban

How is this resolved?

You still have the problematic code​:

  if (newlen > SvLEN(sv))
  newlen += 10 * (newlen - SvCUR(sv)); /* avoid copy each time */

Empty COW strings with CUR=0 ended up allocated as LEN=10.
Now they are rounded up to 4 or 8.

  Timings​:
  +0 16.394324103 0.27%
  +2 16.114379842 0.01%
  +4 16.305622265 1.03%
  +8 16.337438609 1.30%
  +10 16.675009468 0.59%
  with LD_LIBRARY_PATH=`pwd` perf stat -r2 ./perl t/harness t/op/*.t

  +2 was consistently the best number, and +10 the worst.
--
Reini Urban

@p5pRT
Copy link
Author

p5pRT commented Jun 23, 2015

From @iabyn

On Tue, Jun 02, 2015 at 01​:20​:39PM -0700, Reini Urban via RT wrote​:

How is this resolved?

It was marked "pending release" in Jan, which was automatically upgraded
to "resolved"when 5.22 was released. The original marking was in error,
due to, I guess, the attributes.xs part of the patch being applied and not
the sv_grow part, and someone foretting that the grow part still wasn't
resolved.

I'll re-open the ticket.

I still intend to provide a more general fix for this by probing the
OS's malloc and realloc behaviour.

--
I thought I was wrong once, but I was mistaken.

@p5pRT
Copy link
Author

p5pRT commented Jun 23, 2015

@iabyn - Status changed from 'resolved' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Jun 23, 2015

From @rurban

On Jun 23, 2015, at 5​:18 PM, Dave Mitchell via RT <perlbug-followup@​perl.org> wrote​:

On Tue, Jun 02, 2015 at 01​:20​:39PM -0700, Reini Urban via RT wrote​:

How is this resolved?

It was marked "pending release" in Jan, which was automatically upgraded
to "resolved"when 5.22 was released. The original marking was in error,
due to, I guess, the attributes.xs part of the patch being applied and not
the sv_grow part, and someone foretting that the grow part still wasn't
resolved.

I'll re-open the ticket.

I still intend to provide a more general fix for this by probing the
OS's malloc and realloc behaviour

Great, thanks.
Although I suspect it will fall under the noise mark, 2%.

My benchmark showed a bigger slowdown caused by this, but I don’t know exactly why.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants