Announcement

Collapse
No announcement yet.

Gentoo vs. Ubuntu performance comparison

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

  • #16
    Optimization flags are always used. In Ubuntu and every other distro too. They don't use --march though, since the apps needs to run on many types of CPU. Compiling with --march=core2, would result in the distro not being able to run on anything older than an Intel Core 2.

    However, that is not the reason why Gentoo was faster in this test. It's just that Gentoo doesn't include a lot of bloat by default.

    Comment


    • #17
      @mits: 32 bit binary distros such as Debian and Ubuntu use CFLAGS="-O2 -march=i486 -mtune=i686" because they have to run on older hardware too. (So no MMX/3DNow!/SSE for them). Other distros such as Arch and Fedora use -march=i686 which makes them look better in benchmarks at the expense of that compatibility.

      64 bit binary distros can use MMX/SSE/SSE2 for optimization, because all existing x86_64 CPUs support these instruction sets.

      Comment


      • #18
        I see... (I thought flags like -O2 were not used for some reason)
        so, a comparison between different -march settings would be nice...
        and if the performance gains are worth it, it would be meaningful to have a "kinda-new" architecture in linux distros, in which only the last x generations of cpus are supported...
        (I guess amd64 fits that role currently)

        Comment


        • #19
          Originally posted by mits
          Wouldn't it be nice to have an extra architecture in ubuntu that's fully optimized?
          I don't know if it would be nice, but it wouldn't be fair. Ubuntu is a distribution that is targeted at the general public, as is Debian or OpenSuse. They are binary distributions that aim to make sure that everything is easy on the user side. Users are not expected to compile their own kernels or their own packages. They can do it, sure, but they are not expected to; and if they do, they are on their own. On the other hand, the very nature of Gentoo--if I understand it correctly--is that the user takes a more active part on what (and how) is installed. I would assume that at a minimum, every Gentoo user especifically compiles her packages for the relevant target architecture plus some light optimisation flags. Since this is the default, it makes sense to do this if you want to benchmark Gentoo. However, it does not make sense to take Ubuntu, change everything about it, and read the results as if they had any meaning.

          You can apt-build world to recompile all the packages with your own optimisation flags in Debian/Ubuntu too. Would the benchmark results reflect what this distributions really are? Think about boot times benchmarks (extremelly pointless, I know); would it make sense to benchmark the boot time on a machine with tweaked runlevels and then claim that it reflects what distribution X is up to? If you think that it makes sense, you may as well accept the opposite, i.e. that it would make sense to benchmark it with all the possible daemons running from the beginning, mounting a dozen network drives, connecting to a hand of printers, starting a couple of mail servers and doing fsck on the local drives for good measure.

          Originally posted by RealNC
          that is not the reason why Gentoo was faster in this test. It's just that Gentoo doesn't include a lot of bloat by default.
          What bloat do you refer to that it would affect the numbers like that? It's not that Ubuntu runs random crappy applications for the sake of it--or that's what I hope.

          Comment


          • #20
            well, it runs gnome for the sake of it. It doesn't get any crappier.

            Apart from that, a release for everycpu out there (k8, amdfam10, core2, core, pentium4, pentiumm, centrino, blabla) would mean these thing:
            immense load for the mirrors
            immense pile of work for the packagers
            immense confusion for the users (which iso to download? I have a pentium4+64bit)
            exploding maintenance overhead.

            Comment


            • #21
              Originally posted by yotambien View Post
              What bloat do you refer to that it would affect the numbers like that? It's not that Ubuntu runs random crappy applications for the sake of it--or that's what I hope.
              Pulse Audio is a prime example

              More importantly, every configuration option of every package is enabled (I mean the "configure --with --enable" build-time stuff). That's a *lot*, a *LOT* of stuff, making the software bigger and more complex. And they need to, because the software needs to support all the possible things the users want.

              To give a specific example, mplayer in Ubuntu needs to support dozens of stuff like (random picks here): directfb, esd, ftp, ipv6, jack, joystick input, lirc, openal, samba, etc, etc, etc, etc. It's huge list of features compiled-in into mplayer.

              Gentoo doesn't work like that. I have all of those things disabled; they're not even in the executable. In Ubuntu, being a binary distro, all of that stuff is compiled into mplayer, regardless of whether you use the stuff or not.

              Now imagine this removal of "bloat" on a global scale; every program and every library too in your system can be trimmed to only have stuff in it that you actually use. This is "bloat removal" on a level no binary distro will ever be able to provide.
              Last edited by RealNC; 10-30-2009, 06:04 PM.

              Comment


              • #22
                But this is why I asked, because I had the feeling that you were refering to that 'bloat'. Are you sure that having more configure options will affect the performance of the program when you don't use the extra stuff? I remember comparing mplayer from Debian multimedia repo and a self-compiled one some time ago...I couldn't tell the difference, honestly.

                Comment


                • #23
                  Originally posted by chithanh View Post
                  LinuxMag has made a performance comparison of Gentoo at various gcc optimization levels against the previous release of Ubuntu (9.04).

                  http://www.linux-mag.com/id/7574/1/

                  The X11 and 3D performance comparison is not meaningful, as they compare different versions of the NVidia proprietary driver. But other benchmarks are quite interesting.

                  Their conclusion:


                  Of course the decision for or against Gentoo is not primarily due to performance, as the commenters point out.

                  Yep. About a year ago I installed 8.10 side by side with a newly built gentoo, and the newly built gentoo was faster for almost everything.

                  Actually as I'm typing this I'm preparing to nuke that ubuntu partition and reallocate all of the space to gentoo.

                  Disclaimer: Gentoo is not for everyone. If you don't know your way around source code or you don't like having to research how to make your machine do things other distros 'just do' by default, then stick with your current distro.

                  Comment


                  • #24
                    Originally posted by yotambien View Post
                    But this is why I asked, because I had the feeling that you were refering to that 'bloat'. Are you sure that having more configure options will affect the performance of the program when you don't use the extra stuff? I remember comparing mplayer from Debian multimedia repo and a self-compiled one some time ago...I couldn't tell the difference, honestly.
                    And did you tell a difference with mplayer between -march=your_cpu and -march=i486?

                    And how did you try to measure the difference in the first place? Because virtually no one can count FPS just by looking
                    Last edited by RealNC; 10-30-2009, 07:11 PM.

                    Comment


                    • #25
                      mplayer detects the cpu in the configure script and when you don't use --enable-runtime-cpudetection it will be optimized for the build system. I always recompile mplayer - with some extra patches which are not not mainline and luckyly even my slowest system does not need more than 3 min

                      Comment


                      • #26
                        Originally posted by RealNC View Post
                        Optimization flags are always used. In Ubuntu and every other distro too. They don't use --march though, since the apps needs to run on many types of CPU. Compiling with --march=core2, would result in the distro not being able to run on anything older than an Intel Core 2.
                        Not necessarily. I just built my athlon ii 620 system, and took the raid 1 drives out of my gentoo --march=core2 built system, and it booted up and ran fine after I recompiled my kernel for the hardware that had changed. If compiled for an older architecture via --march, there's a good chance it'll run on another cpu type (within the same family) so long as the new cpu type supports every feature that the old cpu supported.

                        EDIT: Oops, I originally read "older" as "other".

                        Comment


                        • #27
                          Maybe, but I know for sure that it won't run on a Pentium 4, because I actually tried and get "illegal instruction" errors.

                          Comment


                          • #28
                            Originally posted by yotambien View Post
                            I don't know if it would be nice, but it wouldn't be fair. Ubuntu is a distribution that is targeted at the general public, as is Debian or OpenSuse.
                            I didn't mean that it should generally be aimed towards newer systems, just that if there's a big difference between the performance of the greatest common divisor and the new hardware, maybe packages for a new arch should be made too (*kiiiind* of like amd64)

                            Comment


                            • #29
                              Originally posted by chithanh View Post
                              (...)the assumption that kernel version skewed the results is not consistent with the almost sweeping win of the 2.6.30 based system over 2.6.28.
                              Why not? Two kernel releases apart = huge differences in performance. Just look at the PostgreSQL performance delta 2.6.31 to 2.6.32.

                              Of course, I don't know if the different kernel causes performance differences or not, but it could - thus this comparison is useless.

                              Comment


                              • #30
                                Originally posted by RealNC View Post
                                And did you tell a difference with mplayer between -march=your_cpu and -march=i486?

                                And how did you try to measure the difference in the first place? Because virtually no one can count FPS just by looking
                                Heh, absolutely noone. I had used mplayer's benchmark option. I looked at the first minutes of a couple of random videos I had lying around, and the differences were minimal and seemingly random. I don't remember the compiling options, but Kano is probably right and mplayer does the right thing so it was expected that I didn't see any real differences. Other issue may be that they were MPEG-4 (low? simple?), nothing very demanding. Off topic, later on I also benchmarked mplayer's h264 decoding speed compared to mplayer using CoreAVC, and the results were again similar, except that the CPU burden was in different places (single processor here).

                                Comment

                                Working...
                                X