Closed p5pRT closed 18 years ago
This is a bug report for perl from jerry@hedden.us\, generated with the help of perlbug 1.35 running under perl v5.8.7.
When a scalar variable is tagged with the :shared attribute and then assigned a shared ref\, the variable's refaddr is not constant.
If the :shared attribute is not used\, the refaddr is constant (as it should be).
The sample code below illustrates the bug:
===== Begin shared_refaddr_bug.pl =====
use threads; use threads::shared;
# Variable with ':shared' attribute my $shared :shared = &share({}); $$shared{'foo'} = 'bar';
print("Print refaddr of :shared var\n"); print("It alternates between two value!\n"); print($shared\, "\n"); print($shared\, "\n"); print($shared\, "\n"); print($shared\, "\n"); print($shared\, "\n"); print($shared\, "\n\n");
# Variable without ':shared' attribute my $var = &share({});
print("Print refaddr of var without :shared\n"); print("Same address each time\n"); print("However\, it's the same as one of the above!\n"); print($var\, "\n"); print($var\, "\n"); print($var\, "\n"); print($var\, "\n"); print($var\, "\n"); print($var\, "\n\n");
print("Print refaddr of :shared var\, again\n"); print("It alternates again\, but with a new address\n"); print($shared\, "\n"); print($shared\, "\n"); print($shared\, "\n"); print($shared\, "\n"); print($shared\, "\n"); print($shared\, "\n\n");
===== End shared_refaddr_bug.pl =====
===== Output from the above =====
Print refaddr of :shared var It alternates between two value! HASH(0x10010fa8) HASH(0x100110b0) HASH(0x10010fa8) HASH(0x100110b0) HASH(0x10010fa8) HASH(0x100110b0)
Print refaddr of var without :shared Same address each time However\, it's the same as one of the above! HASH(0x10010fa8) HASH(0x10010fa8) HASH(0x10010fa8) HASH(0x10010fa8) HASH(0x10010fa8) HASH(0x10010fa8)
Print refaddr of :shared var\, again It alternates again\, but with a new address HASH(0x1002ee78) HASH(0x100110b0) HASH(0x1002ee78) HASH(0x100110b0) HASH(0x1002ee78) HASH(0x100110b0)
=================================
I tested this on Cygwin 5.8.7 and Solaris 5.8.0\, 5.8.2 and 5.8.7 with the same results for all.
I initially encounted this bug with the following:
===== Begin bug_oio.pl =====
use threads; use threads::shared;
package My::Class; { use Object::InsideOut ':SHARED'; }
package main;
# New object my $obj :shared = My::Class->new();
print("$obj $$obj\n"); print("$obj $$obj\n"); print("$obj $$obj\n"); print("$obj $$obj\n"); print("$obj $$obj\n"); print("$obj $$obj\n");
===== End bug_oio.pl =====
===== Output from the above =====
My::Class=SCALAR(0x101466cc) 1 My::Class=SCALAR(0x101e2544) My::Class=SCALAR(0x101466cc) My::Class=SCALAR(0x101e2544) My::Class=SCALAR(0x101466cc) My::Class=SCALAR(0x101e2544)
=================================
This not only shows the alternating refaddr\, but also shows that the contents of the scalar ref is getting wiped out. Unfortunately\, I was not able to produce this latter behavior in a sample that doesn't use Object::InsideOut.
Flags: category=core severity=high
Site configuration information for perl v5.8.7:
Configured by Jerry at Wed Dec 14 13:31:18 EST 2005.
Summary of my perl5 (revision 5 version 8 subversion 7) configuration: Platform: osname=cygwin\, osvers=1.5.18(0.13242)\, archname=cygwin-thread-multi-64int uname='cygwin_nt-5.0 pn100-01-1-123s 1.5.18(0.13242) 2005-07-02 20:30 i686 unknown unknown cygwin ' config_args='-de -Duse64bitint -Dusethreads -Uusemymalloc -A define:optimize=-O3 -pipe -frename-registers -fomit-frame-pointer -march=pentium4 -mfpmath=sse -mmmx -msse -msse2 -A define:ld=/usr/local/bin/ld2' hint=recommended\, useposix=true\, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=undef uselongdouble=undef usemymalloc=n\, bincompat5005=undef Compiler: cc='gcc'\, ccflags ='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include'\, optimize='-O3 -pipe -frename-registers -fomit-frame-pointer -march=pentium4 -mfpmath=sse -mmmx -msse -msse2'\, cppflags='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include' ccversion=''\, gccversion='3.4.4 (cygming special) (gdc 0.12\, using dmd 0.125)'\, gccosandvers='' intsize=4\, longsize=4\, ptrsize=4\, doublesize=8\, byteorder=12345678 d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=12 ivtype='long long'\, ivsize=8\, nvtype='double'\, nvsize=8\, Off_t='off_t'\, lseeksize=8 alignbytes=8\, prototype=define Linker and Libraries: ld='/usr/local/bin/ld2'\, ldflags =' -s -L/usr/local/lib' libpth=/usr/local/lib /usr/lib /lib libs=-lgdbm -ldb -lcrypt -lgdbm_compat perllibs=-lcrypt -lgdbm_compat libc=/usr/lib/libc.a\, so=dll\, useshrplib=true\, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs\, dlext=dll\, d_dlsymun=undef\, ccdlflags=' -s' cccdlflags=' '\, lddlflags=' -s -L/usr/local/lib'
Locally applied patches:
@INC for perl v5.8.7: /usr/local/lib/perl5/5.8/cygwin /usr/local/lib/perl5/5.8 /usr/local/lib/perl5/site_perl/5.8/cygwin /usr/local/lib/perl5/site_perl/5.8 /usr/local/lib/perl5/vendor_perl/5.8/cygwin /usr/local/lib/perl5/vendor_perl/5.8 .
Environment for perl v5.8.7:
CYGWIN=server ntsec forkchunk:32768
HOME=/home/jhedden
LANG=C
LANGUAGE=C
LC_ALL=C
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/home/jhedden/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/c/MinGW/bin:/c/Perl/bin/:/c/djgpp/bin:/c/Program
Files/WiX:/c/Program Files/nant-0.85-rc3/bin:/c/Program
Files/apache-ant-1.6.3/bin:/c/j2sdk1.4.2_08/bin:/c/Program
Files/Documentum/Shared:/c/blp/API:/c/oracle/ora92/bin:/c/Program
Files/Oracle/jre/1.3.1/bin:/c/Program
Files/Oracle/jre/1.1.8/bin:/c/WINNT/system32:/c/WINNT:/c/WINNT/system32/WBEM:/c/Program
Files/cvsnt:/usr/local/lib:.
PERLIO=perlio
PERL_BADLANG (unset)
SHELL (unset)
On Wed\, Dec 14\, 2005 at 12:09:12PM -0800\, Jerry D. Hedden wrote:
Print refaddr of :shared var It alternates between two value! HASH(0x10010fa8) HASH(0x100110b0) HASH(0x10010fa8) HASH(0x100110b0) HASH(0x10010fa8) HASH(0x100110b0)
It seems that it's always a temporary copy\, freshly allocated for each call\, and correctly freed up\, so 2 particular memory locations are being used alternatively for the temporary:
My limited understanding of the threads::shared is that there is a master copy of everything in a private perl interpreter (the "shared space") and every shared variable you can access is a local proxy associated with the master. What we have here is a shared scalar referencing a shared (anonymous) hash - 2 SVs\, so what the local perl interpreter is dealing with are the 2 proxies.
Getting data to/from the proxies to the master copy is implemented by the perl "magic" system. The code for the magic get for the scalar (the reference) (get to the proxy)is in ext/threads/shared.xs:
int sharedsv_scalar_mg_get(pTHX_ SV *sv\, MAGIC *mg) { shared_sv *shared = (shared_sv *) mg->mg_ptr; assert(shared);
ENTER_LOCK;
if (SHAREDSvPTR(shared)) {
if (SvROK(SHAREDSvPTR(shared))) {
SV *obj = Nullsv;
Perl_sharedsv_associate(aTHX_ &obj\, SvRV(SHAREDSvPTR(shared))\, NULL);
sv_setsv_nomg(sv\, &PL_sv_undef);
SvRV_set(sv\, obj);
SvROK_on(sv);
}
else {
sv_setsv_nomg(sv\, SHAREDSvPTR(shared));
}
}
LEAVE_LOCK;
return 0;
}
It seems that the bug is in the argument &obj to Perl_sharedsv_associate. Nullsv is (SV *)0
(why does the code love to do this? Does it date back to the time before ANSI prototypes?)
which being a pointer to a NULL\, makes the code in Perl_sharedsv_associate create a new thread-local proxy\, rather than re-using the same one.
The second and subsequent time sharedsv_scalar_mg_get is called\, it happens that the variable sv is proxy reference\, pointing to a proxy anonymous hash copy generated last call.
The call to Perl_sharedsv_associate generates a new proxy for the hash. The next line
sv_setsv_nomg(sv\, &PL_sv_undef);
has the effect of neatly undefining the proxy reference\, so the (previous) proxy hash is no longer referenced by anything\, and freed. This explains the cycling between 2 values - the old proxy is freed just after the new proxy is allocated.
I think that what the code in sharedsv_scalar_mg_get should be doing in the general case is passing in a pointer to the previous value\, so that the same proxy can be re-used\, but I'm not sure how this works for the first call.
I'm not familiar with this code\, and not sure of the best way to fix this.
Nicholas Clark
The RT System itself - Status changed from 'new' to 'open'
On Thu\, Dec 15\, 2005 at 10:55:24PM +0000\, Nicholas Clark wrote:
I'm not familiar with this code\, and not sure of the best way to fix this.
At this point I'll add my usual mournful refrain: "once I get some tuits I'll have a look"
-- Thank God I'm an atheist.....
On Wed\, Dec 14\, 2005 at 12:09:12PM -0800\, Jerry D. Hedden wrote:
I initially encounted this bug with the following:
This not only shows the alternating refaddr\, but also shows that the contents of the scalar ref is getting wiped out. Unfortunately\, I was not able to produce this latter behavior in a sample that doesn't use Object::InsideOut.
I should have added to my original message - to me it seems worth seeing if solving the reference address problem turns out to resolve the problem with the contents being wiped out.
Nicholas Clark
On Thu\, Dec 15\, 2005 at 10:55:24PM +0000\, Nicholas Clark wrote:
On Wed\, Dec 14\, 2005 at 12:09:12PM -0800\, Jerry D. Hedden wrote:
Print refaddr of :shared var It alternates between two value! HASH(0x10010fa8) HASH(0x100110b0) HASH(0x10010fa8) HASH(0x100110b0) HASH(0x10010fa8) HASH(0x100110b0)
It seems that it's always a temporary copy\, freshly allocated for each call\, and correctly freed up\, so 2 particular memory locations are being used alternatively for the temporary:
Essentially fixed by change #26695
Basically\, every time an mg_get() was done on a private SV who's shared twin in shared space was an RV\, a new private-side referent was created for it to point at. The code now preserves the old referent if its suitable: ie if its magic points to the right shared referent and they're the same type.
This also makes thing go faster: the following code:
our @a : shared; for (1..10_000_000) { $a[$_ % 10_000]++; }
which I made go 13% faster yesterday with change #26684\, is now a further 7% faster with this new change\, for a cummulative speedup of 20%.
Which is nice.
Dave
-- print+qq&$}$"$/$s$\,$*${d}$g$s$@$.$q$\,$:$.$q$^$\,$@$*$~$;$.$q$m&if+map{m\,^\d{0\\,}\,\,${$::{$'}}=chr($"+=$&||1)}q&10m22\,42}6:17*2~2.3@3;^2dg3q/s"&=~m*\d\*.*g
On Sat\, Jan 07\, 2006 at 03:25:40AM +0000\, Dave Mitchell wrote:
This also makes thing go faster: the following code:
our @​a : shared; for \(1\.\.10\_000\_000\) \{ $a\[$\_ % 10\_000\]\+\+; \}
which I made go 13% faster yesterday with change #26684\, is now a further 7% faster with this new change\, for a cummulative speedup of 20%.
ObMath: 13% + 7% = 21%
-----BEGIN PGP SIGNED MESSAGE-----
Moin\,
Yitzchak Scott-Thoennes \sthoenna@​efn\.org scribbled:
On Sat\, Jan 07\, 2006 at 03:25:40AM +0000\, Dave Mitchell wrote:
This also makes thing go faster: the following code:
our @​a : shared; for \(1\.\.10\_000\_000\) \{ $a\[$\_ % 10\_000\]\+\+; \}
which I made go 13% faster yesterday with change #26684\, is now a further 7% faster with this new change\, for a cummulative speedup of 20%.
You are my hero! (This somehow suggests\, that apart from being buggy\, threads were slow in Perl. I know why I avoid them like the plague :)
Yitzchak wrote:
ObMath: 13% + 7% = 21%
It depends on how you round:
1.13 * 1.07 = 1.2091
See http://www.pldesignline.com/howto/showArticle.jhtml;?articleID=175801189 for reference :)
Best wishes\,
Tels
- -- Signed on Sun Jan 8 10:58:36 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.
"Retsina?" - "Ja\, Papa?" - "Rasenmähen." - "Is gut\, Papa."
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iQEVAwUBQ8DjT3cLPEOTuEwVAQGpYQf9ENzQ1B6E/hlUdi1FMsRFUJ1PoemB5YiQ EhNcm03VhsWvXq+3JotZwKC3JhN/NDIfPc3rI25LXwESE2ospfkwr84qWf98Hn3q jpdIvH5lvEXVtkpBr8J685VkzRkNaWeZPRV9uKFYjPI0LNBW9RoW4d3LzRvfvGKd UwO1n5g/F9zzuHFV/M3XFb3URfZ1j40ee8q3W6kIf3tOuWkOyIFTdFs8yeJPiNDY MpUzj5fDX+aHoLqG46Mmk6HpFsaIkN0ck3rqzidvY9d68UtgoQo6DugK3D7Q1w8q QJb8fNgifsyAzcOIh3StGW5qczRx2JvOqqIlM4azZKlYgYF88Kz8PQ== =/sj0 -----END PGP SIGNATURE-----
Yitzchak Scott-Thoennes a écrit :
On Sat\, Jan 07\, 2006 at 03:25:40AM +0000\, Dave Mitchell wrote:
This also makes thing go faster: the following code:
our @​a : shared; for \(1\.\.10\_000\_000\) \{ $a\[$\_ % 10\_000\]\+\+; \}
which I made go 13% faster yesterday with change #26684\, is now a further 7% faster with this new change\, for a cummulative speedup of 20%.
ObMath: 13% + 7% = 21%
... when using base 9 arithmetic
David -- "It's overkill of course\, but you can never have too much overkill."
On Sun\, 2006-01-08 at 17:52 +0100\, David Landgren wrote:
Yitzchak Scott-Thoennes a écrit :
On Sat\, Jan 07\, 2006 at 03:25:40AM +0000\, Dave Mitchell wrote:
This also makes thing go faster: the following code:
our @​a : shared; for \(1\.\.10\_000\_000\) \{ $a\[$\_ % 10\_000\]\+\+; \}
which I made go 13% faster yesterday with change #26684\, is now a further 7% faster with this new change\, for a cummulative speedup of 20%.
ObMath: 13% + 7% = 21%
... when using base 9 arithmetic
1.13 * 1.07 = 1.2091 which is approximately 21%
Vadim Konovalov wrote:
On Sun\, 2006-01-08 at 17:52 +0100\, David Landgren wrote:
Yitzchak Scott-Thoennes a écrit :
On Sat\, Jan 07\, 2006 at 03:25:40AM +0000\, Dave Mitchell wrote:
This also makes thing go faster: the following code:
our @a : shared; for (1..10_000_000) { $a[$_ % 10_000]++; }
which I made go 13% faster yesterday with change #26684\, is now a further 7% faster with this new change\, for a cummulative speedup of 20%.
ObMath: 13% + 7% = 21%
... when using base 9 arithmetic
1.13 * 1.07 = 1.2091 which is approximately 21%
um .. shouldnt we be testing something ?
just a thought...
:-)
-----BEGIN PGP SIGNED MESSAGE-----
Math\,
Jim Cromie wrote:
Vadim Konovalov wrote:
On Sun\, 2006-01-08 at 17:52 +0100\, David Landgren wrote:
Yitzchak Scott-Thoennes a écrit :
On Sat\, Jan 07\, 2006 at 03:25:40AM +0000\, Dave Mitchell wrote:
which I made go 13% faster yesterday with change #26684\, is now a 7% faster with this new change\, for a cummulative speedup of 20%. ObMath: 13% + 7% = 21% ... when using base 9 arithmetic 1.13 * 1.07 = 1.2091 which is approximately 21% um .. shouldnt we be testing something ?
Yeah\, BigFloat's rounding modes:
# perl -Mbignum -le 'print +(1.13 * 1.07)->round(3\,undef\,"trunc")' 1.20 # perl -Mbignum -le 'print +(1.13 * 1.07)->round(3\,undef\,"zero")' 1.21
Sorry\, sorry\, I go and kill myself now... :o)
Tels
- -- Signed on Sun Jan 8 22:22:16 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.
"HOT PACKET ON SERVER ACTION! Click here for FREE ACCESS to streaming video of dirty packets penetrating badly-configured firewalls!!!" aanand (705284) on 2004-03-20 on /. about the Adult Bit and the Evil bit
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iQEVAwUBQ8GDI3cLPEOTuEwVAQEgWwf/U+lNo+HZrIDBn6rC1gDb91RR3zcBDtIg N5+dU8UcIlGp2sqPKHxT00ObWH9LK2e2Pdn036sdgbDhPASp49RK/P9/6UpUwjbo 72yICIXCmWKu+SUJlIucwIRul7j3AeGz/C5yKXPzeVqTRogWkK27V0sU05c+RGif Ec6bdyLn8qGs/VSpxc94EHStQU0dIrKbknbEQ07NQ1mYagGyEKdtpRxZQVhYRcy4 mS8IeaAKlDUyo9+0cmA+mxjVdHDWatCeH1RX5KwSAkGo22DLM9DrpfcVQmzEeK47 bVCuz7D4jLakhMhUM+HwXvVpfmSRSwv1RmDbAg4YLiUpQhybfkYK0w== =80/N -----END PGP SIGNATURE-----
[davem@iabyn.com - Fri Jan 06 19:24:29 2006]: Essentially fixed by change #26695
The attached diffs (patch ?) includes changes to shared.xs from patches 26684\, 26693 and 26695. It was made against maint up to patch 26748.
It excludes changes from patch 26569 that deals with localizing shared variables as that patch involves others that have not yet made it into maint.
The following file is to be deleted: perl-maint/ext/threads/shared/typemap
The diffs are attached.
My hope is that this will assist Nicholas Clark in getting the above patches into the 5.8.8 release.
Thanks\, Jerry D. Hedden jdhedden AT cpan DOT org
On Mon\, Jan 09\, 2006 at 01:01:42PM -0800\, Guest via RT wrote:
My hope is that this will assist Nicholas Clark in getting the above patches into the 5.8.8 release.
As it doesn't change anything outside of the ext/threads/shared directory then it seems that an alternative plan would be to make the module dual life and upload this version to CPAN directly.
I'm loathe to put this code in maint\, as it's not yet proven to be stable. Having it on CPAN gives people the option to use it\, rather than forcing it on their existing installations when they upgrade.
Nicholas Clark
On Tue\, Jan 10\, 2006 at 10:14:29AM +0000\, Nicholas Clark wrote:
On Mon\, Jan 09\, 2006 at 01:01:42PM -0800\, Guest via RT wrote:
My hope is that this will assist Nicholas Clark in getting the above patches into the 5.8.8 release. [snip] I'm loathe to put this code in maint\, as it's not yet proven to be stable.
Yes\, since its mainly an efficiency improvemnt rather than bugfix\, and since it involved a fairly major rewrite of shared.xs\, I don't think it's suitable for maint.
-- To collect all the latest movies\, simply place an unprotected ftp server on the Internet\, and wait for the disk to fill....
On Tue\, Jan 10\, 2006 at 12:36:00PM +0000\, Dave Mitchell wrote:
On Tue\, Jan 10\, 2006 at 10:14:29AM +0000\, Nicholas Clark wrote:
On Mon\, Jan 09\, 2006 at 01:01:42PM -0800\, Guest via RT wrote:
My hope is that this will assist Nicholas Clark in getting the above patches into the 5.8.8 release. [snip] I'm loathe to put this code in maint\, as it's not yet proven to be stable.
Yes\, since its mainly an efficiency improvemnt rather than bugfix\, and since it involved a fairly major rewrite of shared.xs\, I don't think it's suitable for maint.
I actually don't mind efficiency improvements.
It's the rewrite part that makes me cautious. If there's a development release (5.9.3) and then no-one reports any bugs or finds any other need to change the code for some months\, then it would appear that it's stable. (Plus I'd look carefully at it to see if I could spot any problems)
But it takes time for "time passes" to have happened.
Nicholas Clark
On Mon\, Jan 09\, 2006 at 01:01:42PM -0800\, Guest via RT wrote:
My hope is that this will assist Nicholas Clark in getting the above patches into the 5.8.8 release.
Nicholas Clark via RT replied:
As it doesn't change anything outside of the ext/threads/shared directory then it seems that an alternative plan would be to make the module dual life and upload this version to CPAN directly.
If everyone else is too busy with other things\, I could try to do the initial work of creating the module for upload to PAUSE. However\, I'm obviously not familiar enough with the code to be the maintainer\, and thus should not be the one to do the actual upload.
Just let me know. Thanks.
Jerry D. Hedden jdhedden AT cpan DOT org
On 1/10/06\, Nicholas Clark \nick@​ccl4\.org wrote:
On Tue\, Jan 10\, 2006 at 12:36:00PM +0000\, Dave Mitchell wrote:
On Tue\, Jan 10\, 2006 at 10:14:29AM +0000\, Nicholas Clark wrote:
On Mon\, Jan 09\, 2006 at 01:01:42PM -0800\, Guest via RT wrote:
My hope is that this will assist Nicholas Clark in getting the above patches into the 5.8.8 release. [snip] I'm loathe to put this code in maint\, as it's not yet proven to be stable.
Yes\, since its mainly an efficiency improvemnt rather than bugfix\, and since it involved a fairly major rewrite of shared.xs\, I don't think it's suitable for maint.
I actually don't mind efficiency improvements.
It's the rewrite part that makes me cautious. If there's a development release (5.9.3) and then no-one reports any bugs or finds any other need to change the code for some months\, then it would appear that it's stable. (Plus I'd look carefully at it to see if I could spot any problems)
But it takes time for "time passes" to have happened.
Does that mean that there is a chance getting the trie optimisation into maint?
I seem to recall that Yitzchak put together patch at one time...
yves
-- perl -Mre=debug -e "/just|another|perl|hacker/"
On Sun\, Jan 08\, 2006 at 11:02:55AM +0100\, Tels wrote:
On Sat\, Jan 07\, 2006 at 03:25:40AM +0000\, Dave Mitchell wrote:
This also makes thing go faster: the following code:
our @​a : shared; for \(1\.\.10\_000\_000\) \{ $a\[$\_ % 10\_000\]\+\+; \}
which I made go 13% faster yesterday with change #26684\, is now a further 7% faster with this new change\, for a cummulative speedup of 20%.
You are my hero! (This somehow suggests\, that apart from being buggy\, threads were slow in Perl. I know why I avoid them like the plague :)
Er\, not really. Threads are slow to start up\, and use lots of memory\, but once they're running\, they're as fast as normal code. The only exception being that access to *shared* variables is slow\, roughly comparable to tied variable access:
consider the basic loop from above (all timings using -O builds):
for (1..10_000_000) { $a[$_ % 10_000]++; }
This takes 3.8/4.0s for a plain array on unthreaded/threaded builds;
make @a tied and the loop takes 47.9s (12 times slower):
use Tie::Array; tie @a\, 'Tie::StdArray';
make @a shared instead and the loop takes 48.2s; or 27.4s(*) after my recent patching:
use threads; use threads::shared; our @a : shared;
But any decent multi-threaded code should be making sparse use of shared variables anyway\, as regardless of their implementation they will become a bottleneck between threads. On my 4 CPU x86_64 system\, running that loop on several threads never saturated more than 2 CPUs\, since most threads were waiting on locks to get at the shared variable.
Dave
(*) yes\, that's a 43% speedup\, not 20/21%. I got my sums wrong :-)
-- "I do not resent critisism\, even when\, for the sake of emphasis\, it parts for the time with reality". -- Winston Churchill\, House of Commons\, 22nd Jan 1941.
All righty then. It think I've got threads::shared all ready for CPAN!
I've extracted threads::shared from the Perl distribution. Bumped up the version to 0.94. Created MANIFEST and Changes files. Cleaned up the Makefile.PL. Prettied up the code a tad. Added ppport.h. Got it to compile. Cleaned up the tests. Added some new tests for the bug fixes that started all this. Tested it with the latest 5.8 maint under Cygwin. Tested it with 5.8.0 through 5.9.2 under Solaris. Added some missing macros that compiling under released versions of Perl turned up. Removed 'bug' about 'bless' on shared refs from the POD. (That works now!)
Now then\, who is going to be the official maintainer of this so I can hand it off for final inspecition and uploading to CPAN? Dave Mitchell?
Jerry D. Hedden jdhedden AT cpan DOT org
On Tue\, Jan 10\, 2006 at 10:04:23AM -0800\, Guest via RT wrote:
Now then\, who is going to be the official maintainer of this so I can hand it off for final inspecition and uploading to CPAN? Dave Mitchell?
Note that I've never uploaded anything to CPAN\, and don't\, at this moment in time\, want to get involved in learning.
-- There's a traditional definition of a shyster: a lawyer who\, when the law is against him\, pounds on the facts; when the facts are against him\, pounds on the law; and when both the facts and the law are against him\, pounds on the table. -- Eben Moglen referring to SCO
On Tue\, Jan 10\, 2006 at 08:30:29PM +0000\, Dave Mitchell wrote:
On Tue\, Jan 10\, 2006 at 10:04:23AM -0800\, Guest via RT wrote:
Now then\, who is going to be the official maintainer of this so I can hand it off for final inspecition and uploading to CPAN? Dave Mitchell?
Note that I've never uploaded anything to CPAN\, and don't\, at this moment in time\, want to get involved in learning.
I could\, but the two downsides are
1: threads don't represent a personal itch to scratch 2: I'd need to write more Acme:: module to maintain balance. In fact\, I may already be out of balance
I'm not actually confident that anyone on perl5-porters actively contributing patches is using threads that much. So I'm having trouble coming up with a shortlist of "volunteers"
Nicholas Clark
On Tue\, Jan 10\, 2006 at 10:04:23AM -0800\, Guest via RT wrote:
Bumped up the version to 0.94.
Tested it with the latest 5.8 maint under Cygwin. Tested it with 5.8.0 through 5.9.2 under Solaris.
Thanks. That's good to know. I'm rebuilding my bank of perls on FreeBSD to test with.
Could the version be (at least) 0.95 please? There are a couple of documentation tweaks in 5.8.8-to-be that mean that 5.8.8 needs a different version from 5.8.7\, and 5.8.7 was 0.93
Having the higher version as the stand alone threads::shared on CPAN means that it becomes easy for anyone to upgrade using the CPAN shell.
Is your tarball anywhere online to collect?
Nicholas Clark
On Tue\, Jan 10\, 2006 at 08:33:36PM +0000\, Nicholas Clark wrote:
On Tue\, Jan 10\, 2006 at 08:30:29PM +0000\, Dave Mitchell wrote:
On Tue\, Jan 10\, 2006 at 10:04:23AM -0800\, Guest via RT wrote:
Now then\, who is going to be the official maintainer of this so I can hand it off for final inspecition and uploading to CPAN? Dave Mitchell?
Note that I've never uploaded anything to CPAN\, and don't\, at this moment in time\, want to get involved in learning.
I could\, but the two downsides are
1: threads don't represent a personal itch to scratch 2: I'd need to write more Acme:: module to maintain balance. In fact\, I may already be out of balance
I'm not actually confident that anyone on perl5-porters actively contributing patches is using threads that much. So I'm having trouble coming up with a shortlist of "volunteers"
I use threads a little and will maintain the CPAN version if no one else volunteers.
Nicholas Clark via RT wrote:
Could the version be (at least) 0.95 please?
I'll make it 0.95.
Is your tarball anywhere online to collect?
No. It's only 52K\, so I can email it to whoever wants it. Just email me directly at: jdhedden AT cpan DOT org
On Tue\, Jan 10\, 2006 at 02:56:49PM +0100\, demerphq wrote:
On 1/10/06\, Nicholas Clark \nick@​ccl4\.org wrote:
On Tue\, Jan 10\, 2006 at 12:36:00PM +0000\, Dave Mitchell wrote:
On Tue\, Jan 10\, 2006 at 10:14:29AM +0000\, Nicholas Clark wrote:
On Mon\, Jan 09\, 2006 at 01:01:42PM -0800\, Guest via RT wrote:
My hope is that this will assist Nicholas Clark in getting the above patches into the 5.8.8 release. [snip] I'm loathe to put this code in maint\, as it's not yet proven to be stable.
Yes\, since its mainly an efficiency improvemnt rather than bugfix\, and since it involved a fairly major rewrite of shared.xs\, I don't think it's suitable for maint.
I actually don't mind efficiency improvements.
It's the rewrite part that makes me cautious. If there's a development release (5.9.3) and then no-one reports any bugs or finds any other need to change the code for some months\, then it would appear that it's stable. (Plus I'd look carefully at it to see if I could spot any problems)
But it takes time for "time passes" to have happened.
Does that mean that there is a chance getting the trie optimisation into maint?
Well\, when it was added to blead I'd assumed "no\, this isn't viable for maint" but I've looked at the changes to regcomp.h\, regcomp.c and regexec.c and I can't see any externally visible structures or non-static functions that have changed. So I can't spot any fundamental binary compatibility reason why not. But the idea of putting it in to a maint 5.8 at this stage in 5.8's life makes me nervy. I'd be less nervy if there were a pragma that could disable parts the regexp optimiser\, because that way if code turned out to discover latent bugs in the trie optimisation\, then that code could be modified to disable it\, and still work.
However\, there are quite a few things I still want to think about to try to get in to 5.8.9 which fix bugs\, as well as the code cleanups in the upgrade/ dup routines and those involved with locating mathoms. I'd need to get these bumped off first.
Realistically I think it may be faster to get it in maint by making 5.10 maint. There's not a huge amount left under /Needed for a 5\.9.\d release/
I seem to recall that Yitzchak put together patch at one time...
I don't remember this. But my memory isn't perfect.
Nicholas Clark
On 1/12/06\, Nicholas Clark \nick@​ccl4\.org wrote:
On Tue\, Jan 10\, 2006 at 02:56:49PM +0100\, demerphq wrote:
On 1/10/06\, Nicholas Clark \nick@​ccl4\.org wrote: ..
I actually don't mind efficiency improvements. ... Does that mean that there is a chance getting the trie optimisation into maint?
Well\, when it was added to blead I'd assumed "no\, this isn't viable for maint" but I've looked at the changes to regcomp.h\, regcomp.c and regexec.c and I can't see any externally visible structures or non-static functions that have changed. So I can't spot any fundamental binary compatibility reason why not. But the idea of putting it in to a maint 5.8 at this stage in 5.8's life makes me nervy. I'd be less nervy if there were a pragma that could disable parts the regexp optimiser\, because that way if code turned out to discover latent bugs in the trie optimisation\, then that code could be modified to disable it\, and still work.
BEGIN { $^REG_TRIE_MAXBUF=0 }
Will disable the trie functionality if its done before the regexp is compiled.
Having said that I've been tinkering with making $^REG_TRIE_MAXBUF and $^REG_DEBUG_FLAGS go away to be replaced by lexically scoped pragmas. I havent got far with it tho\, due to lack of familiarity and an easily distractable mind.
However\, there are quite a few things I still want to think about to try to get in to 5.8.9 which fix bugs\, as well as the code cleanups in the upgrade/ dup routines and those involved with locating mathoms. I'd need to get these bumped off first.
Realistically I think it may be faster to get it in maint by making 5.10 maint. There's not a huge amount left under /Needed for a 5\.9.\d release/
Ok\, thats fair enough. Especially as it would be much nicer with lexically scoped control as you say.
I seem to recall that Yitzchak put together patch at one time...
I don't remember this. But my memory isn't perfect.
Nope\, in this case your memory is fine\, its mine that was confuzzled. Yitzchak suggested to me offline that it would be cool to do as a module\, but thats certainly beyond me right now.
Cheers\, yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
On 1/12/06\, demerphq \demerphq@​gmail\.com wrote:
BEGIN { $^REG_TRIE_MAXBUF=0 }
...
Having said that I've been tinkering with making $^REG_TRIE_MAXBUF and $^REG_DEBUG_FLAGS go away to be replaced by lexically scoped pragmas. I havent got far with it tho\, due to lack of familiarity and an easily distractable mind.
Whoops\, i meant $^RE_TRIE_MAXBUF and $^RE_DEBUG_FLAGS.
Yves
-- perl -Mre=debug -e "/just|another|perl|hacker/"
On Tue\, Jan 10\, 2006 at 10:41:48PM +0000\, Nicholas Clark wrote:
On Tue\, Jan 10\, 2006 at 10:04:23AM -0800\, Guest via RT wrote:
Bumped up the version to 0.94.
Tested it with the latest 5.8 maint under Cygwin. Tested it with 5.8.0 through 5.9.2 under Solaris.
Thanks. That's good to know. I'm rebuilding my bank of perls on FreeBSD to test with.
Could the version be (at least) 0.95 please? There are a couple of documentation tweaks in 5.8.8-to-be that mean that 5.8.8 needs a different version from 5.8.7\, and 5.8.7 was 0.93
Having the higher version as the stand alone threads::shared on CPAN means that it becomes easy for anyone to upgrade using the CPAN shell.
Is your tarball anywhere online to collect?
Nicholas\, were you volunteering to maintain it on CPAN?
If not\, I'll start working on it in the next week.
Opps. Forgot to follow this up yesterday.
On Thu\, Jan 12\, 2006 at 12:28:58PM -0800\, Yitzchak Scott-Thoennes wrote:
On Tue\, Jan 10\, 2006 at 10:41:48PM +0000\, Nicholas Clark wrote:
On Tue\, Jan 10\, 2006 at 10:04:23AM -0800\, Guest via RT wrote:
Bumped up the version to 0.94.
Tested it with the latest 5.8 maint under Cygwin. Tested it with 5.8.0 through 5.9.2 under Solaris.
Thanks. That's good to know. I'm rebuilding my bank of perls on FreeBSD to test with.
Could the version be (at least) 0.95 please? There are a couple of documentation tweaks in 5.8.8-to-be that mean that 5.8.8 needs a different version from 5.8.7\, and 5.8.7 was 0.93
Having the higher version as the stand alone threads::shared on CPAN means that it becomes easy for anyone to upgrade using the CPAN shell.
Is your tarball anywhere online to collect?
Nicholas\, were you volunteering to maintain it on CPAN?
Well\, only in that I'd like the code out and available\, but not yet forced on everyone who upgrades to 5.8.8\, and I wasn't sure that anyone else would.
If not\, I'll start working on it in the next week.
I'd be very happy if you were able to\, as it reduces by 1 the number of things I need to do.
It passed all tests on 5.8.1-5.8.7 on FreeBSD (not got 5.8.0 built yet)
ABERGMAN is the current owner of the module as recorded by PAUSE. You'd need to agree with him to become co-maintainer (or somesuch) otherwise the indexer will not index anything you upload.
Nicholas Clark
[nicholas - Thu Jan 12 12:37:42 2006]: ABERGMAN is the current owner of [threads::shared] as recorded by PAUSE. You'd need to agree with him to become co-maintainer.
FYI\, I have done this\, and uploaded threads-shared-0.95 to PAUSE a few days ago.
Jerry D. Hedden \<jhedden [at] cpan [dot] org>
@iabyn - Status changed from 'open' to 'resolved'
Migrated from rt.perl.org#37946 (status was 'resolved')
Searchable as RT37946$