Windows precompiled binaries or DIY compile

[ObiPanda]

Is it better to use a "packaged" easily installable version of Perl such as Strawberry on a Windows OS or to compile a version or there is no practical difference, etc...?

I primarily ask for two reasons: stability and speed. An underlying assumption to both reasons is that compiling code will always be faster, because it will compile based on specific chipsets and its respective native math libraries.

1. Stability. My systems run both AMD CPUs and GPUs. I have wondered if instability in GAMES are sometimes caused by various issues of the binaries being compiled for Intel CPUs and NVidia GPUs. By extension, is there an inherent stability benefit of compiling Perl on a Windows system?

2. Speed. This likely has no real practical value unless one is running a "large" server on Windows; but, I wanted to ask anyway. So, by a similar analogy to GAMES stability, since there is a real benefit to GAMES which have been optimized for either AMD or Intel/NVidia and sometimes specifically a chipset, is there a speed benefit to compiling Perl on Windows?

thanks

[syphilis]

Is it better to use a "packaged" easily installable version of Perl such as Strawberry on a Windows OS or to compile a version or there is no practical difference, etc...?

Perl 5.38.0 builds easily on Windows, and "straight out of the box" - using either Visual Studio 2022 or mingw-w64 ports of gcc-12 or gcc-13 (available from https://winlibs.com).
But I doubt that you'll get any advantage (in either speed or reliability) by using a perl that was built on your own machine.

The main thing you'll get by building perl yourself is the opportunity to have a perl that's configured the way you want.
For example, if you're not wanting to use either the fork() function or threads, you could build your own unthreaded perl - which, I believe, does provide a measurable improvement in speed.
For example, if (as I do) you want a perl that has an nvtype of __float128, then you'll have to build that perl yourself.

There are also considerations to be made in your choice of compiler.
For example, VS2022 builds of perl-5.38.0 support utf8 locales that StrawberryPerl doesn't.

The main advantage of Strawberry Perl is that it comes with a large range of additional modules, many of which rely on 3rd party libraries.
A perl that you build from source won't include those modules (which populate Strawberry's perl/vendor/lib directory).

The more people that build perl (including the monthly devel releases) on Windows, the better it is for perl.
One simple way is to start by editing the (self-documenting) perl-5.38.0/win32/GNUmakefile (or perl-5.38.0/win32 Makefile if building with MS Visual Studio).
All you really need do is:
1) Ensure that INST_DRV and INST_TOP specify the location in which you want perl to be installed;
2) For gcc builds, uncomment the line #CCTYPE        := GCC; for VS2022 builds, uncomment the line #CCTYPE        = MSVC143;
3) For gcc builds, uncomment the line #CCHOME        := C:\MinGW and edit it to specify the directory that contains gcc's bin directory.
That should build you a perl that is configured essentially the same as Strawberry Perl.

Then, cd to the perl-5.38.0/win32 folder and run:
1) gmake test (or nmake test for Visual Studio builds).
2) gmake install (or nmake install).

Following that, if you wish to re-use the same source to build a different configuration of perl, first run gmake distclean or nmake distclean.
Any problems, just ask.

Cheers,
Rob.

[eyepopslikeamosquito]

Thanks for that Rob! A really useful post that I will refer to often in the future.

As strongly cautioned by Fletch:

If you're doing anything serious with Perl you DO NOT want to use the OS' perl as that way lies much pain. Doing so couples you tightly to the OS' upgrade schedule for both the language and (if you're using its package manager for them) CPAN modules.

Having supported and maintained large customer systems for many years on many different Unix flavours, I strongly agree with this advice. The last thing you want is to be flooded with support calls when a "harmless" customer OS update breaks the Perl scripts/modules used by your product!

AFAIK, Windows does not have an "OS Perl" ... so perhaps Strawberry Perl is the nearest thing to that ... and similar dependency considerations apply ... that is, a customer upgrading to a later version of Strawberry Perl may break the Perl scripts in your product ... so building and shipping your own Perl on Windows just got a lot more attractive to me. :)

[NERDVANA]

The advice generally assumes that the OS package manager installed perl for lots of scripts and applications to share. That's a bad perl environment for a long-lived app that you want to keep running across OS upgrades.

Windows itself does not have any reliance on Perl, and a Windows Update will never install a new perl version on you. It's equally unlikely that a windows update would break library dependencies of XS perl modules. Unless you have a whole lot of unrelated software on the same host all using perl, Strawberry is probably functioning more like perlbrew than like Unix /usr/bin/perl.

That said, if you are "shipping" a perl application that you intend to be installed in its own Program Files path, then yes it should probably include its own perl interpreter compiled to use those paths and not interfere with anything else in the %PATH%

[NERDVANA]

Lots of good advice here in other comments, but I wanted to add some information directly about the question you asked.

(BTW, most of this is generic info that you should run your own experiments with, because I have never specifically tested this with perl)

Most code written in C is compiled using settings that make it reasonably fast, but compatible with the widest variety of hardware it might run on. The pre-compiled Strawberry perl you download probably is compiled to run on any x86-64 processor since the original release of the architecture 15-20 years ago. It may include special GCC detection of your hardware that enables faster versions of functions like memcpy using newer parallel vector instructions, but probably doesn't.

If you want the absolute fastest possible generated instructions for your processor, you need to tell gcc the flags "-march=native" and "-mtune=native" as it is compiling the code. These are probably not selectable options from any of the standard perl compilation scripts, but you can probably do something like make CFLAGS="-O2 -march=native -mtune=native" to make it happen. Check the full output of the compilation to see what actual gcc commands get run as a result. You might even try -O3 but given the crazy tricks that Perl source code plays, I expect that to just break things. But of course, you can just run the unit tests to find out if it broke.

Using -march=native means that the generated binary might only be able to run on your specific processor, so don't expect to be able to use it on any physical machine other than that one.

But also, I'd be really interested to see benchmark results if you do try this!

[eyepopslikeamosquito]

For completeness, there are also specialized domains, such as:

• GPGPU
• CUDA
• OpenCL
• OpenGL
• FPGA

Though I have zero experience with Perl in these domains, I remember these two nodes from 2021:

• Compile and possibly run cuda code on the GPU via Perl's Inline::C by bliako
• Perl GPGPU Modules by kcott

See also: BioPerl/PDL and Data Science References

[eyepopslikeamosquito]

It's hard to provide useful advice without more specific detail of your situation and what you're trying to achieve. Please tell us more about that.

Strawberry Perl is popular on Windows and I've used it happily in the past (I never attempt to build Perl from source on Windows because it's too much hassle for my tastes).

On Linux, I prefer to build Perl from source - see here for a detailed example of building the latest perl 5.38 securely from source.

Given Windows nowadays comes with a free Ubuntu VM, one possibility that might appeal to you is to build Perl from source on the Windows Ubuntu VM, as described here.

In case it's of use, my mandatory Building Perl References.

Updated: Minor changes to wording.

[haukex]

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.

[syphilis]

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

[Cow1337killr]

Despite the fact that www.strawberry.com can only provide version 5.32 of Perl (which is what I use on my Windows 10 operating system), it seems that one can go to https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/tag/SP_5380_5361 and have a choice of version 5.36 or 5.38. I have not tried it, because my computer is really slow and I usually use Google Colab, because it is faster and I can create Colaboratory notebooks (similar to Jupyter notebooks) that document what it is I was trying to do and easily pick up where I left off.

[stevieb]

5.36 and 5.38 both work flawlessly on Windows 10, I've tested them extensively after adding the ability for berrybrew to install and manage them for you :)

[Cow1337killr]

Thank you. berrybrew installed Perl version 5.38 on my Windows 10 operating system last night.

I installed the latest berrybrew from https://github.com/stevieb9/berrybrew by clicking on the hyperlink “Click here to download the installer” in bold letters.

I thought it was installing Perl version 5.8 as I watched the messages in the console window. I launched Command Prompt and typed berrybrew available and saw 5.38.0_64 installed and currently being used.

I double-checked it using perl -v.

I am impressed with what you have accomplished with berrybrew.

[Polyglot]

I have attempted to replicate my Linux-based Perl applications on a friend's Windows laptop on several occasions. In every case, I found it most difficult to achieve. The temptation was just to install an Ubuntu VM, and have the Perl apps run there (but this meant many GB of extra space on disk, plus more issues with copy/paste between Linux and Windows, etc.). I tried both ActiveState Perl and Strawberry Perl, neither of which ran properly at first blush. The Windows pathways were one issue, but a major part was that the "make" routines (make, dmake, cmake, etc.) for compiling various Perl packages all seemed to be broken...it was a major pain just getting the installation to work!

I finally figured out that XAMPP did most of what I needed if I manually installed Strawberry Perl to replace the Perl it came packaged with, and then redirected my Perl scripts to Strawberry. For me, Perl needed to run in CGI fashion, from Apache (or similar--but I tried in vain with Windows-native options...probably just too ignorant to get them to work). And I needed MySQL/MariaDB, again failing to understand how the MicroSoft options could replace this.

In my case, while speed is always nice, I was just happy to get the scripts to even run at all on Windows. Stability seemed fine whenever I was the one on the computer--my friend seemed to have some issues with getting XAMPP to load up consistently. It may be that he needed to manually start the various services in XAMPP when freshly booted, and being less tech-savvy, this was more challenging for him.

If speed is your thing, my educated guess would be that a Linux platform, even if that has to be a VM on a Windows machine, would be superior. I'd reckon the same would be true for stability with Perl. But owing to difficulties with packages on Windows, compiling from source, unless you are super-savvy with Windows' alternatives for building packages, will probably mean a considerable time investment and/or a hair-pulling experience. Best wishes!

[bliako]

Regarding the speed dimension, note that any XS module you install needs to be compiled with the same settings and flags your current Perl was built with. That's a rule for not compromising stability. I don't know how one installs XS modules in Windows with a pre-built Perl binary. From what I read here, Perl binary providers should also provide compiler and other tools necessary. In that case the advice of anonymonk is good. So, install something that gives you access to compiler tools and then fetch Perl from source and *try* to compile that with the tools you now have. Benchmarks should guide you.

But the best advice one can possibly give you is to run away from Windows and use a proper OS.

bw, bliako

[syphilis]

But the best advice one can possibly give you is to run away from Windows and use a proper OS.

Heh - don't let the truth get in the way of a piece of glib bullshit.
To the OP - I think bliako meant that's the best advice that he is capable of giving.

Cheers,
Rob

[bliako]

I appreciate that you have provided a very clear solution to this question: Re: Windows precompiled binaries or DIY compile

But just because perl devs have done good work it does not make Windows a workable platform. I think you are missing the forest for a plastic swiss-cheese tree with advertisement banners all over continuaslly feeding me CNN news. With all respect.

bw, bliako

[Polyglot]

But the best advice one can possibly give you is to run away from Windows and use a proper OS.

I'll second this. Good advice, indeed. Unfortunately, some are less inclined to give up their indulgences; and once in awhile it's necessary to go with the second-best solution, i.e. accommodate them as best as one can. It occurs to me that this is precisely what Strawberry Perl attempts to do.

[Anonymous Monk]

install strawberry, then compile your own

that's exactly how strawberry perl started, install msys2, compilers.... Build a perl

if you want the newest perl on windows the day its released, you'll have to compile yourself