Loading ...
Sorry, an error occurred while loading the content.

Re: different versions of Perl

Expand Messages
  • Perrin Harkins
    ... I ve been running benchmarks of various IPC modules, like MLDBM::Sync, DBD::MySQL, etc. A version of 5.6.1 with all defaults taken runs them about 50%
    Message 1 of 15 , Nov 3, 2003
    • 0 Attachment
      On Mon, 2003-11-03 at 12:21, Rafael Garcia-Suarez wrote:
      > Have you some benchmarks to back up this affirmation or is it only
      > an opinion ? If you have benchmarks, I know quite a lot of people
      > that would be interested.

      I've been running benchmarks of various IPC modules, like MLDBM::Sync,
      DBD::MySQL, etc. A version of 5.6.1 with all defaults taken runs them
      about 50% faster than the version of 5.8 that shipped with Red Hat 9.
      Granted, I heard that 5.8.1 made some gains in dealing with the overhead
      of unicode and Red Hat's Perl may be compiled with thread support (known
      to slow things down a lot), but I'd be surprised if 5.8.1 was as fast as
      5.6.1.

      - Perrin

      --
      Reporting bugs: http://perl.apache.org/bugs/
      Mail list info: http://perl.apache.org/maillist/modperl.html
    • Todd White
      as mentioned in my side message to you, Perrin, i m looking to 5.8.1 for its unicode support. specifically, to make it easy to output XML in UTF-8 as an OAI
      Message 2 of 15 , Nov 3, 2003
      • 0 Attachment
        as mentioned in my side message to you, Perrin, i'm looking to 5.8.1 for
        its unicode support. specifically, to make it easy to output XML in UTF-8
        as an OAI (Open Archives Initiative) repository.



        On 3 Nov 2003, Perrin Harkins wrote:

        > On Mon, 2003-11-03 at 12:21, Rafael Garcia-Suarez wrote:
        > > Have you some benchmarks to back up this affirmation or is it only
        > > an opinion ? If you have benchmarks, I know quite a lot of people
        > > that would be interested.
        >
        > I've been running benchmarks of various IPC modules, like MLDBM::Sync,
        > DBD::MySQL, etc. A version of 5.6.1 with all defaults taken runs them
        > about 50% faster than the version of 5.8 that shipped with Red Hat 9.
        > Granted, I heard that 5.8.1 made some gains in dealing with the overhead
        > of unicode and Red Hat's Perl may be compiled with thread support (known
        > to slow things down a lot), but I'd be surprised if 5.8.1 was as fast as
        > 5.6.1.
        >
        > - Perrin
        >
        > --
        > Reporting bugs: http://perl.apache.org/bugs/
        > Mail list info: http://perl.apache.org/maillist/modperl.html
        >
        >


        --
        Reporting bugs: http://perl.apache.org/bugs/
        Mail list info: http://perl.apache.org/maillist/modperl.html
      • Rafael Garcia-Suarez
        ... The perl shipped with RH 9 (actually a 5.8.0 + lots of patches) is compiled with threads and with a shared libperl.so, two factors that are known to slow
        Message 3 of 15 , Nov 3, 2003
        • 0 Attachment
          Perrin Harkins wrote:
          > I've been running benchmarks of various IPC modules, like MLDBM::Sync,
          > DBD::MySQL, etc. A version of 5.6.1 with all defaults taken runs them
          > about 50% faster than the version of 5.8 that shipped with Red Hat 9.
          > Granted, I heard that 5.8.1 made some gains in dealing with the overhead
          > of unicode and Red Hat's Perl may be compiled with thread support (known
          > to slow things down a lot), but I'd be surprised if 5.8.1 was as fast as
          > 5.6.1.

          The perl shipped with RH 9 (actually a 5.8.0 + lots of patches)
          is compiled with threads and with a shared libperl.so, two factors that
          are known to slow things down. I think that 5.8.0 is slower than 5.6.x,
          but not considerably. However I have no definitive numbers either.

          --
          Reporting bugs: http://perl.apache.org/bugs/
          Mail list info: http://perl.apache.org/maillist/modperl.html
        • Perrin Harkins
          ... Now that the dust has settled on 5.8.1, I will probably install it and run some of these same benchmarks soon. When I get some numbers, I ll post them. -
          Message 4 of 15 , Nov 3, 2003
          • 0 Attachment
            On Mon, 2003-11-03 at 12:45, Rafael Garcia-Suarez wrote:
            > The perl shipped with RH 9 (actually a 5.8.0 + lots of patches)
            > is compiled with threads and with a shared libperl.so, two factors that
            > are known to slow things down. I think that 5.8.0 is slower than 5.6.x,
            > but not considerably. However I have no definitive numbers either.

            Now that the dust has settled on 5.8.1, I will probably install it and
            run some of these same benchmarks soon. When I get some numbers, I'll
            post them.

            - Perrin

            --
            Reporting bugs: http://perl.apache.org/bugs/
            Mail list info: http://perl.apache.org/maillist/modperl.html
          • Perrin Harkins
            ... You really do need to recompile mod_perl, just as you would with any CPAN module that isn t pure Perl. What s the difficulty with recompiling? Is it just
            Message 5 of 15 , Nov 3, 2003
            • 0 Attachment
              On Mon, 2003-11-03 at 12:39, Todd White wrote:
              > as mentioned in my side message to you, Perrin, i'm looking to 5.8.1 for
              > its unicode support. specifically, to make it easy to output XML in UTF-8
              > as an OAI (Open Archives Initiative) repository.

              You really do need to recompile mod_perl, just as you would with any
              CPAN module that isn't pure Perl. What's the difficulty with
              recompiling? Is it just a political issue?

              - Perrin

              --
              Reporting bugs: http://perl.apache.org/bugs/
              Mail list info: http://perl.apache.org/maillist/modperl.html
            • Stas Bekman
              ... I know about the threads issue. But it s a first time I hear about a shared libperl.so. Is it relevant to mod_perl? It gets loaded at the server startup
              Message 6 of 15 , Nov 3, 2003
              • 0 Attachment
                Rafael Garcia-Suarez wrote:
                > Perrin Harkins wrote:
                >
                >>I've been running benchmarks of various IPC modules, like MLDBM::Sync,
                >>DBD::MySQL, etc. A version of 5.6.1 with all defaults taken runs them
                >>about 50% faster than the version of 5.8 that shipped with Red Hat 9.
                >>Granted, I heard that 5.8.1 made some gains in dealing with the overhead
                >>of unicode and Red Hat's Perl may be compiled with thread support (known
                >>to slow things down a lot), but I'd be surprised if 5.8.1 was as fast as
                >>5.6.1.
                >
                >
                > The perl shipped with RH 9 (actually a 5.8.0 + lots of patches)
                > is compiled with threads and with a shared libperl.so, two factors that
                > are known to slow things down. I think that 5.8.0 is slower than 5.6.x,
                > but not considerably. However I have no definitive numbers either.

                I know about the threads issue. But it's a first time I hear about a shared
                libperl.so. Is it relevant to mod_perl? It gets loaded at the server startup
                and I think produces no overhead at run-time. Or does it? Is it about
                resolving symbols at run-time vs. PERL_DL_NONLAZY=1, which doesn't happen in
                the static library?


                __________________________________________________________________
                Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                mailto:stas@... http://use.perl.org http://apacheweek.com
                http://modperlbook.org http://apache.org http://ticketmaster.com


                --
                Reporting bugs: http://perl.apache.org/bugs/
                Mail list info: http://perl.apache.org/maillist/modperl.html
              • Rafael Garcia-Suarez
                ... For discussion about this, see the INSTALL file, section Building a shared Perl library . You re right, maybe this doesn t impact mod_perl.
                Message 7 of 15 , Nov 3, 2003
                • 0 Attachment
                  Stas Bekman wrote:
                  > > The perl shipped with RH 9 (actually a 5.8.0 + lots of patches)
                  > > is compiled with threads and with a shared libperl.so, two factors that
                  > > are known to slow things down. I think that 5.8.0 is slower than 5.6.x,
                  > > but not considerably. However I have no definitive numbers either.
                  >
                  > I know about the threads issue. But it's a first time I hear about a shared
                  > libperl.so. Is it relevant to mod_perl? It gets loaded at the server startup
                  > and I think produces no overhead at run-time. Or does it? Is it about
                  > resolving symbols at run-time vs. PERL_DL_NONLAZY=1, which doesn't happen in
                  > the static library?

                  For discussion about this, see the INSTALL file, section "Building a shared
                  Perl library". You're right, maybe this doesn't impact mod_perl.

                  PERL_DL_NONLAZY is only for XS modules (AFAIK).

                  --
                  Reporting bugs: http://perl.apache.org/bugs/
                  Mail list info: http://perl.apache.org/maillist/modperl.html
                • Stas Bekman
                  ... In terms of performance, on my test system (Solaris 2.5_x86) the perl test suite took roughly 15% longer to run with the shared libperl.so. Your system and
                  Message 8 of 15 , Nov 4, 2003
                  • 0 Attachment
                    Rafael Garcia-Suarez wrote:
                    > Stas Bekman wrote:
                    >
                    >>>The perl shipped with RH 9 (actually a 5.8.0 + lots of patches)
                    >>>is compiled with threads and with a shared libperl.so, two factors that
                    >>>are known to slow things down. I think that 5.8.0 is slower than 5.6.x,
                    >>>but not considerably. However I have no definitive numbers either.
                    >>
                    >>I know about the threads issue. But it's a first time I hear about a shared
                    >>libperl.so. Is it relevant to mod_perl? It gets loaded at the server startup
                    >>and I think produces no overhead at run-time. Or does it? Is it about
                    >>resolving symbols at run-time vs. PERL_DL_NONLAZY=1, which doesn't happen in
                    >>the static library?
                    >
                    >
                    > For discussion about this, see the INSTALL file, section "Building a shared
                    > Perl library". You're right, maybe this doesn't impact mod_perl.

                    Hmm, I wonder about this para from that file:

                    ---
                    In terms of performance, on my test system (Solaris 2.5_x86) the perl
                    test suite took roughly 15% longer to run with the shared libperl.so.
                    Your system and typical applications may well give quite different
                    results.
                    ---

                    The whole point of using shared libs is that if there are more than one app
                    using the same library it gets loaded only once. I don't know who wrote the
                    claim above, but have you tried doing perl -le 'sleep 1000 while 1' in another
                    window (of course using the same perl) and then start the test suite? This way
                    libperl.so will be constantly loaded and won't cause the loading overhead. I
                    suppose that depending on the OS the loader may even remember the symbols it
                    has resolved at run-time. The perl test suite spawns a lot of fresh perls
                    which causes most of the overhead.

                    > PERL_DL_NONLAZY is only for XS modules (AFAIK).

                    Could be. But I what I meant is whatever the dlopen flag for resolving symbols
                    right away is, and not doing the lazy loading. This is of course of other perl
                    programs can benefit from this resolving. If not it will just slow things down.

                    Actually on several OSs you have no choice but to resolve all the symbols when
                    the shared library is loaded (OS X?), which in case of libperl.so makes a huge
                    overhead if you just need a few dozen of symbols out of 4K+ symbols.

                    __________________________________________________________________
                    Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                    http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                    mailto:stas@... http://use.perl.org http://apacheweek.com
                    http://modperlbook.org http://apache.org http://ticketmaster.com


                    --
                    Reporting bugs: http://perl.apache.org/bugs/
                    Mail list info: http://perl.apache.org/maillist/modperl.html
                  • Gisle Aas
                    ... I also found 15% slowdown with perlbench on Linux. ... The slowdown is not in the loading. The core perl code runs slower because it is compiled with
                    Message 9 of 15 , Nov 5, 2003
                    • 0 Attachment
                      Stas Bekman <stas@...> writes:

                      > Hmm, I wonder about this para from that file:
                      >
                      > ---
                      > In terms of performance, on my test system (Solaris 2.5_x86) the perl
                      > test suite took roughly 15% longer to run with the shared libperl.so.
                      > Your system and typical applications may well give quite different
                      > results.

                      I also found 15% slowdown with perlbench on Linux.

                      > The whole point of using shared libs is that if there are more than
                      > one app using the same library it gets loaded only once. I don't know
                      > who wrote the claim above, but have you tried doing perl -le 'sleep
                      > 1000 while 1' in another window (of course using the same perl) and
                      > then start the test suite? This way libperl.so will be constantly
                      > loaded and won't cause the loading overhead.

                      The slowdown is not in the loading. The core perl code runs slower
                      because it is compiled with -fpic to make it position independent when
                      you enable 'useshrplib'.

                      Regards,
                      Gisle

                      --
                      Reporting bugs: http://perl.apache.org/bugs/
                      Mail list info: http://perl.apache.org/maillist/modperl.html
                    • Stas Bekman
                      ... I should give it a try and see if my ideas make any difference. ... If I understand correctly the following description from the gcc manpage: -fpic
                      Message 10 of 15 , Nov 5, 2003
                      • 0 Attachment
                        Gisle Aas wrote:
                        > Stas Bekman <stas@...> writes:
                        >
                        >
                        >>Hmm, I wonder about this para from that file:
                        >>
                        >>---
                        >>In terms of performance, on my test system (Solaris 2.5_x86) the perl
                        >>test suite took roughly 15% longer to run with the shared libperl.so.
                        >>Your system and typical applications may well give quite different
                        >>results.
                        >
                        >
                        > I also found 15% slowdown with perlbench on Linux.

                        I should give it a try and see if my ideas make any difference.

                        >>The whole point of using shared libs is that if there are more than
                        >>one app using the same library it gets loaded only once. I don't know
                        >>who wrote the claim above, but have you tried doing perl -le 'sleep
                        >>1000 while 1' in another window (of course using the same perl) and
                        >>then start the test suite? This way libperl.so will be constantly
                        >>loaded and won't cause the loading overhead.
                        >
                        >
                        > The slowdown is not in the loading. The core perl code runs slower
                        > because it is compiled with -fpic to make it position independent when
                        > you enable 'useshrplib'.

                        If I understand correctly the following description from the gcc manpage:

                        -fpic
                        Generate position-independent code (PIC) suitable for use in a
                        shared library, if supported for the target machine. Such code
                        accesses all constant addresses through a global offset table
                        (GOT). The dynamic loader resolves the GOT entries when the pro-
                        gram starts (the dynamic loader is not part of GCC; it is part of
                        the operating system). If the GOT size for the linked executable
                        exceeds a machine-specific maximum size, you get an error message
                        from the linker indicating that -fpic does not work; in that case,
                        recompile with -fPIC instead. (These maximums are 16k on the m88k,
                        8k on the SPARC, and 32k on the m68k and RS/6000. The 386 has no
                        such limit.)

                        Position-independent code requires special support, and therefore
                        works only on certain machines. For the 386, GCC supports PIC for
                        System V but not for the Sun 386i. Code generated for the IBM
                        RS/6000 is always position-independent.

                        it affects only the loading time:

                        The dynamic loader resolves the GOT entries when the program starts

                        Doesn't it imply that once resolved, there is no more run-time overhead incurred?

                        __________________________________________________________________
                        Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                        http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                        mailto:stas@... http://use.perl.org http://apacheweek.com
                        http://modperlbook.org http://apache.org http://ticketmaster.com


                        --
                        Reporting bugs: http://perl.apache.org/bugs/
                        Mail list info: http://perl.apache.org/maillist/modperl.html
                      • Wilt, Paul
                        Stas: Actually there is continued overhead due to the fact that different instructions (that require a larger number of cycles to decode / dispatch) are used
                        Message 11 of 15 , Nov 5, 2003
                        • 0 Attachment
                          Stas:

                          Actually there is continued overhead due to the fact that different
                          instructions (that require a larger number of cycles to decode / dispatch)
                          are used when calling subroutines and / or accessing memory in a shared
                          environment.

                          Paul E Wilt
                          Senior Principal Software Engineer
                          ProQuest Information and Learning
                          ---------------------------------------------------------
                          http://www.proquest.com mailto:paul.wilt@...
                          300 North Zeeb Rd Phone: (734) 302-6777
                          Ann Arbor, MI 48106 Fax: (734) 302-6779
                          ---------------------------------------------------------



                          -----Original Message-----
                          From: Stas Bekman [mailto:stas@...]
                          Sent: Wednesday, November 05, 2003 4:17 AM
                          To: Gisle Aas
                          Cc: Rafael Garcia-Suarez; perrin@...; modperl@...
                          Subject: Re: different versions of Perl


                          Gisle Aas wrote:
                          > Stas Bekman <stas@...> writes:
                          >
                          >
                          >>Hmm, I wonder about this para from that file:
                          >>
                          >>---
                          >>In terms of performance, on my test system (Solaris 2.5_x86) the perl
                          >>test suite took roughly 15% longer to run with the shared libperl.so.
                          >>Your system and typical applications may well give quite different
                          >>results.
                          >
                          >
                          > I also found 15% slowdown with perlbench on Linux.

                          I should give it a try and see if my ideas make any difference.

                          >>The whole point of using shared libs is that if there are more than
                          >>one app using the same library it gets loaded only once. I don't know
                          >>who wrote the claim above, but have you tried doing perl -le 'sleep
                          >>1000 while 1' in another window (of course using the same perl) and
                          >>then start the test suite? This way libperl.so will be constantly
                          >>loaded and won't cause the loading overhead.
                          >
                          >
                          > The slowdown is not in the loading. The core perl code runs slower
                          > because it is compiled with -fpic to make it position independent when
                          > you enable 'useshrplib'.

                          If I understand correctly the following description from the gcc manpage:

                          -fpic
                          Generate position-independent code (PIC) suitable for use in a
                          shared library, if supported for the target machine. Such code
                          accesses all constant addresses through a global offset table
                          (GOT). The dynamic loader resolves the GOT entries when the
                          pro-
                          gram starts (the dynamic loader is not part of GCC; it is part
                          of
                          the operating system). If the GOT size for the linked
                          executable
                          exceeds a machine-specific maximum size, you get an error
                          message
                          from the linker indicating that -fpic does not work; in that
                          case,
                          recompile with -fPIC instead. (These maximums are 16k on the
                          m88k,
                          8k on the SPARC, and 32k on the m68k and RS/6000. The 386 has
                          no
                          such limit.)

                          Position-independent code requires special support, and
                          therefore
                          works only on certain machines. For the 386, GCC supports PIC
                          for
                          System V but not for the Sun 386i. Code generated for the IBM
                          RS/6000 is always position-independent.

                          it affects only the loading time:

                          The dynamic loader resolves the GOT entries when the program
                          starts

                          Doesn't it imply that once resolved, there is no more run-time overhead
                          incurred?

                          __________________________________________________________________
                          Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                          http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                          mailto:stas@... http://use.perl.org http://apacheweek.com
                          http://modperlbook.org http://apache.org http://ticketmaster.com


                          --
                          Reporting bugs: http://perl.apache.org/bugs/
                          Mail list info: http://perl.apache.org/maillist/modperl.html

                          --
                          Reporting bugs: http://perl.apache.org/bugs/
                          Mail list info: http://perl.apache.org/maillist/modperl.html
                        • Stas Bekman
                          ... That would be a very badly designed shared lib support. Those instructions are supposed to be cached, aren t they? From what I understand the shared
                          Message 12 of 15 , Nov 5, 2003
                          • 0 Attachment
                            Wilt, Paul wrote:
                            > Stas:
                            >
                            > Actually there is continued overhead due to the fact that different
                            > instructions (that require a larger number of cycles to decode / dispatch)
                            > are used when calling subroutines and / or accessing memory in a shared
                            > environment.

                            That would be a very badly designed shared lib support. Those instructions are
                            supposed to be cached, aren't they? From what I understand the shared
                            libraries concept was designed to make upgrades easy, save memory and provide
                            other benefits, without losing the speed benefits of the static libs. Reading
                            some papers from Ulrich Drepper (http://people.redhat.com/drepper/) suggests
                            that the latest glibc libs 2.3.x is suppose to be much better at giving you a
                            good performance with shared libs. It also suggest that -fpic is about 3 times
                            faster than -fPIC. This is all discussed in details at:
                            http://people.redhat.com/drepper/dsohowto.pdf

                            In any case, perlbench indeed shows a signifact performance difference, so I'd
                            rather believe numbers than promises, untill someone proves it wrong ;) So we
                            need to add one more tip to the bag-of-performance tricks: Use less shared
                            libs if you can, especially avoid libperl.so.

                            p.s. According to the paper I've quoted above (See section 2), it takes one
                            extra instruction for -fpic and 3 for -fPIC to do the dispatch and not a large
                            number of cycles as you have suggested above, Paul ;) Unless we are talking
                            about different things (and may be different architectures).

                            __________________________________________________________________
                            Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                            http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                            mailto:stas@... http://use.perl.org http://apacheweek.com
                            http://modperlbook.org http://apache.org http://ticketmaster.com


                            --
                            Reporting bugs: http://perl.apache.org/bugs/
                            Mail list info: http://perl.apache.org/maillist/modperl.html
                          Your message has been successfully submitted and would be delivered to recipients shortly.