Why is Perl usually installed without thread support?

Question

Perlbrew installs per default Perl without thread support. Is this just a legacy habit or could a Perl installation with thread support generate problems?

Oviduct

@mpapec I edited the question. Actually I had in mind some RH versions but I see that now is not the case anymore. Perlbrew per default does not enable it. – Oviduct

Answer 1

Compiling Perl with thread supports adds a lot of overhead due to all the locking, even if you don't use threads in your program. I measured about 15% overhead for a simple benchmark just by using Perl compiled with threads support.

Linnie

I'm not sure I understand this, or perhaps would be better to say I hope I am misunderstanding. Are you saying that if I run a perl module which does not utilize threads, I'll get different performance levels depending on rather the perl I run with was compiled with the -DuseThreads argument? I knew perl threads were...not the best threads out there, but I would never have expected the interpreter to take that kind of hit if a program never loaded threads. You would think they would toggle on or off the appropriate interpreter behavior so when threads isn't used the locking doesn't occur? – Linnlinnaeus

@dsollen: you understand it correctly. If Perl is compiled with support for threads it needs to make several internal structures safe against parallel use, i.e. locking etc. This means overhead. This is not specific to Perl, i.e. in earlier times where multi-core CPU were not used that much it was common to use a single-core kernel in various UNIX versions because the multi-core kernel just introduced more overhead and thus meant less performance. – Linnie

Oh I'm not surprised interpreting in a thread-safe manner takes longer. I was surprised they don't have a way to toggle between the thread safe and non-threadsafe modes so that if you don't have "use threads" somewhere in your code you run without thread safety. Looking back though, I realize in a fully interpreted language you can't figure out rather threads will be used prior to runtime to decide which interpreter to use; my compiled language bias is showing. Still, I would think at least perl compiled for threads would have a -no-thread cmd line argument to use faster interpreter – Linnlinnaeus

Answer 2

Because it isn't robust and performant enough to be the default.

Besides that, you have to consider CPAN. There are too many modules written in C without concern for threads.

I say this with all due love and respect as an ex-Perl6 / Parrot developer. Perl5 wasn't designed from the ground up with threading in mind (at least when I was involved in the community).

At this point, I don't think enough people care to change it. The future was going to be Perl6, and Parrot had threads very early. To destabilize Perl 5 at this point in its lifecycle is probably questionable.

It isn't like Perl is unique in this, Linux was the same way for a long time (as-in there was a big kernel lock that had to be dealt with). Most projects start like that, but some take it further than others before addressing it.

Webber

Answer 3

As @steffen-ultisch said, it is a performance issue.

But, if one so wish, it is possible to easily install Perl both with and without threads, so you can use the version more proper to a given script.

The perlbrew installation, say for Perl 5.22.1, is:

perlbrew install-multiple 5.22.1 --both=thread

Crossroads

But how to choose one or another perl? – Grown

If one needs threads obviously has no choice. Or, one can still install threads, knowing he will have to suffer a performance penalty (as Steffen Ullrich said). If you do not need threads, it is better to leave them out. – Crossroads

Answer 4

From perl threads tutorial:

Basic Thread Support

Thread support is a Perl compile-time option. It's something that's turned on or off when Perl is built at your site, rather than when your programs are compiled. If your Perl wasn't compiled with thread support enabled, then any attempt to use threads will fail.

Your programs can use the Config module to check whether threads are enabled.

Anson

Answer 5

Perl threading is not threading in the usual sense - it actually runs a separate interpreter for each thread, so there is no shared state. A shared memory model is the main reason to use threads vs. forking processes, so Perl threads are rarely used.

Further, it is easy to end up with crashes or other unexpected behavior if you use modules that aren't thread-safe from multiple threads concurrently.

See http://perldoc.perl.org/threads.html for more.

Panic

Yes but having a Perl version that supports threads does not force you to use it. Having such a version and using it with scripts that do not use threads should be no problem. Or ist it disabled to force users to think before using threads (something like: you want to use threads, bad idea, think and re-install perl?) – Oviduct

It isn't about forcing you to use it or not, it is about internal differences that affect robustness and performance, specifically when you aren't using it. – Webber