in reply to Windows precompiled binaries or DIY compile

From what I have heard, compiling Perl on Windows yourself is quite an undertaking. Update: But see also the reply by syphilis. Personally, I would still say the following at least as a starting point. /Update So I would say: just use Strawberry Perl. It's also a major argument in terms of stability to just use the precompiled, tested binaries that everyone else is using.

As for speed, the usual applies: first, see if your code runs fast enough in the first place. If not, then first measure where the slowdown is, optimize the hotspots, and measure again to make sure your changes made an improvement. Keep doing that until either your code is now fast enough for your application, or until you can optimize your Perl code no more and you have determined that it is in fact the Perl interpreter that is slowing you down - and if that happens, then please do let us know.

  • Comment on Re: Windows precompiled binaries or DIY compile (updated)

Replies are listed 'Best First'.
Re^2: Windows precompiled binaries or DIY compile (updated)
by syphilis (Archbishop) on Sep 25, 2023 at 13:21 UTC
    It's also a major argument in terms of stability to just use the precompiled, tested binaries that everyone else is using.

    There's merit in that approach.
    Personally, I don't like that a 64-bit perl automatically "upgrades" integer values that exceed 64-bits by rounding them to a 53-bit precision NV (often with loss of information). If you have the option to instead use a perl that automatically upgrades integer values that exceed 64-bits by setting them to a 113-bit precision NV (and guaranteed no loss of information, unless they exceed 113 bits), then I think it makes good sense to avail yourself of that option.

    Effectively, with 113-bit NVs you've got 113-bit integer arithmetic so long as the operands and the result are in the (integer) range of -10384593717069655257060992658440191..10384593717069655257060992658440191, even on perls with 32-bit IVs..
    (Some caveats - with division you'd have to int() the result, and the left shift and right shift operators don't work as intended. But '+', '-', '*', and '%' work fine.)
    In any case, it's the fact that a quadmath perl's native arithmetic avoids that "loss of information" that appeals to me - rather than any extended integer arithmetic potential.

    I can envisage that many perl users don't care about that and would prefer the comfort of the 'double' NV, even though it's comparatively lame.
    And, of course, some systems are so lame as to not even provide the option of a 113-bit precision NV, anyway. (I guess that the 64-bit precision long double is then also an improvement, but not one that I would bother with unless the IV is 32-bit.)

    Cheers,
    Rob
[reply]
[d/l]

In Section Seekers of Perl Wisdom