Description of problem: While running this program and any other program I tried: #!/usr/bin/perl use strict; use warnings; my $x = 0; for my $i (1 .. 100_000_000) { $x = $x * 2 + 1; } I am getting this: shlomif@telaviv1:~$ time perl time-me-1.pl real 0m21.258s user 0m21.257s sys 0m0.000s shlomif@telaviv1:~$ perlbrew use 5.26.0-mt A sub-shell is launched with 5.26.0-mt as the activated perl. Run 'exit' to finish it. shlomif@telaviv1:~$ time perl time-me-1.pl real 0m6.500s user 0m6.499s sys 0m0.001s ===== It also happens if I remove the strict and warnings statements. I also recall the old 5.22.3 mageia perl being faster. Version-Release number of selected component (if applicable): Cauldron.
I've now rebuilt and installed perl from mgarepo and i am still getting the same results.
After patching the mgarepo perl with the below patch, rebuilding and installing, the problem was fixed: shlomif[rpms]:$mageia/perl$ svn di Index: SPECS/perl.spec =================================================================== --- SPECS/perl.spec (revision 1134389) +++ SPECS/perl.spec (working copy) @@ -1,5 +1,5 @@ %define threading 1 -%define debugging 1 +%define debugging 0 %define _disable_ld_no_undefined 1 %bcond_with int64
(In reply to Shlomi Fish from comment #2) > After patching the mgarepo perl with the below patch, rebuilding and > installing, the problem was fixed: > > shlomif[rpms]:$mageia/perl$ svn di > Index: SPECS/perl.spec > =================================================================== > --- SPECS/perl.spec (revision 1134389) > +++ SPECS/perl.spec (working copy) > @@ -1,5 +1,5 @@ > %define threading 1 > -%define debugging 1 > +%define debugging 0 > %define _disable_ld_no_undefined 1 > %bcond_with int64 i should note that doing that broke all perl XS extensions (and urpmi) but improved the speed of the XML-LibXML's test suite.
Slowness confirmed. On Mageia 6, perl-5.22.3-3.mga6, real hw: 6.030s On Mageia 6, self-compiled perl 5.22.4, real hw: 5.609s On Mageia 6, self-compiled perl 5.26.0, real hw: 3.717s On Cauldron, perl-5.26.0-2.mga7, VBox: 14.260s On Cauldron, self-compiled perl 5.26.0, VBox: 3.895s (the perf boost between 5.22 and 5.26 is pretty impressive!)
CC: (none) => LpSolit
Thanks for working on it, Shlomi :-)
Assignee: bugsquad => shlomifCC: (none) => marja11
Thierry any idea about this ?
CC: (none) => mageia, thierry.vignaud
i think we can disable debuging but i would like to have your approval first.
Yeah it has been enabled by error
Done in SVN. I fear this might need a boostrap build though (to be confirmed) I that's the case, I would suggest we investigate the use of int64 by default on 32bit like FC does (I've added support but disabled by default through %bcond)
just pushed on the BS ( to see if this break the BS or not ). i don't know all this enough to work on the use of int64. Shlomi Fish can you help thierry on this ?
I: [iurt] [iurt] --------------- Command failed, full output follows --------------- I: [iurt] [iurt] D: [iurt_root_command] chroot /usr/bin/perl: symbol lookup error: /usr/lib/perl5/vendor_perl/5.26.0/x86_64-linux-thread-multi/auto/Math/Int64/Int64.so: undefined symbol: Perl_pad_sv I: [iurt_root_command] ERROR: chroot D: [iurt_root_command] chroot /usr/bin/perl: symbol lookup error: /usr/lib/perl5/vendor_perl/5.26.0/x86_64-linux-thread-multi/auto/Math/Int64/Int64.so: undefined symbol: Perl_pad_sv I: [iurt_root_command] ERROR: chroot how to fix ? by rebuilding it on a clean chroot like first bootstraping ?
perl breakage reverted, sorry. "I that's the case, I would suggest we investigate the use of int64 by default on 32bit like FC does (I've added support but disabled by default through %bcond)" How to work on this ?
64bit build is OK but on 32bit, we need to find out the right missing -D option used by FC in order to get rid of -int64 (else file lists differs between 64 & 32bit arches). Though FC has also moved !binary modules to /usr/share
(In reply to Thierry Vignaud from comment #13) > 64bit build is OK but on 32bit, we need to find out the right missing -D > option used by FC in order to get rid of -int64 (else file lists differs > between 64 & 32bit arches). For now, could we revert this change? Performance matters more than supporting 64bit integers on 32 bit machines. If the want 64bit support, then they should use a 64bit machine.
That means 2 painful bootstrap instead of only one. Actually it looks I already did all the work from a quick chroot test. So here it comes: http://svnweb.mageia.org/packages?view=revision&revision=1147909 Then Nicolas or another sysadmin will have to use iurt/rebuild_perl_iurt
ok i will do this, this week end. you have increased the release of the rpm builded with rebuild_perl_iurt ?
build pb: URPM.c: In function 'XS_URPM__Transaction_check': URPM.xs:2603:7: warning: variable 'translate_message' set but not used [-Wunused-but-set-variable] int translate_message = 0; ^ URPM.xs: In function 'XS_URPM_parse_rpm': URPM.xs:3033:31: error: 'RPMVSF_NOPAYLOAD' undeclared (first use in this function) vsflags |= (RPMVSF_NOPAYLOAD | RPMVSF_NOSHA1HEADER); ^ URPM.xs:3033:31: note: each undeclared identifier is reported only once for each function it appears in URPM.xs:3037:46: error: 'RPMVSF_NOSHA256HEADER' undeclared (first use in this function) vsflags |= (RPMVSF_NOMD5 | RPMVSF_NOSHA256HEADER); ^ URPM.xs: In function 'XS_URPM_get_gpg_fingerprint': URPM.xs:3125:9: warning: implicit declaration of function 'pgpPubkeyKeyID' [-Wimplicit-function-declaration] pgpPubkeyKeyID (pkt, pktlen, fingerprint); ^ URPM.c: In function 'XS_URPM__Package_EVR': URPM.xs:1508:10: warning: ignoring return value of 'asprintf', declared with attribute warn_unused_result [-Wunused-result] asprintf(&res, "%d:%s", epoch, version); ^ Makefile:343: recipe for target 'URPM.o' failed make: *** [URPM.o] Error 1 error: Bad exit status from /home/iurt/rpmbuild/tmp/rpm-tmp.MTUi63 (%build)
That's b/c URPM is now targeting rpm-4.14. I can workaround a compat patch
can you just modify the rebuild script for updates_testing to be enabled ?
i just commited for this ( i forgot to add the bug reference btw ). Rebuild in progress
I've restored URPM' support for rpm-4.13.x in svn
(In reply to Nicolas Lécureuil from comment #20) > i just commited for this ( i forgot to add the bug reference btw ). "svn propedit svn:log --revprop -rXXX" is your friend :-) (already done)
(In reply to Nicolas Lécureuil from comment #20) > i just commited for this ( i forgot to add the bug reference btw ). > > Rebuild in progress What's the status, Nicolas?
in progress ( i will start arm in some minutes ). Do i upload first 64 and 32 bit and then arm when available or do i upload all at once ?
I guess all at once would be better (it would be bad to still have to doble bootstrap arm :-) )
So what's the status :-) ?
32 and 64bits and armv7 OK i am doing armv5 now
done. I am rebuilding the hdlist now.
The fixed Perl has been moved to core/release and a bunch of perl modules have already been rebuilt for it too (WIP). We did both disabling debuging & enabling 64bit integers on 32bit arches in order to prevent another later bootstrap for 32bit arches I've fixed the in main perl so that it's not installed in "*-64int". Though there are still references to "-64int" in rebuilt modules. eg: /usr/lib/perl5/vendor_perl/5.26.0/i386-linux-thread-multi-64int/URPM.pm I think this can be safely fixed later, w/o breaking anything, providing we temporary add the proper directories to @INC Ideally this should be saved before the big glibc-2.26/gcc-7 rebuild :-)
CC: (none) => jquelin, shlomifStatus: NEW => RESOLVEDResolution: (none) => FIXED
commit 4920fbf71ee20c8cfd44fa6a73c06f2159932cff Author: Thierry Vignaud <thierry.vignaud@...> Date: Thu Sep 7 20:24:35 2017 +0200 adapt to URPM-5.14 (using perl native ints) See mga#21441 --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=4920fbf71ee20c8cfd44fa6a73c06f2159932cff