develooper Front page | perl.perl5.porters | Postings from November 2014

Re: significant slowdown in float arithmetic

Thread Previous | Thread Next
From:
bulk88
Date:
November 17, 2014 07:06
Subject:
Re: significant slowdown in float arithmetic
Message ID:
BLU436-SMTP175FC8B7D79DA4F284E497EDF8B0@phx.gbl
bulk 88 wrote:
> 
> 
>  > Date: Sat, 25 Oct 2014 16:50:40 +0100
>  > From: davem@iabyn.com
>  > To: perl5-porters@perl.org
>  > CC: jhi@iki.fi
>  > Subject: significant slowdown in float arithmetic
>  >
>  > For example,
>  >
>  > my $n = 0.0;
>  > my $a = 0.1;
>  > $n += $a*$a + $a*$a + $a*$a for 0..10_000_000;
>  >
>  > These two miniperls are ones built non-threaded, -O2 just before and 
> after
>  > that commit:
> 
> Can you send/paste/attach the 2 miniperl binaries for me to look at (not 
> run)?

This reply is very very late. I had problems with my software for 
disassembling/analyzing 64 bit code+perl workshop.

I've attached a ignore whitespace diff of commit "Avoid mixing Inf/NaN 
with IV/UV." since the actual commit contains a ton of irrelavent 
whitespace changing which makes it difficult to understand.

I dont understand how that test code "$n += $a*$a + $a*$a + $a*$a" is 
calling Perl_isinfnan.  (haven't tried stepping it). In 
Perl_sv_2nv_flags, there wasn't a new call to Perl_isinfnan added but 
additional branches, but no func calls. Pics attached.

@@ -2652,6 +2635,13 @@ Perl_sv_2nv_flags(pTHX_ SV *const sv, const I32 
flags)
  	else
  	    SvNOKp_on(sv);
  #else
+        if ((numtype & IS_NUMBER_INFINITY)) {
+            SvNV_set(sv, (numtype & IS_NUMBER_NEG) ? -NV_INF : NV_INF);
+            SvNOK_on(sv);
+        } else if ((numtype & IS_NUMBER_NAN)) {
+            SvNV_set(sv, NV_NAN);
+            SvNOK_on(sv);
+        } else {
              SvNV_set(sv, Atof(SvPVX_const(sv)));
              /* Only set the public NV OK flag if this NV preserves the 
value in
                 the PV at least as well as an IV/UV would.

I included 3 pics from your miniperl binaries. Perl_isinfnan is very fat 
on your compilers, 2 libc calls, and the Perl C call itself.

Someone at Mozilla considered "breaking the rules" and skipping the 
portable compilers way of doing things 
https://bugzilla.mozilla.org/show_bug.cgi?id=416287

I will guess (I still need to try stepping that sample code) that the 
pp_* funcs are calling SvUV/SvIV on all NVs or something, all the time.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About