Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Using 64 Bit Perl for Production Scripts.

by pmu (Beadle)
on Apr 18, 2014 at 12:31 UTC ( #1082751=perlquestion: print w/ replies, xml ) Need Help??
pmu has asked for the wisdom of the Perl Monks concerning the following question:

Respected Monks,

We're going get a new set of SAN Management Servers and I am planning to install Strawberry Perl Version 5.18.2.2 (64 Bit) on it. I googled about it and found that its often recommended to stick to 32 Bit Perl eventhough the OS is 64 Bit because 64 bit versions of some Perl Modules have issues. Is that still the case or can I go ahead using 64 Bit Perl?

Please let me know.

-------------------------------------------------------------- Perspectum cognitio aeterna --------------------------------------------------------------

Comment on Using 64 Bit Perl for Production Scripts.
Re: Using 64 Bit Perl for Production Scripts.
by choroba (Abbot) on Apr 18, 2014 at 12:52 UTC
    What modules do you use? We use 64bit Perl at work, I use it at home, used it at a previous work, but noticed no issues.
    لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
Re: Using 64 Bit Perl for Production Scripts.
by sundialsvc4 (Abbot) on Apr 18, 2014 at 12:53 UTC

    Quite obviously, you need to research this answer, for your environment and the particular packages that you. intend to use.   There’s simply no other way to find the reliable for-you answers that you need.

    Generally speaking, I would suggest that in a native 64-bit environment, native 64-bit software should be used whenever possible.   However, every scenario is at-least potentially different.   You should therefore identify and enumerate the software packages that you need for this box, and check documentation for each of these.   Every aspect of a production system must be verified in this manner.   I would presume that a 64-bit setup is most likely to be the appropriate one for all hardware of recent vintage.   However ... “Trust, but Verify.™”

      “Trust, but Verify.™”

      That's exactly why I distrust everything you say. Because every time I have verified anything you've said; it has not just been slightly wrong, but rather, substantially wrong.

      Very often so wrong that it seems more like deliberate, malicious misdirection than simple-minded error or dumb misunderstanding. Whatever combination of malignancies drives your continuing need to post always perpetually pointless, usually useless, habitually harmful, and sometimes serious malevolent advice; it does this place harm.

      It seems that most regulars here have seen you for the ignoble, thick-skinned, self-deluding conman that you are; but I wish more of them would challenge you more often; so that the less regular, and new members are less likely to be taken in by the particular brand of meaningless, techno-babble flimflam that is the hallmark of your long con.

      You recently, unjustifiably, told another forum member to "Go away"; I now, with long and strong justification, invite you to do exactly that:

      Go away and do not come back!


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

        In a word: shut up.

Re: Using 64 Bit Perl for Production Scripts.
by moritz (Cardinal) on Apr 18, 2014 at 13:10 UTC

    I've been using 64 bit perls under Linux for several years, and can't remember having any architecture-related module problems.

    So I don't think there are many 64 bit problems out there, at most 64 bit + Windows problems.

Re: Using 64 Bit Perl for Production Scripts.
by pmu (Beadle) on Apr 18, 2014 at 13:36 UTC

    Respected Monks,

    Thank you for your replies.

    Yes, I will be installing it on Windows 2003/2008 Server (64 Bit).

    -------------------------------------------------------------- Perspectum cognitio aeterna --------------------------------------------------------------
Re: Using 64 Bit Perl for Production Scripts.
by kschwab (Priest) on Apr 18, 2014 at 14:39 UTC

    I think the perception that 64 bit Perl has issues is more about specific modules than it is about Perl.

    For example, Win32::SerialPort has been borked on 64 bit distributions of ActiveState for quite a while now: Win32::SerialPort Test Status

    (though you can build it manually, and it works fine)
Re: Using 64 Bit Perl for Production Scripts.
by sundialsvc4 (Abbot) on Apr 18, 2014 at 14:43 UTC

    If you are installing on a 64-bit Windows system, then I would not expect you to find any issues that would oblige you to run a 32-bit Perl.   Since this is a production setting, you should be thorough in verifying that there are no 32/64-bit issues in the specific modules that you intend to run.   Naturally, on a 64-bit system you very much want to use 64-bit software, not 32-bit, for a variety of good reasons.   I would be surprised to learn of any show-stoppers.   Of course, if you do find any, please immediately update this thread with full details.

Re: Using 64 Bit Perl for Production Scripts.
by wanna_code_perl (Pilgrim) on Apr 18, 2014 at 17:01 UTC

    Firstly, I have been using 64-bit Perl more or less exclusively for the past few years on a variety of Linux, Windows, and Mac systems, with 50+ modules (many of them XS, don't have an exact count on that, though), and have had zero issues that would have been avoided with a 32-bit Perl.

    Secondly, my own anecdotal experience shouldn't mean squat to you. :-) Fortunately, the Perl module ecosystem (and Perl itself) are blessed with some of the best unit tests in the industry (see Test::More for a start). As long as your own software also has good unit tests, you are already a long way to verifying your installation.

    Thirdly, if you still have any doubt, it's worth questioning whether 64-bit Perl would actually make any substantial difference in your installation. By themselves, 64-bit programs do not inherently outperform their 32-bit counterparts. There are a couple of cases where they do:

    • (The big one): Your program needs to access more than ~3GiB of RAM, go with 64-bit
    • 64-bit architectures have additional registers that can (at the C compiler level) be used to optimize some compute-intensive routines. Benchmarking is the only sane way to tell whether this will be worthwhile.

    However, there's a downside: 64-bit programs are larger (again, depends, but I've seen 10-30%), and consequently use more RAM, which can increase memory traffic, which can actually degrade performance a little. Probably not terribly significant, but again, benchmark.

    For "SAN Management Servers", you are probably not using significant RAM or doing anything computationally expensive (think: decoding human genome, solving chess, etc.), so to be honest, it's probably not going to make a huge difference. So, as above, unit tests (and your own functional and integration testing) will guide you.

Re: Using 64 Bit Perl for Production Scripts.
by pmu (Beadle) on Apr 18, 2014 at 19:00 UTC

    Revered Monks,

    I simply have no words to thank you all for your eagerness to help and provide so much useful information.

    The modules I will mostly end up using are:

    Net::SSH2 Excel::Writer::XLSX Config::Tiny MIME::Lite List::MoreUtils

    kschwab, yes you are right. Win32::SerialPort does indeed fail. On both 32 and 64 bit versions of Perl 5.18. Output given below is for 64 bit, but it's the same for 32 bit. I don't need that module (atleast as of now), but just wanted to see what I get when I try to install it. I have downloaded Strawberry Perl Version 5.18.2.2 (Portable Version) which was released just a few days ago and was eager to try it out. May be, the module expects something to be connected to the serial port, or may be, the module is not able to see a serial port and hence it fails.
    C:\perl64_51822>cpanm Win32::SerialPort --> Working on Win32::SerialPort Fetching http://www.cpan.org/authors/id/B/BB/BBIRTH/Win32-SerialPort-0 +.22.tar.gz ... OK Configuring Win32-SerialPort-0.22 ... N/A ! Configure failed for Win32-SerialPort-0.22. See C:\PERL64~1\data\.cp +anm\work\1397846877.6344\build.log for details.

    And this is what the log file says

    -------------------------------------------------------------- Perspectum cognitio aeterna --------------------------------------------------------------
      Device COM1 does not appear to exist

      What output do you get if you type this command into a cmd window?: mode com1


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

        Hi,

        I get the following:

        C:\Users\pmu>mode com1 Illegal device name - COM1 C:\Users\pmu>
        -------------------------------------------------------------- Perspectum cognitio aeterna --------------------------------------------------------------
Re: Using 64 Bit Perl for Production Scripts.
by mhearse (Hermit) on Apr 19, 2014 at 00:04 UTC
    I am interested in this post. After all, what is the benefit of using 64 bit Perl vs 32 bit Perl? Obviously it should be able to address a larger amount of memory. But when is that useful? For me... probably never. But since you're doing SAN management, maybe you can break the 4GB boundary. If it is a matter of stability... I understand.

      Generally and generically speaking, I would recommend that “you should use the interpreter that is most-native to your particular operating system, which should be the one that is most-native to your hardware.”   If you are running a modern-day 64-bit microprocessor, you (so to speak ...) “owe it to that microprocessor” to be running an OS that expects what it can give.   And, in such an environment, you should run an application that is truly designed for it.

      “Naturally, there are exceptions,” and an entirely-justifiable example of such an exception would be a legacy library that is mission-critical but that has not yet caught up with the 21st Century.   You would perhaps consent to run a 32-bit interpreter for this compelling reason alone.   But you would be anxious for the inevitable future, panting for the day when it finally arrives.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1082751]
Approved by karlgoethebier
Front-paged by mtmcc
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (4)
As of 2014-12-23 01:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (133 votes), past polls