Announcement

Collapse
No announcement yet.

Mac OS X 10.5 vs. Ubuntu 8.10 Benchmarks

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

  • #76
    Originally posted by kraftman View Post
    I thought about that: "Still, linux will be playing catch up for a few years after 10.6 comes out." I quoted other comment, because I was answering to some part of it.
    That is the only area where I even mentioned OS X being better.


    Maybe it will proove that you're wrong?
    Testing 2 non-Mesa drivers against each other in different OS doesn't prove squat when it comes to finding out if Mesa is the limiting factor or not.

    Sorry, but I don't see it... Btw. I'm not interested in Apple's sweet talk. I'd prefer to see real advantages of Quartz over X.
    Look here:

    http://developer.apple.com/documenta...section_1.html

    http://developer.apple.com/documenta...424-TP30000559

    http://developer.apple.com/documenta...CH273-BBCEADBC

    For a reasonable laymans guide although be it is missing some of the 10.5 changes:
    http://arstechnica.com/reviews/os/macosx-10-4.ars/14

    Keep in mind as well that compositing didn't have to be disabled on the mac. It doesn't effect games as it does on linux where it slows openGL games and such.

    Comment


    • #77
      I think it is pertinent some comments about the graphics library and drivers used on both systems... And maybe illustrate a bit more how do graphics subsystems work on both platforms.

      First Mesa Vs Binary Blobs

      Mesa is an Open Source implementation (keyword for whatever other concepts exposed here after) of the OpenGL specification, that implicitly means that Mesa is NOT necessarily the same as OpenGL (just as Wine is not Windows, but an implementation of the WinAPI under Unix), and provides some of the functionality OpenGL does. OpenGL is very bureaucratic and is governed by a series of board members (ARB) who agree on a series of basic set of features and functionality the API and library has to provide. OpenGL is deployed on systems through the use of ICD (or Installable Client Driver) which usually gives the whole bunch of OpenGL functionality. This functionality by consensus is provided by a system library, the libGL.so library under Unix systems and OpenGL32.dll under Windows ; and a driver (ICD) which makes use of such library. More often than not, the drivers also include their own optimized implementation of the API as part of the ICD (i.e, their own libGL.so or OpenGL32.dll [or similar]) in order to provide optimized OpenGL rendering. What in fact is happening whenever you test the Open Drivers (Intel, ATi, Matrox, 3dfx, etc) under Linux/FreeBSD/OpenSolaris to any of the binary blobs (nVidia/ATi) is that you are actually comparing apples to oranges. These blobs are indeed an ICD, while the Open Drivers use Mesa as their OpenGL implementation. nVidia, ATi/AMD, Intel, SGI, Sun, Apple, Microsoft (they abandoned the ARB before Vista's release [and the OpenGL 2.0 specification release] IIRC, but I believe they're back), etc are actually members of the Architecture Review Board for OpenGL, what does this mean? Well, simply that the degree of performance you can expect to obtain from the implementation of any of these ARB members would be orders of magnitudes above Mesa (which is not an ARB member [though I believe there are special considerations towards Mesa]), then there is the degree of optimization that the driver coders can implement into the driver using Mesa (remember Mesa, even though implementing the whole OpenGL spec, may not be as optimized as an ARB member ICD).

      This is why comparing Mesa Vs a proper ICD usually ends up resulting in Mesa being much slower, if not due to features or system optimization, due to the large number of device architectures that make use of it. And this is another differentiator between Mesa and OpenGL ICDs. Mesa does not require by itself (just as OpenGL doesn't either) to be hardware accelerated, for accelerating Mesa (and OpenGL in Linux) the DRI mechanism was devised. As it name implies the Direct Rendering Infrastructure seeks to attain direct hardware access for accelerating OpenGL through Mesa (or a vendor's ICD) and is where X is more involved in the acceleration process, since by itself X does much of its rendering in an indirect manner (which is part of the core of the problems that it now presents for more sophisticated rendering on the desktop, by the way) and so there are two extra components that help accelerate in hardware the rendering through direct access, the userland DRI library, and the kernel-side Direct Rendering Manager kernel module, responsible for direct I/O to the hardware parsing calls from the DRI library above (carrying Mesa GL commands along to the graphics hardware). This is an overly simplified explanation and I'm sure that any DRI/DRM developers will have a heart attack by reading my explanation of how this works [or I think it works]).

      At any rate, a much more "fair" comparison would involve putting together a system that would match in hardware configuration and capabilities vis-a-vis comparable to the MacMini, however using another ICD OpenGL backend instead (like nVidia with an nVidia 7050 IGP or fglrx with an ATi HD3200/790G IGP), then the graphics comparison would be much more leveled (simply due to sheer OpenGL support)

      The XServer Vs Quartz.

      Again, overly simplified, as noted X11 was engineered to do indirect-over-the-network-through-sockets rendering, and it has excelled at that over the last 24 years. However this robustness, is its Achilles heel for fast desktop rendering. In a nutshell, the client-server architecture of X (which makes it network transparent) has the server running on the local computer, and clients (other machines, programs) connect to it for rendering, using network packets. This is rather convoluted (though it is very convenient for a lot of tasks such as mainframes and centralized rendering, etc), and that's where DRI comes in, it is a system to by pass the XServer and allow applications direct access to the graphics hardware instead. In this model the XServer is still the responsible for the rendering of the desktop, etc. From what I have been able to make out of Quartz (or rather Core Graphics), in its design the render path is much faster as it indeed has direct access to the hardware through the Quartz compositor (kind of like the XServer) and Quartz Extreme (using OpenGL), and has been very much optimized through the use of SIMD instructions (AltiVec, SSE) and hardware acceleration (OpenGL).

      The design and architecture of both rendering systems, though not mutually exclusive, do let you see the difference in applications they were thought for. Quartz was built from the ground-up to be a desktop rendering system, while X allows for more distributed rendering and seems to have been one of its original goals. It is not surprising that Apple decided to depart from X when they created OS X and built from scratch (well based on NextStep) Quartz and its compositor, to better suit the desktop needs. They indeed implemented X11, but instead of having X have its own server, it does render through Quartz as the server, providing the protocol and libraries for X client applications. I think that in Linux in the not so distant future, that is going to become the natural evolution for X, from an inherently indirect rendering nature, to a direct rendering one, and keeping backwards compatibility through support libraries. This transition (IMHO) started with the addition of Composite, Damages and other extensions which will have a more centric role in X... Still a LOT of work. What would be better, allow X to naturally transition, or have another renderer like Wayland provide X11 compatibility through a mechanism similar to Mac OS X's Quartz? I don't know, and most likely both systems will coexist for some time before a decision is made in what direction Linux on the desktop is taken.

      PS Sorry for the long post.
      Last edited by Thetargos; 11-14-2008, 09:18 AM.

      Comment


      • #78
        Originally posted by Thetargos View Post
        PS Sorry for the long post.
        No need to apologize +10 on the post. You hit the key points right on the head.

        Comment


        • #79
          Originally posted by deanjo View Post
          That is the only area where I even mentioned OS X being better.
          You didn't mentioned in that comment what area you were talking about and that's why I replied (sic!).

          Testing 2 non-Mesa drivers against each other in different OS doesn't prove squat when it comes to finding out if Mesa is the limiting factor or not.
          So, why you asked:
          Why do you think blobs bypass MUCH of X
          ? If those drivers aren't using mesa? Man, you're amazing me, but it doesn't matter...


          I asked for non Apple's link, but thanks. In this case they're probably objective.

          @Thetargos

          Thanks for this exhaustive comment .

          Comment


          • #80
            Originally posted by kraftman View Post
            So, why you asked: ? If those drivers aren't using mesa? Man, you're amazing me, but it doesn't matter...
            The blobs don't use mesa that's why.

            Comment


            • #81
              Originally posted by kraftman View Post
              So, why you asked: ? If those drivers aren't using mesa? Man, you're amazing me, but it doesn't matter...
              No, they don't. They use the ICD approach, providing themselves the GL library, why do you think you have a different libGL with the nVidia and fglrx drivers? ; and the GL library usually conflicts with the Mesa library included in most systems, and distribution packages manage to keep both libraries, making the proprietary GL library visible to the applications, but not breaking the installed Mesa package.

              Originally posted by kraftman View Post
              I asked for non Apple's link, but thanks. In this case they're probably objective.
              And I provided those Granted, I know not many give the same credit to the Wikipedia, but stillf or computing topics their articles are usually very well done.

              Originally posted by kraftman View Post
              @Thetargos

              Thanks for this exhaustive comment .
              You are welcome... It took me some three hours to post (as I wanted to make sure all my info was right )

              Comment


              • #82
                I'm confused... didn't ubuntu x86_64 win most of the tests?

                Why the dissappointment with the ubuntu results, that some of the posts here express?
                The Nexuiz tests on intel graphics are not interesting to me.
                sqlite test is important. Most sane people would use noatime or relatime, which should have dramatic results.

                I would love to see someone with similar/identical hardware post some PTS global links with different configurations/distros for comparison. Also, GNU/Linux is as much about choice as anything else - having the most default setup beat osx is just an added bonus.
                Last edited by unlotto; 11-22-2008, 07:56 PM. Reason: clarification

                Comment


                • #83
                  Originally posted by unlotto View Post
                  I'm confused... didn't ubuntu x86_64 win most of the tests?

                  Why the dissappointment with the ubuntu results, that some of the posts here express?
                  The Nexuiz tests on intel graphics are not interesting to me.
                  sqlite test is important. Most sane people would use noatime or relatime, which should have dramatic results.

                  I would love to see someone with similar/identical hardware post some PTS global links with different configurations/distros for comparison. Also, GNU/Linux is as much about choice as anything else - having the most default setup beat osx is just an added bonus.
                  Some people are just ticked OS X beat ubuntu in i/o limited and graphics tests. Compilation tests don't mean much either as different libraries and options will be different on both systems. One has to compile more the other doesn't.
                  Last edited by deanjo; 11-22-2008, 08:13 PM.

                  Comment


                  • #84
                    Originally posted by deanjo View Post
                    Some people are just ticked OS X beat ubuntu in i/o limited and graphics tests. Compilation tests don't mean much either as different libraries and options will be different on both systems. One has to compile more the other doesn't.

                    I/O limited and graphics tests don't mean much either in Phoronix test. You look like MACOS fanboy to me.

                    The blobs don't use mesa that's why.
                    Read 100x times more and maybe you will understand what I meant...
                    Last edited by kraftman; 11-23-2008, 10:45 AM.

                    Comment


                    • #85
                      Originally posted by kraftman View Post
                      I/O limited and graphics tests don't mean much either in Phoronix test. You look like MACOS fanboy too me.
                      I give credit were credit is due with a deep understanding of the issues not based on "brand X sucks" without having a clue about the subject.



                      Read 100x times more and maybe you will understand what I meant...
                      Maybe perhaps make your comments in a clear, concise manner that doesn't require filling in of the blanks and you will be more pleased with the answers. As it stands , you don't even seem to understand what uses mesa and what uses a optimized ICD.

                      Comment


                      • #86
                        Originally posted by deanjo View Post
                        I give credit were credit is due with a deep understanding of the issues not based on "brand X sucks" without having a clue about the subject.
                        You sound really funny :> You're just Mac OS fanboy (wait, you're dev probably) and you try to defend it. Luckily some people understand those issues and they're objective in their clues. I don't expect that Apple dev will be objective...

                        Maybe perhaps make your comments in a clear, concise manner that doesn't require filling in of the blanks and you will be more pleased with the answers. As it stands , you don't even seem to understand what uses mesa and what uses a optimized ICD.
                        It was clear, but due to your misunderstanding it has complicated a little. I was talking about something else... Simple question: do binary blobs use mesa (NVIDIA driver especially)? I want to hear it from you and it will be great if you just say: yes or no.

                        Comment


                        • #87
                          Here's a great article about tunning EXT3 file system:

                          http://www.heise-online.co.uk/open/T...tures/110398/0

                          Comment


                          • #88
                            Originally posted by kraftman View Post
                            You sound really funny :> You're just Mac OS fanboy (wait, you're dev probably) and you try to defend it. Luckily some people understand those issues and they're objective in their clues. I don't expect that Apple dev will be objective...
                            I develop for many OS's windows, *nix, osx. Currently coding satellite control systems.


                            It was clear, but due to your misunderstanding it has complicated a little. I was talking about something else... Simple question: do binary blobs use mesa (NVIDIA driver especially)? I want to hear it from you and it will be great if you just say: yes or no.
                            No the blobs do not use mesa.

                            Comment


                            • #89
                              Originally posted by deanjo View Post
                              No the blobs do not use mesa.
                              So, that's probably why blobs bypass MUCH of X :> You asked me before why I think so.

                              I wonder what journaling options were used during the tests. It seems that it matters a lot:

                              http://www-128.ibm.com/developerwork...ary/l-fs8.html

                              Theoretically, data=journal mode is the slowest journaling mode of all, since data gets written to disk twice rather than once. However, it turns out that in certain situations, data=journal mode can be blazingly fast.
                              Somehow, ext3's data=journal mode is incredibly well-suited to situations where data needs to be read from and written to disk at the same time.

                              Comment


                              • #90
                                Originally posted by kraftman View Post
                                So, that's probably why blobs bypass MUCH of X :> You asked me before why I think so.

                                I wonder what journaling options were used during the tests. It seems that it matters a lot:

                                http://www-128.ibm.com/developerwork...ary/l-fs8.html
                                Heh, did you take a look at the date on that article? Ext3 is not known for it's speed nowdays. Ars technica did a good breakdown of the filesystems out there a while back.

                                http://arstechnica.com/articles/paed...-systems.ars/1

                                There is also a good debian paper.

                                http://www.debian-administration.org/articles/388

                                To quote the ars article:

                                Despite valiant attempts to establish ReiserFS as a new standard, and the measurable superiority of systems like XFS, most Linux users are still using ext3. ext3 is not new. It's not super fast. It's not sexy. It won't cook your dinner. But it is tried and true, and for many people, that is more important.

                                Comment

                                Working...
                                X