Beefy Boxes and Bandwidth Generously Provided by pair Networks RobOMonk
Perl: the Markov chain saw
 
PerlMonks  

How much slower is perl (the binary) with threads than without?

by Anonymous Monk
on May 10, 2012 at 19:37 UTC ( #969855=perlquestion: print w/ replies, xml ) Need Help??
Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Gracious monks

I remember reading that having Perl compiled with threading support enabled, code execution will slow down whether it actually uses threads or not. However, I cannot find a reference for that anywhere, and would be glad if someone could supply more information on that.

How much of a slow-down am I to expect with a threaded Perl binary? Which situations does it manifest in? Was it just a problem of an older Perl version?

I'm also interested in whether there are any Linux distributions who might ship a threadless Perl binary. I do know of Gentoo already. (I know -- I'm better off compiling my own binary than using the system Perl)

Comment on How much slower is perl (the binary) with threads than without?
Re: How much slower is perl (the binary) with threads than without?
by dave_the_m (Parson) on May 10, 2012 at 20:16 UTC
    It's generally regarded as being a "bit" slower, e.g. 10-20%. This is because each function takes an extra argument (the interpreter), data attached to ops has been moved into the pad (so is slightly slower to retrieve), and until recently, the malloc wrappers did a slow getting of the interpreter address on each call.

    Of course, the actual slowdown will depend on the particular code and modules. For example, individual XS modules may be considerably slower if they haven't been written to take advantage of workarounds for certain compatibility slowdowns (e.g. PERL_NO_GET_CONTEXT). Until recently, DBI with DBD::mysql was 3 times slower under a threaded perl for a simple fetch() loop. It's now only 20% slower, having been reworked a bit.

    Dave.

      While you're at it, do you have any feel for the overhead imposed by Unicode support?

        Is there a Perl without Unicode support?

        CountZero

        A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

        My blog: Imperial Deltronics
Re: How much slower is perl (the binary) with threads than without?
by Anonymous Monk on May 10, 2012 at 20:41 UTC
Re: How much slower is perl (the binary) with threads than without?
by sundialsvc4 (Monsignor) on May 10, 2012 at 21:03 UTC

    It’s the same reason why we have single-processor and multi-processor versions of, say, Linux kernels.   (And why those kernels also have tests for the presence of multiple cores, with instructions to halt every core but one.)   If you know that threading will never be used, mutual exclusion gates can be omitted from the core interpreter.   (And, AFAIK, any attempt to use threading will be detected and prevented.)   But would I bother to do it?   Probably not ...

Re: How much slower is perl (the binary) with threads than without?
by Tux (Monsignor) on May 11, 2012 at 06:28 UTC

    I measure the difference every day when Test::Smokeing the perl core. The actual difference (runtime) changes over time, but at current blead, it is

    threadedis5.1%slowerthan non-threaded
    DEBUGGINGis4.4%slowerthan non-DEBUGGING
    stdiois5.2%slowerthan perlio

    Enjoy, Have FUN! H.Merijn
Re: How much slower is perl (the binary) with threads than without?
by Anonymous Monk on May 11, 2012 at 10:40 UTC

    Hi, the OP here

    Thank you for your input.

    I went and tested for my specific performance problem: generation of HTML tables. It was a fairly dumb, CGI-ish test, and there were not-benchmarky things such as using SSL for the database connection, and the database being on another server etc. Database connection was a basic DBI + DBD::Pg.

    The test was, in short: Query the database for the rows and format a HTML page of them, printing it to /dev/null. The table was about 300 rows, and had eight columns. There were a lot of function calls thanks to HTML escaping.

    The contestants were Perl 5.14.2 i686-linux-thread-multi-64int and i686-linux-64int, run on an old x86 computer.

    nothreads 33.8/s threads 28.7/s

    I'm certain that I would get different results if I added a web framework, templating language, or even a HTTP server into the mix, or ran the database on the same computer, or whatever. But I guess I can say that non-threaded Perl is about 17% faster for this limited test.

      When using a threaded perl, be sure to use DBI-1.620, as there have been changes in performance that mainly affect threaded builds.


      Enjoy, Have FUN! H.Merijn

        I suspect I had that version. The required modules were simply installed with /path/to/perl -MCPAN -e 'install DBD::Pg'.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (7)
As of 2014-04-18 12:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (466 votes), past polls