Large Windows network: One 32 bit perl or 32 and 64 bit perls?

[Boldra]

We're looking at modernising our standard perl install on 1000+ Windows machines of mixed versions (2000 through 2008, 32 and 64 bit, various hardware, including VM).

We are considering two options:

1. One 32-bit perl

We build a 32 bit perl and modules, place it on a filer (eg \\ourperl\bin\perl.exe), and always call that one perl for everything. When we need a new module, we test it on one 32 bit and one 64 bit machine locally and then update the master if the tests pass.

CON: Some modules running on 32-bit perl are buggy on a 64-bit os (eg Win32::TieRegistry and Win32::OLE)

2. 32 and 64 bit perls

We keep two perls up to date, eg \\ourperl\32bit\bin\perl.exe and \\ourperl\64bit\bin\perl.exe, each with it's own versions of any cpan modules we need. Updating modules works similar to 1, but we do the tests and rollouts seperately.

CON: Each machine needs to keep track of the location of perl.

Have I missed anything? Is there a significant performance difference with 64 bit? Is it worth the admin hassle of having all the perls locally installed? We are tending towards strawberry (because of better cpan support, and I'm fairly sure we can compile in INC to point to a network drive).

We also have to consider that on some of these machines other perl versions may be installed, so we have to be careful about changing anything in the global environment (that's what the IPCC said).

Our usage is quite varied, from gui apps called from network shares on user request, scripts started remotely via ssh, and locally started scheduled tasks.

[BrowserUk]

I'd set up a windows share for perl (say p:) on the clients and have it point to the server with the appropriate 32/64-bit build. You can do this via user group setting at the domain controller and you probably have the procedures already in place for doing so.

Also, any frequently loaded modules will get cached locally by the OS.

The main advantage of 64-bit is that it allows for access to (much) more than 2GB of ram (if you have the hardware). It also seems to run a little bit faster than 32-bit on 64-bit. 64-bit ints are nice also.

The biggest limitation is that there is no Win64::* yet.

[Corion]

Without having too much network and administration knowledge, note that having Perl installed locally has the added advantage of reducing the network traffic. Many Perl modules are relatively small files, so loading them adds some network latency if you load them from a remote location.

Of course, by carefully setting up PERL5LIB, you can make it so that each Perl tries the local directory first before falling back onto the network share, which would get you easier upgrading at the price of confusion when you install a newer version on the network and the older, local version is used instead.

[Boldra]

On some systems we have a problem where perl5lib is set to something utterly useless (an old oraperl dir), forcing us to re-set it before each call.

The network traffic issue may well be a point, but I'm optimistic the filers can handle it. In the worst case, we can load-balance the filers or switch to local installs. Local installs would just need some extra testing to make sure we have identical images on each server.

[JavaFan]

Is it worth the admin hassle of having all the perls locally installed?

That depends on how you've set up things. I'm sure Windows will have equivalents for tools like Puppet, Cfengine and other management software. Assuming you have a tool like that, installing things locally isn't much of a hassle.

Of course, you should be able to install both perl32 and perl64 on the central server, and make it that 32-bit machines see the 32-bit perl, and 64-bit machines see the 64-bit perl.

But I would assume that this issue has already been solved in your organization. Surely, perl isn't the first piece of software you encounter that exists in both 32-bit and 64-bit variants? What have you done for other such software?

[Boldra]

Hi JavaFan, thanks for your answer.

We do have deployment software, I just don't trust it much :) I don't know if there's a policy on 64 bit software, but the pattern tends to be, "if the 64 bit version offers important advantages, we install it, otherwise not". Eg databases or large application software is almost always matched to the hardware, but we also have a suite of about 50 32 bit command-line tools which are available and used on all machines.

So I guess you've helped me refine part of my question to: "are there important advantages in installing 64 bit perl on 64 bit windows?" I have not yet come across any.

[JavaFan]

I think you answered your own question: do you use perl for large applications, or just for command line tools?

Reasons to use 64 bits: larger memory use, linking 64-bit libraries, 64-bit integers (those can be mimiced on 32-bit perls as well), large file support (requires 64-bit integers), long doubles (perhaps).

Note that you may not be able to build a 32-bit perl on a 64-bit platform.

BTW, you did read the INSTALL file, didn't you?

[Anonymous Monk]

Are you sure you don't want to use local installs?

Since we moved to a MSI installer, Strawberry _should_ installer properly via Active Directory Group Policy and behave like any other regular installable package.

Of course, since you said you wanted to be able to install new CPAN modules in an ad-hoc fashion, that might not work quite so well...