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 06:26
Re: pp_add -> pp_i_add efficiency hack?
Message ID:
On Thu, Oct 05, 2000 at 02:19:40PM +0100, Nicholas Clark wrote:
> On Thu, Oct 05, 2000 at 06:38:59AM -0500, Jarkko Hietaniemi wrote:
> > 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%.
> even for a lazier test such as (for 32 bit ints) both bits 30 being clear
> for addition means that there can't be overflow?
> and both arguments < 2^16 for multiplication?

You can try be smarter but I think in any case you will end up with
a couple of tests before you do the actual op, so some speed hit is
inevitable.  And remember that 32 bit ints is awfully quaint :-) The
basic source suckage here is C: however nice portable assembler it is,
it's too high-level because you can't detect whether you just had an
integer overflow.

> Nicholas Clark 

$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