Tuesday, November 29, 2005


ActiveState on ActivePerl Windows x64 follow-up

You may remember an earlier post regarding an ActivePerl Windows x86_64 version. It turns out that many of my readers are also interested in the availability of ActivePerl for x64. With that in mind, I contacted ActiveState product manager Matt Herdon to ask about an x64 port of ActivePerl.

Let me start by saying that it's pretty great when a product manager is as accessible as Matt (but please don't start emailing him a bunch of crap). Being a product manager is like trying to herd cats, except developers are more stubborn and you have the sales department chained to your ankles. And you're blindfolded. You should see the product lifecycle management systems used in big time development. Look at a company like Microsoft and I am sure you could find a few cases of the code to implement a feature being smaller than the design documentation supporting it. Anyway...

The bad news:
"The bottom line is that there are no immediate plans to do an x64 port of ActivePerl.

"[...]For our other languages, Python and Tcl, it has been relatively easy to do, since both seem to have few issues related to 64-bit. Not so with Perl.

"The usefulness of Perl lies on the use of modules (CPAN etc.), a huge number of which won't work in 64-bit mode. Therefore there's lots of work to do -- both for us and the Perl community -- to get 64-bit firing on all cylinders.

"We have limited resources, so unless a large customer (or Microsoft for that matter) wants to sponsor the port, it's going to be hard to get to unless the demand is large, which, currently, it's not."
My take on this is that ActiveState has at least partially compiled the base Perl interpreter in 64 bit. The problem was in building the modules and PPDs. As mentioned above, Perl without any modules is pretty much useless. You could do little things like read and write files, do some math, print some output, but anything more complex requires modules. In fact, unless you're doing some processor intensive computing with ActivePerl, most anything will require some modules to work.

Perl modules come in two big varieties. The first can be called a native Perl module. This sort is a module comprised of all Perl code. The other variety is XS or compiled. XS modules are usually written in C/C++ and must be compiled with a C/C++ compiler. There is a speed benefit with compiled modules but more importantly they allow access to system calls. For instance, to reboot a Windows machine you might use Win32::InitiateSystemShutdown. The Perl code in the Win32 module ties this function call to the compiled code in the Win32 module. The compiled code is what is actually tied in to the Microsoft Win32 API.

The compiled code is exactly the sort that might break in a 64 bit port. Data types in C get broken because the size of core variables changes in a bit-width change like 32 to 64 bits. This would affect tons of code in the Win32 modules alone, but extend this to all of CPAN and you see the problem ActiveState has.

One thing I have mentioned before is that ActiveState automatically tries to build packages for all CPAN modules. This is one of the reasons their Win32 Perl port is the best. PPM is the easiest way to install Perl modules on a Windows machine, which almost certainly won't have all the compilers and tools needed to install a traditional CPAN module. In other words, if a platform is added to ActivePerl and it lacks a majority of modules, the quality of ActivePerl suffers a great deal. It's not an option.

On the upside, if you believe as I do that x64 is an inevitable conclusion in the data center (and beyond...), ActiveState most certainly will release an x64 version of ActivePerl. It will only take demand from the majority of the market, or more likely demand from the right customer. The other positive note is that the majority of ActivePerl is functional on x86. The few bits that don't work well are accessing system files, spawning 64 bit processes, and accessing the registry. I wonder if there isn't a solution to these problems that doesn't require a full blown port to x64?

It is worth noting that x86 based ActivePerl does work successfully on Windows' x64 platforms in the WOW layer. This essentially means that you can go ahead and use Perl on x64 all you want--it will simply be in a 32bit process.
The only real problem with this is if you expect to use Perl with IIS or some other native 64 bit process. The reason for this is that Windows x64 does not allow you to mix 32bit and 64bit libraries in a single process space. So don't expected 64 bit applications to embedd 32 bit perl.

That said the biggest real world issue you'll run into is if you want to run IIS in 64 bit mode and run PerlScript. You will need to configure IIS to run as 32bit (yes, there is a vbscript available on MSDN that will enable this). I don't know if there are any limitations to running a 32 bit CGI process from 64bit IIS (maybe not since CGI is spawned as a seperate process).

Good luck!
Well, I'm trying to port a module to Windows x64 and I can't without an x64 Perl.
Post a Comment

Links to this post:

Create a Link

<< Home

This page is powered by Blogger. Isn't yours?