1

For several scripting tasks, our team currently uses Strawberry Perl 5.14 / 32bit and I'm looking into upgrading to the latest 5.24(+) version.

I have always used the 32-bit version on Windows, and I found some references that the 32-bit version may be a little bit less troublesome in general, but how true that is today, I have no clue.

In general, today on my Win7-Win10 installations, I try to install the 64bit version of a tool if there is one available, but since perl is not a tool but a toolbox, the choice seems a bit more complicated.

Of course, it's no problem at all having two Strawberry Portable/ZIP Versions in parallel on the same box, but obviously we as a team want to minimize version variations as much as possible, so I guess the question could be summed up as a

TL;DR: Default to 32-bit Strawberry Perl and use the 64-bit one when needed, or default to 64-bit Strawberry Perl and use the 32-bit one when a package only has a 32-bit version?

I checked, and if it's relevant, the only packages we currently have in addition to the Strawberry 5.14 defaults are DBD::Oracle, HTML::Formatter, XML::LibXML and XML::LibXSLT

Oh, and of course, "it doesn't matter, because there are only some obscure modules, or you'll know exactly when it matters (e.g. 32bit vs 64-bit MS Office)" is indeed a valid answer, which doesn't make the question per se opinion based IMHO.

I'll note that the Strawberry homepage lists both the 64-bit as well as the 32-bit version as recommended, but lists the 64-bit version first.

Community
  • 1
  • 1
Martin Ba
  • 37,187
  • 33
  • 183
  • 337
  • Well, it's an opinion, but mine is - there's no problem running 64bit. – Sobrique Nov 17 '16 at 11:07
  • @Sobrique - which cpan modules do you use with which SB Perl 64bit version? That might make some good info to showcase that 64bit is in fact no problem? – Martin Ba Nov 17 '16 at 11:12
  • A vast medly, because I end up downloading almost anything someone mentions on Stack Overflow. (In Strawberry perl). – Sobrique Nov 17 '16 at 12:45
  • If you know which modules you're using on the old perl, why not just start there? Just install a new instance of the 64-bit, install the modules, and test out your scripts. I've never had any issues after switching to 64-bit a long time ago, and in my development, perform auto-testing of my distributions across both 32 and 64 bit perls. My automation distributions takes care of installing all dependency modules automatically. Never had an issue with a clash – stevieb Nov 17 '16 at 13:25
  • 1
    another option, is use 'autobundle'. Here's a [post](http://stackoverflow.com/questions/40057829/openssl-upgrade-in-strawberry-perl/40059315#40059315) I show how to do this. You can ignore the berrybrew parts (that's not the focus of this comment). autobundle allows you to make a list of all currently installed modules in one perl, and easily re-install them all in another – stevieb Nov 17 '16 at 13:42
  • @nwellnhof - Nick, "picking" on you as the first closer: I wonder whether you think that the 32bit and 64bit versions are technically equivalent, and therefore you think it is a purely opinion based question, or whether you close-voted because you think that the question as-asked is potentially opinon-based, regardless of any Perl technicalities? – Martin Ba Nov 17 '16 at 16:32
  • @ChankeyPath - because, you know, stating that there are very little / or only obscure modules that only work e.g. on 32-bit and therefore *it doesn't matter* would be a far more useful comment/answer that close-voting. Just sayin'. Cheers. – Martin Ba Nov 17 '16 at 16:33
  • 1
    It's simply impossible to give a definite answer to the question. Whether one prefers 32- or 64-bit Strawberry Perl depends on too many factors. Maybe I should have chosen "too broad" as reason to close. – nwellnhof Nov 17 '16 at 19:18

1 Answers1

1

The rule of thumb I've always used during architecture changes is to examine your tool-chain. If nothing is holding you back, move to the newer architecture. If some part of your tool chain is 32-bit only, then deal with 32-bit for a little longer.

For example, I have a customer who requires NotesSQL, and for some time they only provided a 32-bit version of their library. This meant sticking with a 32-bit ODBC connection and a 32-bit perl. Now all the tools I depend on are available in 64-bit. Odds are, at this late date, that the same is true for you.

tjd
  • 4,064
  • 1
  • 24
  • 34