Announcement

Collapse
No announcement yet.

Benchmarks Of The Gentoo-based Sabayon

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    What flags are each and what version of GCC? Can you give the specific times and uname -a?

    Comment


    • #32
      Originally posted by Apopas View Post
      Well I learnt everything I know about gcc and icc flags and optimizations in general. A source based distro helps a lot there.
      Also, I have not find a benefit yet to use Arch instead of Sabayon which is a binary edition of Gentoo.
      I don't think compilation flags are all that useful. Setting up user accounts, desktop environments, understanding the boot sequence, device detection, the unix philosophy (everything is a file, no output unless something fails, permissions) - that's useful. Gcc/Icc flags, not so much (unless you are a developer) .

      Besides, Arch has AUR which contains packages to build from source, so you get to learn about USE flags and similar stuff anyway.

      As to Sabayon vs Arch... no idea. Maybe a user of both can give some insight to the benefits of either distro, but so far it seems they are about on par to me.

      Comment


      • #33
        a meant average feeling
        Just boot faster, open programs faster, anything is faster
        may be not 25%, but ~10%.
        Anyway, i just like it.
        It gives me the best answer. I started with Debian (Red Hat and Suse failed to stay) and all those little things that were disturbing me, are not there.

        I'm surprised to see that a lot of people using Slack, Arch Gentoo

        Comment


        • #34
          Originally posted by Apopas View Post
          What flags are each and what version of GCC? Can you give the specific times and uname -a?
          AMD recommended -march=amdfam10 -mabm -msse4a
          Gentoo flags -march=amdfam10 -O2 -pipe
          Default suse flags -O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables

          AMD encode time=933 seconds
          Gentoo encode time=950 seconds
          suse defaults=952 seconds

          2.6.31.5-0.1 desktop #1 SMP PREEMPT

          GCC 4.4.2

          Comment


          • #35
            Originally posted by BlackStar View Post
            I don't think compilation flags are all that useful. Setting up user accounts, desktop environments, understanding the boot sequence, device detection, the unix philosophy (everything is a file, no output unless something fails, permissions) - that's useful. Gcc/Icc flags, not so much (unless you are a developer) .

            Besides, Arch has AUR which contains packages to build from source, so you get to learn about USE flags and similar stuff anyway.

            As to Sabayon vs Arch... no idea. Maybe a user of both can give some insight to the benefits of either distro, but so far it seems they are about on par to me.
            Through the ABS, it's possible to recompile the whole system from source.

            Comment


            • #36
              Originally posted by deanjo View Post
              Just for example I just compiled a couple handbrake (and it's supporting libraries which is extremely easy to do since it builds them specifically for hb use) using the recommended gentoo flags for Phenom II's. I then ran the same encode using the prepackaged rpm vs gentoos recommended vs AMD's recommended aggressive flags. Net result was a delta of 2% between the best version (AMD agressive flags) and worst versions (rpm and Gentoo recommended which were within seconds of each other and fall within standard deviation).
              Well, handbrake is rather pointless to use for this since the libraries it uses contains a ton of hand-optimized assembly code for all the time critical parts. So unless you explicitly tells the packages not to use hand-optimized assembly it will be worthless as a comparison between compiler options.

              Comment


              • #37
                Originally posted by BlackStar View Post
                I don't think compilation flags are all that useful. Setting up user accounts, desktop environments, understanding the boot sequence, device detection, the unix philosophy (everything is a file, no output unless something fails, permissions) - that's useful. Gcc/Icc flags, not so much (unless you are a developer) .
                I find them useful, you don't, while the personal opinion is subjective, the matter of knowledge is objective. Alas if we separate knowledge by usefulness or not.

                Besides, Arch has AUR which contains packages to build from source, so you get to learn about USE flags and similar stuff anyway.
                We had an argument about that once and I gave you the example with Mplayer. Gentoo is much more flexible for compilation. So flexible that you don't even understand that you compile, since it's as automatic as if you run apt-get in Ubuntu.

                As to Sabayon vs Arch... no idea. Maybe a user of both can give some insight to the benefits of either distro, but so far it seems they are about on par to me.
                It is the same with the addition that Sabayon has the flexibility of Gentoo when compilation takes place.

                Comment


                • #38
                  Originally posted by deanjo View Post
                  AMD recommended -march=amdfam10 -mabm -msse4a
                  Gentoo flags -march=amdfam10 -O2 -pipe
                  Default suse flags -O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables

                  AMD encode time=933 seconds
                  Gentoo encode time=950 seconds
                  suse defaults=952 seconds

                  2.6.31.5-0.1 desktop #1 SMP PREEMPT

                  GCC 4.4.2
                  So if I set AMD's recommended flags in my system's variable, probably I'll have an even faster system? Ithink I'll give it a try. That's the Gentoo power

                  Comment


                  • #39
                    Originally posted by XorEaxEax View Post
                    Well, handbrake is rather pointless to use for this since the libraries it uses contains a ton of hand-optimized assembly code for all the time critical parts. So unless you explicitly tells the packages not to use hand-optimized assembly it will be worthless as a comparison between compiler options.
                    Those libraries are the same libraries that pretty much every encoding application out there uses. The reason I used handbrake because it is very simple to apply the flags across for all the needed libraries. Also to note that over aggressive optimizations often result in slower binaries. My tests were to simply show that going from a base optimizations in x86-64 to "tweaker" flags certianly do not yield a 25% increase in speed and that one set of flags is not universal for best performance system wide.

                    Comment


                    • #40
                      From gcc flags you are not going ofcourse to get 25% boost. But the small advantage you get in combination with the lean system which means less CPU and memory usage you get a bonus which is obvious in some applications, especially games, Firefox etc, boot times, start up times and your desktop in general feels faster.
                      The best always is to find a formula to apply different system flags for different parts of the system. For example while I build my system with Gentoo's defaults, my encoders are compiled with O3.

                      I run a similar test with lame. Gcc 4.4.2 and Kernel 2.6.32.
                      SUSE defaults = 0m35.996s
                      Gentoo defaults = 0m35.080s
                      Gentoo with O3 = 0m34.928s

                      The difference finally is about 3% better performance. Not something exceptional, but why not since I can have it easily? In games the FPS are even higher, especially in opensource games that I compiled myself.
                      Also, my system boots in 22 seconds (grub to gdm) plus 8 secs for KDE. Not bad for a 5 years old CPU.
                      Also, with Gentoo is easy to use ICC. The results are even better, but I can't since I avoid proprietary apps.
                      Last edited by Apopas; 01-04-2010, 08:12 PM.

                      Comment


                      • #41
                        The biggest speed improvements you get from Gentoo are the fact that the bare minimum of services tend to be running, just like you get on other distros like Arch and Slackware.

                        I think the biggest feature Gentoo has going for it are the USE flags. Setting up a couple of those during setup and leaving the rest out can dramatically slim down an installation compared to most distros which tend to compile in support for everything.

                        As others have mentioned, the compile times are no big deal. They usually take maybe 15 minutes a weekend, and while it's going you are free to do other stuff like surf the web, so you hardly even notice it. And they provide binaries for a couple of large projects, like OpenOffice. Upgrading KDE can take a few hours, and if you switch to a newer version of GCC you're supposed to recompile the whole system which can take all night, but those are exceptions and not the rule. More commonly I did have to spend some time every now and then merging config files and figuring out emerge conflicts. They're usually quite simple, but certainly nothing I would want to show the "average" user, who would be much happier with Ubuntu/OpenSuse/etc.

                        Oh, and you really should just use march=native now with gcc4.4. No need to try and specify the architecture manually.
                        Last edited by smitty3268; 01-04-2010, 08:31 PM.

                        Comment


                        • #42
                          Originally posted by Apopas View Post
                          From gcc flags you are not going ofcourse to get 25% boost. But the small advantage you get in combination with the lean system which means less CPU and memory usage you get a bonus which is obvious in some applications, especially games, Firefox etc, boot times, start up times and your desktop in general feels faster.
                          The best always is to find a formula to apply different system flags for different parts of the system. For example while I build my system with Gentoo's defaults, my encoders are compiled with O3.

                          I run a similar test with lame. Gcc 4.4.2 and Kernel 2.6.32.
                          SUSE defaults = 0m35.996s
                          Gentoo defaults = 0m35.080s
                          Gentoo with O3 = 0m34.928s

                          The difference finally is about 3% better performance. Not something exceptional, but why not since I can have it easily? In games the FPS are even higher, especially in opensource games that I compiled myself.
                          Also, my system boots in 22 seconds (grub to gdm) plus 8 secs for KDE. Not bad for a 5 years old CPU.
                          Also, with Gentoo is easy to use ICC. The results are even better, but I can't since I avoid proprietary apps.
                          I'm not denying that there are small gains to be had nor am I saying nobody should use Gentoo as everybody has different needs. Heck I used to do LFS but PITA factor outweighed the small, almost non existent gains over a "in the can" solution. For those libs that did see an appreciable gain it was just as easy to recompile them from the src rpm after changing rpmbuilds default flags for my arch if I wanted a more permanent rebuild flags. In a network environment gentoo amounts to even more work where the system configs could be very wide spread.

                          Comment


                          • #43
                            Originally posted by smitty3268 View Post
                            The biggest speed improvements you get from Gentoo are the fact that the bare minimum of services tend to be running, just like you get on other distros like Arch and Slackware.
                            Bare minimum services running are just as easily done on other distro's, openSUSE for example even has a YaST module to do just that.

                            Comment


                            • #44
                              Originally posted by deanjo View Post
                              For those libs that did see an appreciable gain it was just as easy to recompile them from the src rpm after changing rpmbuilds default flags for my arch if I wanted a more permanent rebuild flags.
                              Yep but you can't do this system wide, since you won't be able to update your system through yast, or yum or apt, but donload the source rpms or debs manually and again compile them manually. Plus is impossible to disable features, since that needs to edit every rpm spec by hand and pray you didn;t forget something.
                              In a network environment gentoo amounts to even more work where the system configs could be very wide spread.
                              Depends. If the machines have similar hardware then the configs are the same as well. But even if they are not, then you just make a general stage4 and put it everywhere. Like this you don't get advantage over tthe binary distros, but still you can have as a lean system you want, which is a valuable advantage as well. but still as smitty3268 pointed, with gcc-4.4 you can use march=native, which helps a lot.
                              Also, the rolling nature of Gentoo, helps to keep every server and client moden for ever, unlike the conventional distros.
                              But for sure Gentoo isn't a distro which can be used in your machines in dt time unlike OpenSUSE etc.

                              Bare minimum services running are just as easily done on other distro's, openSUSE for example even has a YaST module to do just that.
                              True, but why we see so large differences in the benchmarks between binary distros even if they use the same DE, graphics and kernel?
                              Last edited by Apopas; 01-04-2010, 08:54 PM.

                              Comment


                              • #45
                                Originally posted by Apopas View Post
                                Yep but you can't do this system wide, since you won't be able to update your system through yast, or yum or apt, but donload the source rpms or debs manually and again compile them manually. Plus is impossible to disable features, since that needs to edit every rpm spec by hand and pray you didn;t forget something.
                                That's the power of having a personal build service. All of that is easily done automated.

                                Depends. If the machines have similar hardware then the configs are the same as well. But even if they are not, then you just make a general stage4 and put it everywhere. Like this you don't get advantage over tthe binary distros, but still you can have as a lean system you want, which is a valuable advantage as well. but still as smitty3268 pointed, with gcc-4.4 you can use march=native, which helps a lot.
                                Also, the rolling nature of Gentoo, helps to keep every server and client moden for ever, unlike the conventional distros.
                                But for sure Gentoo isn't a distro which can be used in your machines in dt time unlike OpenSUSE etc.
                                Again these issues are easily dealt with a build service where optimized packages can be built for pretty much any arch. openSUSE's public build service for example is pretty much next day releases when dealing with items such as X11, kernel, alsa, gcc and the various other quick changing projects.

                                True, but why we see so large differences in the benchmarks between binary distros even if they use the same DE, graphics and kernel?
                                That's the thing, I don't know where you see these huge differences. As far as the game tests in the above article goes again this can be done on any distro if you wish to compile from scratch or setup a build service to do so automatically. At work for example I run a build server there and separate packages are built for pentium 4, amd64, ia32e and ppc (distributed among various machines, some old workstations to newer machines that are just not used alot using icecream) . When a update comes out from the update service (or a upgrade version from watched projects) it goes out and retrieves the src rpm and builds updates for all of them utilizing the specific optimizations. Set and forget.
                                Last edited by deanjo; 01-04-2010, 09:22 PM.

                                Comment

                                Working...
                                X