Announcement

Collapse
No announcement yet.

Ubuntu 7.04 to 8.10 Benchmarks: Is Ubuntu Getting Slower?

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

  • #21
    Originally posted by ssam View Post
    intel's naming scheme is confusing

    core solo = 32bit single core
    core duo = 32bit dual core
    core 2 solo = 64 bit single core
    core 2 duo = 64 bit dual core
    core 2 quad = 64 bit quad core
    core 2 extreme = 64 bit dual/quad

    the dual cores share cache (but that is a good thing (i think. lets you do openMP))

    The quads are actually two bits of silicon in one enclosure.

    there is far too much information on wikipedia :-)
    Sorry. I don't get what you are trying to say other than quoting a wikipedia article detailing the amount of available addresses.

    What was tested is a 32 bit OS environment on a 32 bit core processor. This isn't taking advantage of multiprocessing. I wonder if there is a difference in performance.

    One can make the argument that a 32bit processor on a 32 bit machine should not have a decrease in performance. But, what if there is an increase in performance between 7.04 to 8.10 by the advent using multiprocessing if those applications use this advantage.

    Comment


    • #22
      the tests were done on a core duo. that is a dual core CPU, so it can and is doing multiprocessing.

      Comment


      • #23
        What about power settings? Is there a chance that the CPU downclocked while running these tests, or is the userspace governor set to Performance? That could quite easily cause a major performance differential with the memory accesses and such.

        Comment


        • #24
          Originally posted by Pitabred View Post
          What about power settings? Is there a chance that the CPU downclocked while running these tests, or is the userspace governor set to Performance? That could quite easily cause a major performance differential with the memory accesses and such.
          EIST was disabled during testing. The Core Duo was running at its full speed the entire time.
          Michael Larabel
          https://www.michaellarabel.com/

          Comment


          • #25
            Personally, I don't think PTS in it's current form is suitable for benching distro version vs distro version. Since a distro is a culmination of pre-built packages, to do a A/B test items such as the encoding tests and such should utilize the distro's pre-builts instead of compiling them from source which may not have the same build flags.

            Comment


            • #26
              Originally posted by thacrazze View Post
              The cause for the bad performance is the CFS (Completly Fair Scheduler), I think. It's standard since 2.6.23/24.

              World of Warcraft on Wine lags terrible and freezes every some seconds since the introducing of CFS.

              I hope OpenSolaris supports my hardware completly soon, so that I can change to this OS.
              Total bullshit. You're too lazy to look at wine forum? It's wine problem not CFS and you have to tune CFS for wine... Best gaming experience (especially with wine) on open solaris XD

              And one more thing, some games under wine worked better with SD Scheduller (it was piece of cra... in my opinion, especially for desktop use), but not native.
              Last edited by kraftman; 27 October 2008, 03:18 PM.

              Comment


              • #27
                Well, (K)Ubuntu always felt to me as somewhat slower comparing to other distributions so it's not that surprising for me.
                Slowdown in GCC - compilation time is not regression - newer GCC is always armed with better, more sophisticated optimizations and resulting with longer compilation times - no shocker here.
                Java performance is a shocker here anyway.
                SQLite and Python performance may be improved *vastly* just using -O3 for CFLAGS - sometimes disregarded (on Phoronix) Linux distributions can be helpful...

                Comment


                • #28
                  Originally posted by reavertm View Post
                  Slowdown in GCC - compilation time is not regression - newer GCC is always armed with better, more sophisticated optimizations and resulting with longer compilation times - no shocker here.
                  That could make sense. After all, the compilation time is not a big deal as long as the resulting binaries are fast. BUT, as the test shows, the resulting binaries, at least of audio codecs, are much slower too.

                  It would be good to test the same LAME binary on the different Ubuntu versions (or just on different kernels). That way we could know if the problem is in GCC doing wrong optimizations or on a pure kernel regression.

                  Thanks for the tests!

                  Comment


                  • #29
                    Originally posted by reavertm View Post
                    SQLite and Python performance may be improved *vastly* just using -O3 for CFLAGS - sometimes disregarded (on Phoronix) Linux distributions can be helpful...
                    Not really, at least for SQLite.

                    Comment


                    • #30
                      Hhmmm, looking through the archives I've found some previous benchmarks that don't seem to confirm the issues found in this latest one.

                      For example, in this article Ubuntu 7.10 and 8.04 are compared and their performance is the same (for example, using LAME to encode an audio file takes the same time, while in the last article it's 53 vs. 116 secs).

                      Also the article comparing 12 kernel versions shows that all perform about the same.

                      So I'm rather inclined to think that something strange is happening with the hardware used to test. Maybe some driver regression that affects that laptop is causing all the troubles...

                      Comment

                      Working...
                      X