develooper Front page | perl.module-authors | Postings from October 2005

Releasing slower pure-perl module and faster Inline::C version

Thread Next
Scott W Gifford
October 15, 2005 22:30
Releasing slower pure-perl module and faster Inline::C version
Message ID:

Some quick background: I've got some code I use that does a lot of
distance calculations.  I found that a limiting factor for me was the
time it took to do a "great circle" calculation, a trigonometric
calculation of the distance along the surface of a sphere (see
Math::Trig::great_circle_distance).  I rewrote that function in C
using Inline::C, and achieved a substantial speedup (a 300% speedup
for the great circle calculation, resulting in about 30% overall
speedup).  So I actually do have an application that cares about the
speed of this function, and I have benchmarked and the Inline::C
version is substantially faster.

I'm interested in releasing the Inline::C version of this code.
Because it's often called from within modules, I'd like to make it
easy for module authors to use the accelerated version if it's
available, but without limiting their support to platforms that have a
compiler and Inline::C.

I think the easiest way to do this would be to release the Inline::C
version as Math::GreatCircle::Fast and a pure-perl version as
Math::GreatCircle.  Math::GreatCircle would check for an installation
of Math::GreatCircle::Fast, and if it found it would override all of
its own functions with the C equivalents from the accelerated module.
That would allow module authors to simply say "use Math::GreatCircle"
in their module and "PREREQ_PM => {Math::GreatCircle=>0}" in their
Makefile.PL, and they'd get the fast version if it was available,
without having any dependencies on Inline::C or a compiler.  If a user
needed the faster distance calculations, they could install
Math::GreatCircle::Fast; otherwise things would still work OK, but a
little slower.

The functionality of Math::GreatCircle would be pretty much the same
as Math::Trig's great circle functions; primarily it's a wrapper for

Does anybody see any problems with, or have any objections to, this

Thanks for any thoughts,


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