Announcement

Collapse
No announcement yet.

Why Mono Is Desirable For Linux

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

  • I've finished Limbo on Windows, and after tried HIB Limbo which uses Winelib I haven't noticed much difference. I only had to disable xfce compositor.

    In fact, running through Wine is faster than using Mono

    Comment


    • Originally posted by narciso View Post
      Well, we are talking about mono.

      Bastion and Rochard both use mono in Linux and both have much worse performance in Linux than Windows. Both games tested with an Nvidia Gtx680 at 2560x1440 resolution.

      In general other HIB games run on par with Windows, except Psyconaughts which is a lousy port.
      So please ask NVidia to improve the drivers. Search any webpage complaining on Bastion performance and they relate it with video performance. Like: https://bbs.archlinux.org/viewtopic.php?pid=1110411, there is even a trouble shoot page here: http://www.ubuntuvibes.com/2011/12/h...g-bastion.html

      Seems Mono can run really fast, try this youtube clip: http://www.youtube.com/watch?v=kCX42MSpRlU Comment related with the video link:

      Watch the video below showing Bastion running on Ubuntu 11.10. I haven't experienced any frame rate or lag issues so far. Lag in video is recording issue plus audio and video streams are a bit out of sync so bear with it.
      At the end, may you show to me where is related Bastion's slow performance with Mono? From a non biased source?

      Comment


      • Bastion ran fine for me but yes that is just another piece of anecdotal 'evidence'. Anyway I fail to see a logical reason for why Mono would perform worse under Linux than Windows. Also while Bastion is a REALLY beautiful game, it's game engine can't be particularly taxing as it is in essence a 2d isometric game with the heavy lifting being done by your graphics card and again as such I can't see why Mono would be the culprit if you have poor performance in this particular game.

        If we were talking some computationally heavy game using physics or some such then I could see how Mono might be a performance bottleneck but for this type of game? nah!

        Comment


        • Originally posted by XorEaxEax View Post
          Bastion ran fine for me but yes that is just another piece of anecdotal 'evidence'. Anyway I fail to see a logical reason for why Mono would perform worse under Linux than Windows. Also while Bastion is a REALLY beautiful game, it's game engine can't be particularly taxing as it is in essence a 2d isometric game with the heavy lifting being done by your graphics card and again as such I can't see why Mono would be the culprit if you have poor performance in this particular game.

          If we were talking some computationally heavy game using physics or some such then I could see how Mono might be a performance bottleneck but for this type of game? nah!
          Exactly. However I would not be surprised if Mono on Linux was slower then MS's .net runtime on windows, you know, being reversed engineered and all. Actually that is probably the case.

          Bastion does not use mono on windows, but MS's .net.
          The use a forked monogame (XNA replacement) on linux/osx.

          Comment


          • Originally posted by directhex View Post
            Wait, what? Can you show me the bugs relating to these architectures on http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=mono ?
            According to Popcon there are 196 people using Sparc, one using Sparc64, 75 using arm, 1164 using armel, and 53 using armhf.

            How many of the one percent of Debian users using these architectures are going to have mono installed to test if it works properly to file bugs?

            Comment


            • Originally posted by yogi_berra View Post
              According to Popcon there are 196 people using Sparc, one using Sparc64, 75 using arm, 1164 using armel, and 53 using armhf.

              How many of the one percent of Debian users using these architectures are going to have mono installed to test if it works properly to file bugs?
              I'm not the one who claimed they "didn't work properly". That was you. Where's your evidence?

              Comment


              • Originally posted by n3wu53r View Post
                Exactly. However I would not be surprised if Mono on Linux was slower then MS's .net runtime on windows, you know, being reversed engineered and all. Actually that is probably the case.

                Bastion does not use mono on windows, but MS's .net.
                The use a forked monogame (XNA replacement) on linux/osx.
                Mono implements mostly a specification of executing MSIL, and the virtual machine is not a a clone of .Net
                Let me elaborate why:
                - .Net from very early used SSA representation, when Mono did this just about with Mono 2.2 (named Linear-IL)
                - at least from public description of CLR Runtime blog, .Net can recognize specific patterns of IL and can optimize those preferentially. Also, it is specified that, in .Net, functions with less than 32 bytes of MSIL in length are candidates for inlining. As far as I'm aware, in Mono the inlining does not happen on MSIL, but on intermediate representation, so Mono theoretically at least can do better inlining than .Net
                - the GC in Mono is less tuned and obviously not a reverse engineered from .Net, or from Java for that matter, yet the latest incarnation is generational because of performance implications (a generational garbage collector is faster than a non-generational one)
                - both are likely using a Linear Scan Register Allocator, a quick&dirty policy to allocate registers, which is fast, but in complex routines with a lot of variables, it will mean that it will be like 15% slower than the same C++ code
                Are Mono applications slower? If you have a Gtk#/.Net compared with Gtk#/Mono/Linux, of course Mono can (and should) be faster, even more so if you have 64 bit OS:
                - Gtk# on Windows is only 32 bit, so your application will run on the 32 bit runtime on Windows, meaning: slower call convention (the 64 bit calling convention allows using registers for function calls) and fewer registers
                - Cairo on Windows is slow, so drawing of widgets can make it look sluggish (because is indirected paint to another CPU based library, GDI+)
                - Mono has a more generic optimizer, and does not try to find patterns that it will know that Visual Studio/C# will fed into it, so it may optimize better the sequences that your code really has
                - Mono is leaner than .Net (at least because it does not use COM, and not only), making it that the application to start (visibly) faster than the .Net equivalent.
                As of 2012, Mono is not this sluggish environment that some people are thinking of 5 years ago.
                Last edited by ciplogic; 19 September 2012, 05:47 AM.

                Comment


                • Here's a bug report by some guy who are using monogame on linux: http://monogame.codeplex.com/workitem/6971

                  He says that can't reach more than 40fps with a gtx570.

                  Comment


                  • Originally posted by narciso View Post
                    Here's a bug report by some guy who are using monogame on linux: http://monogame.codeplex.com/workitem/6971

                    He says that can't reach more than 40fps with a gtx570.
                    He also says that this is a REGRESSION of the latest git version (read: not thoroughly tested or used in production) and that it ran just peachy at 60 FPS before. So I fail to see what this has to do with anything.

                    Comment


                    • The report was in May and there's no fix yet, so if games use the latest version of mono they'll suffer from this performance issues.

                      Comment

                      Working...
                      X