My Two Perls

Perl's greatest blessing and greatest curse, in my opinion, is CPAN. CPAN is an unbelievably rich repository of modules that do everything imaginable. I can't think of another language that has a resource like it. But using CPAN on the most widely used desktop platform available, Windows, presents some problems. Here is one developer's Perl on Windows saga.

Historically, I've always run ActiveState Perl. It's a great Windows distribution, and ActiveState has done a lot of work to make it very user friendly, especially by creating PPM, the Perl Package Manager. As opposed to the standard CPAN installation mechanism, which generally expects you to "make" your modules, sometimes compiling sources, PPM provides pre-compiled packages, so it's no hassle at all to install them. It's just a download/copy operation, really. The problem here is that if ActiveState's PPM repository doesn't have the module you want, you're back to compiling from source.

At some point (as I became nerdier, I guess), I decided to play around with compiling my own version of Perl and bundling it with a few important web modules from CPAN (i.e. CGI, CGI::Ajax, DBI, SOAP::Lite, Template Toolkit, etc), along with Apache/mod_perl, and MySQL. I decided to make this a distribution, and named it zangweb. It was intended to give a Windows developer everything he needs to start programming in Perl/Apache/MySQL with as little effort possible.

zangweb Perl replaced ActiveState on my machine for some time. I no longer had the convenience of PPM, so I just went ahead with the standard CPAN way of installing modules. For most modules, this wasn't too big of a headache. You just need to be sure to have a working development environment, one with nmake.exe available, and most modules installed without difficulty. Generally, I did something like

c:\>vcvars32
c:\>perl -MCPAN -e shell

and installed from the CPAN prompt.

However, modules like PerlMagick, or any others that had complex C/C++ builds and originally been developed for *nix, did not build easily. They took a lot of work, and while I thought it was kind of fun, from a hobbyist standpoint, I don't know if under other circumstances I would have wanted to go through all that trouble.

Nonetheless, zangweb worked well, and I was pretty content. Then Perl 5.10 was released, and it was available from ActiveState in short time. I wanted to try 5.10, naturally, and as usual, the path of least resistance was ActiveState. I downloaded it and ran it alongside zangweb Perl at work. On my own laptop, I decided I would try a different configuration: ActiveState Perl 5.10, and standard Apache and MySQL installations. Kind of as a comparison to see how valuable zangweb really was.

I realized the only thing that made zangweb more valuable was all the work I had done to get those web CPAN modules compiled and installed. Yet again, it boiled down to the modules, and the difficulty that came with installing them on Windows. For instance I want to have PerlMagick. I have it for zangweb. So far, ActiveState doesn't for v5.10:

http://ppm.activestate.com/BuildStatus/5.10-P.html

But you might get lucky, and find some kind soul who has created and bundled it in a PPM friendly package:

http://www.google.com/search?hl=en&q=filetype%3Appd ...

But I don't want to have to rely on the kindness of strangers to get my "must have" modules.

Recently, I wanted to do some charting in Perl. After looking around at the modules, I decided I wanted to use GD::Graph. This relies on libgd. At the time of this writing, they don't have a compiled binary for Windows for the latest revision. So now I've got compiling ahead of me once again.

After trying unsuccessfully to get it to compile natively on Windows, it dawned on me: Since CPAN is designed so much in the *nix way of doing things, why not make my second, "alternate Perl" run under an emulation of the Linux system? All the tools that are usually expected by these kinds of libraries, bash, configure, make, etc., are there, so surely I'd have a much easier time getting these modules on my machine this way.

No way to know until you try. I installed Cygwin, which came with Perl 5.8 already bundled. GD::Graph expects you to have libgd already compiled, so I went through the steps to do this, using my freshly installed Cygwin bash shell.

This is where the story gets remarkably pleasant.

I downloaded the libgd source, and after reading the README, downloaded the libraries it required, i.e. libpng, and freetype. These two compiled no problem. I jumped back over to the libgd source folder, did its configure and make steps, and after waiting a while for things to compile (something I'm not real fond of, I must admit), had a working version of libgd. The CPAN install of GD::Graph was a breeze after this, and soon I was charting in Perl, happy as could be.

Soon enough, I began to wonder why I wasn't just using Cygwin Perl as my main, and perhaps only, Perl distribution. I tried to think of anything I was doing with Perl that was only available to a Win32 distribution. (Yes, I know, that is kind of funny in retrospect.) Nothing came up.

The only thing I wondered about now was whether running Perl under emulation would be significantly slower than a natively compiled version. I know it should be slower. The more important question was would it be slow enough to matter?

The quickest, most basic way that I could think to check was to make Perl count. So I ran the following with each of my Perls:

ActiveState:

perl -e"$a=time; for($i=0;$i<=100000000;$i++){} print time-$a"  21 

Cygwin:

perl -e'$a=time; for($i=0;$i<=100000000;$i++){} print time-$a'  19

Cygwin was faster by about 2 seconds. This satisfied me, initially. At least I knew that there wasn't an embarassing difference in performance. Curious, now, however, I found some good benchmark tests on the web, primarily for comparing the performance of different languages, but definitely useful for what I was trying to do. I downloaded the nsieve Perl code. This performs the Sieve of Eratosthenes, and is a way of finding primes.

Here are the results:

ActiveState:

perl C:\cygwin\home\nsieve.pl 7
Primes up to  1280000    98610
Primes up to   640000    52074
Primes up to   320000    27608

11

Cygwin:

perl nsieve.pl 7
Primes up to  1280000    98610
Primes up to   640000    52074
Primes up to   320000    27608

11

They both ran in 11 seconds. I'm reasonably satisfied that Cygwin, for most of my development purposes, will be fast enough.

So that leaves me with a nagging question. Why am I running two Perls? Unless there was a specific case where I need ActiveState -- performance or compatibility with some poorly designed app -- why not just run the Perl that works with CPAN?

Then My Two Perls can become My One CPAN-Compatible Perl. I like the sound of that, as a matter of fact. Because really, that's what it's been about all along.