Front page | perl.perl5.porters |
Postings from December 2000
[PATCH] ++ 20% faster
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
December 4, 2000 04:17
Subject:
[PATCH] ++ 20% faster
Message ID:
20001204121726.B52976@plum.flirble.org
On Sun, Dec 03, 2000 at 06:08:41PM -0600, Jarkko Hietaniemi wrote:
> On Sun, Dec 03, 2000 at 11:01:39PM +0000, Simon Cozens wrote:
> > On Sun, Dec 03, 2000 at 09:47:59PM +0000, Nicholas Clark wrote:
> > > Well, it would be if I sent it. I'm tired and making mistakes now.
> >
> > Without the patch:
> > u=2.31 s=0.38 cu=134.63 cs=11.73 scripts=261 tests=15242
> >
> > With the patch:
> > u=2.32 s=0.3 cu=135.14 cs=11.67 scripts=261 tests=15242
> >
> > Was it really worth it?
>
> IIRC the "efficiency" comes into play in one of Nicholas' platforms
> (ARM Linux?) where double math is really, *really*, slow, and staying
Well, ARM most things, as most ARM cores aren't in chips with floating
point. But most digital cell phones won't run perl, so it doesn't matter
there. [I'm told that 80% of digital cell phones in the last year have
have ARM CPU cores in them.]
> with integers if at all possible really pays off.
>
> There's also the 'correctness' aspect. If NVs smear your low order
> bits when you need need them you might get fussy about it.
It's not going to be correct until everything in the core that does
maths is vetted. And there should be scop for speed improvement. eg
currently:
./perl -Ilib -MDevel::Peek -e '$a = ""; $a++; Dump ($a)'
SV = PVNV(0x80f6140) at 0x80fc59c
REFCNT = 1
FLAGS = (NOK,pNOK)
IV = 0
NV = 1
PV = 0x80f91b8 ""\0
CUR = 0
LEN = 1
which seems somewhat loopy that it's not integer.
[Actually. it's really silly:
PP(pp_preinc)
{
djSP;
if (SvREADONLY(TOPs) || SvTYPE(TOPs) > SVt_PVLV)
DIE(aTHX_ PL_no_modify);
if (SvIOK_notUV(TOPs) && !SvNOK(TOPs) && !SvPOK(TOPs) &&
SvIVX(TOPs) != IV_MAX)
{
++SvIVX(TOPs);
SvFLAGS(TOPs) &= ~(SVp_NOK|SVp_POK);
}
else
sv_inc(TOPs);
SvSETMAGIC(TOPs);
return NORMAL;
}
optimised to add IVs. And so what's the default to upgrade from undef in
sv_inc?
if (!(flags & SVp_POK) || !*SvPVX(sv)) {
if ((flags & SVTYPEMASK) < SVt_PVNV)
sv_upgrade(sv, SVt_NV);
SvNVX(sv) = 1.0;
(void)SvNOK_only(sv);
return;
}
NV. :-(
--- sv.c.orig Sun Dec 3 20:01:20 2000
+++ sv.c Mon Dec 4 11:49:12 2000
@@ -4651,9 +4651,9 @@
}
if (!(flags & SVp_POK) || !*SvPVX(sv)) {
if ((flags & SVTYPEMASK) < SVt_PVNV)
- sv_upgrade(sv, SVt_NV);
- SvNVX(sv) = 1.0;
- (void)SvNOK_only(sv);
+ sv_upgrade(sv, SVt_IV);
+ (void)SvIOK_only(sv);
+ SvIVX(sv) = 1;
return;
}
d = SvPVX(sv);
Timings are for 500Mhz AMD K6:
Regression tests followed by 1 line of:
./perl -Ilib -MBenchmark -lwe 'use vars q($a); print timestr timeit(1000000, sub {$a++})'
unpatched bleadperl
All tests successful.
u=1.36 s=0.39 cu=62.18 cs=10.02 scripts=264 tests=15632
1 wallclock secs ( 1.88 usr + -0.01 sys = 1.87 CPU) @ 534759.36/s (n=1000000)
patched bleadperl
All tests successful.
u=1.49 s=0.56 cu=61.77 cs=10.68 scripts=264 tests=15632
2 wallclock secs ( 1.40 usr + 0.00 sys = 1.40 CPU) @ 714285.71/s (n=1000000)
unpatched 5.005_03
u=0.66 s=0.39 cu=24.82 cs=9.05 scripts=188 tests=6750
4 wallclock secs ( 2.82 usr + 0.03 sys = 2.85 CPU)
patched 5.005_03
u=0.66 s=0.36 cu=24.7 cs=9.43 scripts=188 tests=6750
2 wallclock secs ( 2.79 usr + 0.01 sys = 2.80 CPU)
so little change in 5.005_03 at all and 5.7 not much change overall
(within noise I think) but about 20% speed up on gratuitous ++;
Nicholas Clark
Thread Previous
|
Thread Next