Front page | perl.perl5.porters |
Postings from October 2000
> Argh. Hang on, I didn't do anything floating point. Why has it upgraded to
> PVNV?
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++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Thread Previous
|
Thread Next