develooper Front page | perl.perl5.porters | Postings from October 2000

Re: pp_add -> pp_i_add efficiency hack?

Thread Previous | Thread Next
Jarkko Hietaniemi
October 5, 2000 04:39
Re: pp_add -> pp_i_add efficiency hack?
Message ID:
> Argh. Hang on, I didn't do anything floating point. Why has it upgraded to

Because that's the way Perl does it.  I hate it too.

> We have two addition ops: one for integers, (pp_i_add) and one for 
> non-integers. (pp_add) If "use integer" is in force, Perl can change
> pp_add to pp_i_add at compile time, during the constant-folding stage.
> Otherwise, at runtime, you have to go through pp_add which pops NVs off
> the stack. This means that your SV gets upgraded to PVNV, possibly 
> needlessly.
> Would it be an efficiency hack to say the moral equivalent of
>     if(SvIOK(left) && SvIOK(right))
>         pp_i_add();
> and save the upgrade?

A buggy efficiency hack.  Consider integer overflows.  Consider
also IV+UV, UV+IV, UV+UV.  Consider also other basic arith ops
like - * / %.

I have been down this path many times and I think I once even hacked
pp_add and pp_substract to correctly detect overflow situations and
returns IVs/UVs when possible.  The problem is that this slowed down
Perl by about 10%.

You could think that doing first the op in NV and then in IV/UV, the
checking if the NV is within IV/UV limits, and if so, returning the
IV/UV result, would work.  Well, it won't.  You can't assume that an
IV/UV can be represented by an NV.  Also, this approach would
naturally be even slower because the op is effectively done twice.

> -- 
> "I will make no bargains with terrorist hardware."
> -- Peter da Silva

$jhi++; #
        # There is this special biologist word we use for 'stable'.
        # It is 'dead'. -- Jack Cohen

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About