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

Re: different versions of Perl

Expand Messages
  • Perrin Harkins
    ... No, there isn t. Frankly, unless you really need something that is in 5.8.1 you should stick with what you have. 5.6.1 is considerably faster. - Perrin
    Message 1 of 15 , Nov 3, 2003
      On Mon, 2003-11-03 at 12:12, Todd White wrote:
      > this system also has Perl version 5.8.1 installed. is there any way to
      > use the 5.8.1 interpreter without rebuilding mod_perl?

      No, there isn't. Frankly, unless you really need something that is in
      5.8.1 you should stick with what you have. 5.6.1 is considerably
      faster.

      - Perrin

      --
      Reporting bugs: http://perl.apache.org/bugs/
      Mail list info: http://perl.apache.org/maillist/modperl.html
    • Rafael Garcia-Suarez
      ... 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
      Message 2 of 15 , Nov 3, 2003
        Perrin Harkins wrote:
        >
        > On Mon, 2003-11-03 at 12:12, Todd White wrote:
        > > this system also has Perl version 5.8.1 installed. is there any way to
        > > use the 5.8.1 interpreter without rebuilding mod_perl?
        >
        > No, there isn't. Frankly, unless you really need something that is in
        > 5.8.1 you should stick with what you have. 5.6.1 is considerably
        > faster.

        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.

        --
        Reporting bugs: http://perl.apache.org/bugs/
        Mail list info: http://perl.apache.org/maillist/modperl.html
      • 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 3 of 15 , Nov 3, 2003
          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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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.