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

Re: different versions of Perl

Expand Messages
  • 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 1 of 15 , Nov 3, 2003
      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 2 of 15 , Nov 3, 2003
        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 3 of 15 , Nov 3, 2003
          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 4 of 15 , Nov 3, 2003
            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 5 of 15 , Nov 3, 2003
              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 6 of 15 , Nov 3, 2003
                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 7 of 15 , Nov 4, 2003
                  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 8 of 15 , Nov 5, 2003
                    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 9 of 15 , Nov 5, 2003
                      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 10 of 15 , Nov 5, 2003
                        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 11 of 15 , Nov 5, 2003
                          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.