Announcement

Collapse
No announcement yet.

Mac OS X 10.5 vs. Ubuntu 8.10 Benchmarks

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

  • #11
    Originally posted by Pesho View Post
    In the filesystem and SQLite tests, the Ext3 filesystem gave Ubuntu a huge disadvantage. It's generally slow, and its default journalling mode is seriously buggy. You should have tested using a better filesystem, for example JFS.
    Each OS was left in their stock mode, which is why JFS or any other FS wasn't used.
    Michael Larabel
    https://www.michaellarabel.com/

    Comment


    • #12
      My love for Phoronix reports keeps growing and growing! Great job on this extensive comparison between Mac OS X and Ubuntu. Given the results, I have to say that I wouldn't expect Linux to win on a Mac Mini hardware both in the OpenGL and disk benchmarking area, because Apple will always have the upper hand here. That said, the SQLite results are not so good for Linux. BYTE Unix Benchmark, way to go! And looking forward to all the GEM and kernel-based mode setting goodness to kick in.

      Comment


      • #13
        I'm glad you're doing these benchmarks. Timing people makes them want to try harder. I haven't noticed any bad regressions in ubuntu yet, but the only way to get performance right is to always be aware of it.

        Comment


        • #14
          I think it's time to make a Windows Vista vs Ubuntu benchmark. of course use NVIDIA as GPU.

          Comment


          • #15
            Originally posted by hdas View Post
            (2) sure the default artwork might not suit one's taste, but thanks to the community, there is so much choice and a little effort on luser's part is all that is required. i myself hate the orange brown theme to the core (even though the light brown feisty and the hardy heron bird were pretty cool to my taste). i changed my entire system to all blue (including usplash boot and grub theme!). for the interested, look for 'bluman' theme in ubuntu-art.org. also i picked the nodoka gtk theme and echo icon theme and bluecurve cursors from fedora.
            I know, this is what mine looks like (http://www.isarapix.org/pix35/1225188868.png). My point is that if I'm going to customize it extensively I might as well use something like Arch where I get to trim away all the crap I don't need and where I am spared from the Debian package management system - Ubuntu is supposed to be a turnkey distro, and I would just love for it to be turnkey beautiful instead of turnkey 1995. Not just for myself but the image and the adoption rates that would lead to. Lots of people bought Vista purely on the eye candy. Many people who buy Macs buy them because the OS (and the hardware) is pretty. The GUI is the face of the OS, doesn't matter how solid it is, if users are met with grey task bars and some ugly brown splatter they're going to be less positive about it. I'm looking at this from a 'competing with Win/OSX' perspective which Shuttleworth claims is his goal.

            Comment


            • #16
              Originally posted by Pesho View Post
              In the filesystem and SQLite tests, the Ext3 filesystem gave Ubuntu a huge disadvantage. It's generally slow, and its default journalling mode is seriously buggy. You should have tested using a better filesystem, for example JFS.
              About the SQLite benchmarks - if they used stock SQLite (shipped with Leopard), they may be faster with 10.5 because default SQLite options are "cheating":

              On Mac OS X v10.4, there are only two settings to control the way in which data in a SQLite-based store is written to disk. In order to provide finer granularity of control over the tradeoff between performance and reliability, on Mac OS X v10.5 Core Data uses two independent pragmas to control these options.

              Note that the default fsync behavior on Tiger was fcntl(F_FULLFSYNC) but on Leopard it is now a standard fsync . (This affects all SQLite databases on Leopard, not just Core Data.) The pragma allows you to toggle this value. See ?Configuring a SQLite Store?s Save Behavior? in Persistent Stores for a full discussion.
              10.4 behaviour was:

              fsync on Mac OS X: Since on Mac OS X the fsync command does not make the guarantee that bytes are written, SQLite sends a F_FULLFSYNC request to the kernel to ensures that the bytes are actually written through to the drive platter. This causes the kernel to flush all buffers to the drives and causes the drives to flush their track caches. Without this, there is a significantly large window of time within which data will reside in volatile memory?and in the event of system failure you risk data corruption.
              On 10.5 it's no longer F_FULLFSYNC, which means that SQLite does not do full fsync by default on Leopard, which might be the case on Ubuntu, which might be the reason why it is much slower there.

              Comment


              • #17
                Originally posted by Pesho View Post
                In the filesystem and SQLite tests, the Ext3 filesystem gave Ubuntu a huge disadvantage. It's generally slow, and its default journalling mode is seriously buggy. You should have tested using a better filesystem, for example JFS.
                About the SQLite benchmarks ? if they used stock SQLite (shipped with Leopard), they may be faster because that default Leopard SQLite is "cheating":

                On Mac OS X v10.4, there are only two settings to control the way in which data in a SQLite-based store is written to disk. In order to provide finer granularity of control over the tradeoff between performance and reliability, on Mac OS X v10.5 Core Data uses two independent pragmas to control these options.

                Note that the default fsync behavior on Tiger was fcntl(F_FULLFSYNC) but on Leopard it is now a standard fsync . (This affects all SQLite databases on Leopard, not just Core Data.) The pragma allows you to toggle this value. See ?Configuring a SQLite Store?s Save Behavior? in Persistent Stores for a full discussion.
                10.4 behaviour was:

                fsync on Mac OS X: Since on Mac OS X the fsync command does not make the guarantee that bytes are written, SQLite sends a F_FULLFSYNC request to the kernel to ensures that the bytes are actually written through to the drive platter. This causes the kernel to flush all buffers to the drives and causes the drives to flush their track caches. Without this, there is a significantly large window of time within which data will reside in volatile memory?and in the event of system failure you risk data corruption.
                So maybe it's just faster on OS X because by default SQLite there does not issue full fsync, which may be the case on Ubuntu.

                Comment


                • #18
                  Originally posted by valgonzarp View Post
                  So maybe it's just faster on OS X because by default SQLite there does not issue full fsync, which may be the case on Ubuntu.

                  Yes, that's probably the main cause.

                  Comment


                  • #19
                    Originally posted by valgonzarp View Post
                    About the SQLite benchmarks ? if they used stock SQLite (shipped with Leopard), they may be faster because that default Leopard SQLite is "cheating":
                    PTS compiles it from scratch.

                    Comment


                    • #20
                      I'm disappointed for linux
                      still, Ubuntu is one of the slower linux distro's.

                      I wish there was hype behind some of these benchmarks, like there is on Acid tests for web rendering engines, or javascript stuff.
                      If there was such hype, I could see some linux people improving these a lot.

                      I agree with the post about lag since the 2.6.22 kernel in gutsy. I think it had to do with the scheduler. not convinced the CFS is completely fair

                      When i copy big files between HDs, my PC becomes unusable (quad core 4GB ram) seriously, I see no need for this.

                      Comment

                      Working...
                      X