Discussion:
Version 0.10 of Math::Prime::FastSieve
David Oswald
2012-05-25 08:10:01 UTC
Permalink
I've uploaded a new version of Math::Prime::FastSieve: v0.10.

This version is still based on Inline::CPP. At some future point I
may use InlineX::CPP2XS to remove the Inline::CPP dependency, but for
now I like it how it is.

Here are the most significant changes:

- Implemented an END{ Inline->init(); } block to prevent M54 warnings.
(Rob's suggestion).

- Increment inner 'j' loops at +=2 instead of just ++ ( 20-30% performance
improvement for primes(), and even better for the OO constructor.
(Dana's suggestion)

- EXPERIMENTAL support for long int data type. Perls built with long int
support are now able to go past the 2.14 billion limitation imposed by
standard ints. However, I haven't tested on a 32 bit Perl, so it may not
fare well in smoke testing. If the smoke tests start throwing up FAILs, I
will roll back the change, and possibly re-implement it behind
preprocessor guards. (Longs were another of Dana's suggestions).

- TO-DO: Dana also suggested trimming the sieve size in half by eliminating
evens from it. We're already NOT spending time iterating over evens, but
to keep the algorithm's math simple, a sieve of 1 .. 100000 has 100000 bits.
As Dana pointed out, it could contain just 50000 bits representing odd
integers, thereby saving some memory.

I may implement that later on, but
I think in the past I benchmarked it and found the math to be more
expensive. More work needs to be done there to work out the details of a
computationally cheap means of cutting the sieve's memory footprint
in half.


One other note: Perl SV's support an 'unsigned' data type, and my
functions mostly work with unsigned longs internally. They even
specify unsigned longs as return type in some cases. However,
whenever I try to specify unsigned long as a parameter type,
compilation fails. I think it may be an Inline::C or Inline::CPP
issue, either in the grammar parsing or in the typemaps.

Dave
--
David Oswald
daoswald-***@public.gmane.org
Sisyphus
2012-05-25 09:57:12 UTC
Permalink
----- Original Message -----
From: "David Oswald" <daoswald-***@public.gmane.org>
To: "Dana Jacobsen" <dana.jacobsen-***@public.gmane.org>; "Sisyphus"
<sisyphus1-sFbbPxZDHXw0n/***@public.gmane.org>; "inline" <inline-***@public.gmane.org>
Sent: Friday, May 25, 2012 6:10 PM
Subject: Version 0.10 of Math::Prime::FastSieve
Post by David Oswald
I've uploaded a new version of Math::Prime::FastSieve: v0.10.
This version is still based on Inline::CPP. At some future point I
may use InlineX::CPP2XS to remove the Inline::CPP dependency, but for
now I like it how it is.
It's a good demo of an Inline::CPP module as is - I wouldn't change that.
If you want to rebuild it as an InlineX::CPP2XS demo, maybe rename it
slightly - then we'll have *2* excellent demos :-)
Post by David Oswald
- Implemented an END{ Inline->init(); } block to prevent M54 warnings.
(Rob's suggestion).
Doing it in an END{} block probably doesn't achieve much.
It seems that the END{} block has to come after the 'use Inline ....'
anyway, so you might just as well code it at the end of the perl code and
not worry about enclosing it in an END{} block. (Putting it in an END{}
block shouldn't matter, however.)
Originally, I was thinking that if you put it in an END{} block then you
could put that END{} block anywhere in the code, as the location of the
END{} block wouldn't matter. But some later testing revealed that's not so.

See Inline-0.50_02 (which I released, but failed to announce, yesterday).
It also contains a Makefile.PL message for any pre-5.8.1 perls that don't
have Digest::MD5 installed.
Post by David Oswald
One other note: Perl SV's support an 'unsigned' data type, and my
functions mostly work with unsigned longs internally. They even
specify unsigned longs as return type in some cases. However,
whenever I try to specify unsigned long as a parameter type,
compilation fails. I think it may be an Inline::C or Inline::CPP
issue, either in the grammar parsing or in the typemaps.
The 'unsigned long' might pose a problem on 5.6 (I don't think it was in the
typemap ... not entirely sure), but shouldn't be a problem on later versions
of perl.

Cheers,
Rob

Loading...