Announcement

Collapse
No announcement yet.

Ubuntu 11.10 vs. Mac OS X 10.7.2 Performance

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

  • #21
    Originally posted by ninez View Post
    These people who think Apple products are are status symbol, need to give it up. Apple isn't that expensive and like you say Liam ~ Apple stores are very common and so are Macs and iOS devices. I also quite like MacOS...

    Mac's don't use a 'true' (mach) microkernel. While MacOSX/Darwin's (XNU aka: X not Unix) kernels are/were (partially) based on Mach, they actually call it a 'hybrid kernel'. It kind of it's own deal (in some people's mind's anyway). Some parts of the kernel follow the micro-kernel approach and are completely isolated from each other, but XNU also has parts that follow the monolithic model.. Here's some info on it. The 1st link it slightly dated (2007), but still very much applies;



    Mach's wikipedia also explains that Apple is not using a microkernel in OSX.

    http://en.wikipedia.org/wiki/Mach_(kernel)

    A little on the XNU kernel;



    You should be able to find additional resources from there liam.

    As for the BSD core inside of Mach;



    BSD in XNU is a built-in kernel module. Note this;

    /System/Library/Extensions/System.kext/PlugIns/BSDKernel.kext

    .kext = kernel extension.

    As a sidenote, as far as i know XNU / Darwin are both still opensource projects, so you could probably poke around the source code if you wanted to The PureDarwin (and OpenDarwin before that) projects aimed to make Darwin usable with the GNU toolchain but never really got too far along, although like i said i am fairly sure apple still makes their kernel sources and darwin available to the public.

    cheerz
    I was aware that they, along with the NT kernel, were considered hybrid, it just wasn't clear to me how they managed it (for that matter, it wasn't even clear what exactly a hybrid kernel is, since the definitions seemed to be "having characteristics of both a monolithic and microkernel"). If they are running their scheduler as a server that would help explain how they manage such good latency for a general purpose system. Though I do think Linux will end up being the general purpose kernel closest to a realtime kernel after some more of the Molnar tree gets brought in.
    Thanks for the great links. Looks like I've some reading to do

    Best/Liam

    Comment


    • #22
      Originally posted by ruel24 View Post
      You're speaking to the choir here, but a whole lot of Linux users run on old equipment and like their software free as in beer because they're cheap. I am a Linux user, so I do know this. People don't understand that Apple not only has high grade parts, such as beautiful IPS screens in iMacs, but they also build in subsidized costs such as OS upgrades for $29 and iWork for $79. I've owned Macs in the past, and my next computer will probably be a Mac. Right now, I run a home-brewed Core i7 that was stout when I built it, running Win 7 and PCLinuxOS as well as Mageia Linux distros.
      I wouodn't buy a Mac until they at least update to the standard UEFI. Matthew Garret has posted enoigh of his experiences on getting things to work well with his Air that it just doesn't make sense to buy a machine which requires so much unique effort to get linux to run "well".
      They really do make nice machines, though, but at least the ultrabook initiative is pointing out to vendors that there is a large market for nice kit. The ultrabook that I liked best, Lenovo's, had so much going for it. Awesome design, beautifully built and mostly nice componets, but it skimped in one crucial area: the screen. Now Apple may not use grwat screens on their laptops but they apparently do add some filter that improves viewing angles. Lenovo, however, cqn one uo Apple in thos area easily by offering an IPS screen like they do with some of their Thinkpads. If.they fixed that, Lenovo would have the very best slim notebook on the market.
      Regarding Linux users being cheap, I can see where you are coming from but I've seen far more people at conferences running Linux on a Mac or Thinkpad than any other single vendor. Neither of those are "cheap" options. At home I've no idea what they run, but surely a virtue of Linux iw having the option to run it on low end kit.

      Comment


      • #23
        Hey Liam,

        Originally posted by liam View Post
        I was aware that they, along with the NT kernel, were considered hybrid, it just wasn't clear to me how they managed it (for that matter, it wasn't even clear what exactly a hybrid kernel is, since the definitions seemed to be "having characteristics of both a monolithic and microkernel"). If they are running their scheduler as a server that would help explain how they manage such good latency for a general purpose system. Though I do think Linux will end up being the general purpose kernel closest to a realtime kernel after some more of the Molnar tree gets brought in.
        Thanks for the great links. Looks like I've some reading to do
        The whole 'Hybrid kernel' term is a bit of an odd one, but think of it this way ~ if you genetically engineered a cow and a pig together ~ we would call that a hybrid. The hybrid would exhibit features of both the pig and the cow. So in Apple's case - The XNU kernel has feature sets from both the Mach kernel and BSD kernel ...They've taken code from both kernels engineered them to overlap and work together, as well as integrating their own code + i/o kit.

        I think where people get confused with the term 'hybrid' (in terms of a kernel) is that they tend to look at it like monolithic vs. micro-kernel, and immediately try to resolve that. Instead, it might make more sense to look at it, as i have explained above ~ 2 or more kernels/technologies being blended into one that is unique in itself.

        As far as scheduling goes, i thought i had read somewhere that in Lion (10.7.x), there is actually a scheduler for user-space as well, while in Leopard/Snowy there wasn't. But i am not running Lion yet (i'm still using Snowy 10.6.8), and can't remember where i read about that off hand - i'll have to look though, as i am curious myself.

        But ya, i agree Linux is a better platform for the RT-type low-latency stuff. I already proved that to myself, a couple years ago when dual-booting my Macbook with MacOSX 10.5.x VS. Fedora using RT (now my distro of choice is Archlinux, though). I can't remember what the number's where but using MainStage with midi midi-controllers tended to choke a bit. While with Linux, running bigger graphs/large number of clients in Jackd ~ it wouldn't choke at all.

        I wonder if and when the day will come where the RT patches are FULLY upstream? ~ like all one would need to do, is use a boot flag or some other mechanism to enable it...

        cheerz
        Last edited by ninez; 31 January 2012, 08:42 PM.

        Comment


        • #24
          Originally posted by ninez View Post
          Hey Liam,



          The whole 'Hybrid kernel' term is a bit of an odd one, but think of it this way ~ if you genetically engineered a cow and a pig together ~ we would call that a hybrid. The hybrid would exhibit features of both the pig and the cow. So in Apple's case - The XNU kernel has feature sets from both the Mach kernel and BSD kernel ...They've taken code from both kernels engineered them to overlap and work together, as well as integrating their own code + i/o kit.

          I think where people get confused with the term 'hybrid' (in terms of a kernel) is that they tend to look at it like monolithic vs. micro-kernel, and immediately try to resolve that. Instead, it might make more sense to look at it, as i have explained above ~ 2 or more kernels/technologies being blended into one that is unique in itself.

          As far as scheduling goes, i thought i had read somewhere that in Lion (10.7.x), there is actually a scheduler for user-space as well, while in Leopard/Snowy there wasn't. But i am not running Lion yet (i'm still using Snowy 10.6.8), and can't remember where i read about that off hand - i'll have to look though, as i am curious myself.

          But ya, i agree Linux is a better platform for the RT-type low-latency stuff. I already proved that to myself, a couple years ago when dual-booting my Macbook with MacOSX 10.5.x VS. Fedora using RT (now my distro of choice is Archlinux, though). I can't remember what the number's where but using MainStage with midi midi-controllers tended to choke a bit. While with Linux, running bigger graphs/large number of clients in Jackd ~ it wouldn't choke at all.

          I wonder if and when the day will come where the RT patches are FULLY upstream? ~ like all one would need to do, is use a boot flag or some other mechanism to enable it...

          cheerz
          Hey ninez,

          The very fact that you think of the hybrid kernel as a cross between a pig and cow makes me think it must really be some kind of unholy frankensteinian monster created by men with dreams of godlike powers, but feet of clay. Considering how well both kernels actually work, it is something of a miracle that perhaps deserves a novelization with a somewhat happier ending than the original. Still, I get the point you are trying to convey
          According to Singh (http://osxbook.com/book/bonus/ancien.../arch_xnu.html) the scheduler runs in the kernel, but I'm not sure how recently that was updated. Likewise according to (http://developer.apple.com/library/m...CH211-BEHJDFCA) Mach is responsible for the scheduler, which suggests that it could be run as a server, but I couldn't find any documentation expressing that thought. It seems as though they maintain 3 APIs for scheduling, only one of which is accessible from user space (pthread), but I can't seem to find any mention of the schedulers themselves living in user space. Frankly, now that I'm looking at it a bit more closely, XNU looks like a mess of APIs! Linux has little to be ashamed of here. However, I do wish that Linux would try and attempt to implement the io kit interface for drivers since that would give us access to loads more good drivers (albeit closed source). IO kit itself looks pretty interesting since I first head about it yesterday. It's a large topic so I expect it will take awhile to absorb, but thus far it looks really nice and "simple", plus its been shown to work well.
          Regarding RT, coincidentally I've been looking for a preempt kernel for my system (fedora), but unfortunately Fedora themselves have ZERO interest in including one in the repos (and none of the standard 3rd part repos do one either, but I did find a relatively obscure repo that maintains one called http://ccrma.stanford.edu/planetccrm...planetcore/16/).
          Do you recall the news made last week about a Collabora dev hacking PA into Android? I've been having a conversation with him, and someone who seems like his colleague, about PA, JACK and RT. They seem to think PA can get a good deal better, latency-wise, but seem to think that actually replacing JACK will be extremely difficult, if even possible. Obviously my hope is that we can eventually get rid of one or the other sound servers in Linux b/c until there is, at a minimum though more would have to happen as well, an out-of-the-box solution, Linux won't be a primary platform for musicians. Currently setting up a true RT system is pretty complex. I know there is at least one distro that has done this in the past (Studio64), but I'm not sure which patches they're using (PREEMPT or RT, for instance), nor if they are even still active. Even if Studio64 is still around, setting up and tuning JACK doesn't look easy based upon the descriptions I've read. That needs to be easier.
          BTW, when you were running an RT kernel was it actually RT or the PREEMPT option? The former should let you get really tiny deltas if everything is properly setup, but I think that is way more than is needed for doing mixing, but I'm still curious as to how that kernel behaves in ordinary usage.

          Did you happen to catch the recent lwn article about the status of the realtime kernel, and its upstreaming progress? As usual Corbet seems hopeful, but I think things are looking better than in the past regarding potential tree merging.

          Comment


          • #25
            Originally posted by liam View Post
            Hey ninez,

            The very fact that you think of the hybrid kernel as a cross between a pig and cow makes me think it must really be some kind of unholy frankensteinian monster created by men with dreams of godlike powers, but feet of clay. Considering how well both kernels actually work, it is something of a miracle that perhaps deserves a novelization with a somewhat happier ending than the original. Still, I get the point you are trying to convey
            LOL.

            Originally posted by liam View Post
            According to Singh (http://osxbook.com/book/bonus/ancien.../arch_xnu.html) the scheduler runs in the kernel, but I'm not sure how recently that was updated. Likewise according to (http://developer.apple.com/library/m...CH211-BEHJDFCA) Mach is responsible for the scheduler, which suggests that it could be run as a server, but I couldn't find any documentation expressing that thought. It seems as though they maintain 3 APIs for scheduling, only one of which is accessible from user space (pthread), but I can't seem to find any mention of the schedulers themselves living in user space.
            I'll see if i can dig up a link or some info. Like i said i thought i had heard it was 'Lion' specific, which means it's somewhat newer, but who knows, maybe i am just confused.

            Originally posted by liam View Post
            Frankly, now that I'm looking at it a bit more closely, XNU looks like a mess of APIs! Linux has little to be ashamed of here. However, I do wish that Linux would try and attempt to implement the io kit interface for drivers since that would give us access to loads more good drivers (albeit closed source). IO kit itself looks pretty interesting since I first head about it yesterday. It's a large topic so I expect it will take awhile to absorb, but thus far it looks really nice and "simple", plus its been shown to work well.
            IO kit is good...so is having a stable ABI for developers to work with.... I think a lot of drivers in linux are very buggy, and is one area where linux is lacking.

            Originally posted by liam View Post
            Regarding RT, coincidentally I've been looking for a preempt kernel for my system (fedora), but unfortunately Fedora themselves have ZERO interest in including one in the repos (and none of the standard 3rd part repos do one either, but I did find a relatively obscure repo that maintains one called http://ccrma.stanford.edu/planetccrm...planetcore/16/).
            Ah, you found CCRMA. - I used to used that repo for audio stuff, when i used Fedora (it was my distro for a couple of years). the CCRMA rt-kernel should work nicely, the guy from Stanford University who maintains that repo knows his stuff. Beyond that you could always compile it yourself ~ i do every time a new RT release comes out. ~ But the difference being, since i use Archlinux, and more specifically the AUR -> compiling linux-rt and installing it is very straight forward, it would be like using 'yum install XYZ' in fedora. one quick command + compile time... it's that easy

            Originally posted by liam View Post
            Do you recall the news made last week about a Collabora dev hacking PA into Android? I've been having a conversation with him, and someone who seems like his colleague, about PA, JACK and RT. They seem to think PA can get a good deal better, latency-wise, but seem to think that actually replacing JACK will be extremely difficult, if even possible.
            PA wont ever replace Jackd. Jack provides a lot of stuff that PA simply doesn't do. Jack at this point has a lot of users (not only in Linux, but also Windows and OSX) and a lot of applications built with jack in mind (mainly linux ones, though). I can't see PA taking over that. I wouldn't want it to anyway. PA is never allowed to exist on my Linux boxes.

            Originally posted by liam View Post
            Obviously my hope is that we can eventually get rid of one or the other sound servers in Linux b/c until there is, at a minimum though more would have to happen as well, an out-of-the-box solution, Linux won't be a primary platform for musicians.
            Ya, i know what you mean. but PA isn't targeted for Proaudio, and ALSA is obviously a requirement (at least in the kernel). I personally wished ALSA had been fixed rather than introducing PA.... on the Jackd front - some commercial Proaudio software is starting to target Linux though. Aside from Harrison mixbus (ardour-based) and Renoise ... BitWig Studio will be available for linux and will also support Jackd (just like Renoise does). BitWig looks very much comparable to Ableton Live - so Bitwig could be a game changer for some.

            Originally posted by liam View Post
            Currently setting up a true RT system is pretty complex. I know there is at least one distro that has done this in the past (Studio64), but I'm not sure which patches they're using (PREEMPT or RT, for instance), nor if they are even still active. Even if Studio64 is still around, setting up and tuning JACK doesn't look easy based upon the descriptions I've read. That needs to be easier. BTW, when you were running an RT kernel was it actually RT or the PREEMPT option? The former should let you get really tiny deltas if everything is properly setup, but I think that is way more than is needed for doing mixing, but I'm still curious as to how that kernel behaves in ordinary usage.
            CONFIG_PREEMPT_RT_FULL=y ~ full preemption. I *am* running RT, not just PREEMPT.

            Linux ninez 3.0-rt #1 SMP PREEMPT RT Sat Jan 31 22:28:24 EST 2011 x86_64 AMD Phenom(tm) II X4 965 Processor AuthenticAMD GNU/Linux

            As far as behavior, i use RT all the time and i don't use a generic kernel at all. I also use Jackd as my default sound server - ie: it runs all the time, no PA no ALSA - just JAckd The only time i've gotten funny/odd behavior out of this machine was once when i plugged in a USB-drive but Jackd/soundcard made file transfers 'ridiculously slow' (until i killed jack, and unplugged the soundcard). But it only happened the once, and actually made sense being as Jack/apps were using 60-70% of each core, and the sound device had the highest rt-priorities...

            Originally posted by liam View Post
            Did you happen to catch the recent lwn article about the status of the realtime kernel, and its upstreaming progress? As usual Corbet seems hopeful, but I think things are looking better than in the past regarding potential tree merging.
            nope, but i'm gonna read about it now!

            cheers
            Last edited by ninez; 01 February 2012, 12:19 AM.

            Comment


            • #26
              Originally posted by liam View Post
              Apple doesn't produce super expensive computers. If someone wants to join the Apple club, they can get a pretty decent laptop for $1000.
              It really depends on how you are approaching Apple.

              For someone with a specific set of hardware in their minds to buy, Apple probably won't sell them exactly what they are looking for. So they have to go up to the next faster model, with correspondingly higher prices. Getting a PC with the exact hardware they want would definitely be cheaper.

              On the other hand, for someone with a specific budget, like $1000, who just wants the best hardware they can get for that specific price will generally do OK through Apple. Like any company, sometimes they have bad deals, and sometimes they're pretty decent.

              Comment


              • #27
                Originally posted by ltcommander.data View Post
                http://developer.apple.com/graphicsi...1072_Core.html

                As I mentioned in the previous OS X graphics comparison article, Lion now supports OpenGL 3.2 on Sandy Bridge. Apple went with Core profile only, so you have to specifically call for it, which I'm guessing the Phoronix test suite doesn't do. I believe Sandy Bridge on Windows is only at OpenGL 3.1 and with Linux at OpenGL 3.0, OS X looks to in fact have the best OpenGL support for Sandy Bridge, at least in terms of version/features. Seeing Oil Rush requires Lion on OS X, I presume it's using the OpenGL 3.2 path, so could be a good benchmark for OpenGL 3.x speed comparison between platforms.
                That's right, but it's still far behind when comes to AMD and nVidia hardware - openGL 3.2 vs Linux' 4.x.

                Comment


                • #28
                  Originally posted by kraftman View Post
                  Ubuntu is not only far better, faster (like benchmarks show), has much better graphic support (like OpenGL 3 with Intel while os x doesn't), it's much better as a gaming platform - Linux + wine kills os x.
                  But at least OS X has a native Steam client... Most of the open-source games that Linux runs will probably run in Mac OS, but the inverse is not necessarily true.

                  Comment


                  • #29
                    Originally posted by Veerappan View Post
                    But at least OS X has a native Steam client... Most of the open-source games that Linux runs will probably run in Mac OS, but the inverse is not necessarily true.
                    I know, but Linux + wine + OpenGL 4.x is better overall, because it allows you to play many more games.

                    Comment


                    • #30
                      Originally posted by Veerappan View Post
                      But at least OS X has a native Steam client... Most of the open-source games that Linux runs will probably run in Mac OS, but the inverse is not necessarily true.
                      Actually the Mac builds of many OSS games are broken/bit-rotten, because no dev wants to buy a Mac

                      It would also seem that Mac users rarely can devel, or maybe they're just not interested in FOSS.

                      Comment

                      Working...
                      X