Hi Scott,
Here's how I would try implementing it as one module instead of two.
I'm not sure if this is the best approach -- I'd be interested to
hear if other authors have done anything like this. Use
Module::Build, and have a block like:
recommends => { Inline::C => 0 },
Then in the module do this:
eval {
require Inline;
import Inline C => "DATA";
};
if ($@) {
*great_circle = sub { ... pure perl implementation ... };
} else {
*great_circle = sub { ... wrapper for C function ... };
}
__DATA___
... C implementation ...
That way, anyone who installs Inline::C either before or after
installing your module gets the speed boost. The biggest risk, as I
see it, is if the two implementations are not quite identical. But
some good regression tests could ameliorate that. To help with that,
there's a new CPAN module called Devel::Hide that can make your test
code think that Inline::C is not installed.
Chris
On Oct 16, 2005, at 12:30 AM, Scott W Gifford wrote:
Hello,
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
Math::GreatCircle::Fast.
Does anybody see any problems with, or have any objections to, this
approach?
Thanks for any thoughts,
---ScottG.
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
