Page 20 of 32 FirstFirst ... 10181920212230 ... LastLast
Results 191 to 200 of 315

Thread: Why Mono Is Desirable For Linux

  1. #191
    Join Date
    May 2010
    Posts
    87

    Default

    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

  2. #192
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote 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?

  3. #193
    Join Date
    Oct 2009
    Posts
    845

    Default

    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!

  4. #194
    Join Date
    Oct 2011
    Posts
    224

    Default

    Quote 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.

  5. #195
    Join Date
    Oct 2008
    Posts
    878

    Default

    Quote 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?

  6. #196
    Join Date
    May 2012
    Posts
    347

    Default

    Quote 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?

  7. #197
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote 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; 09-19-2012 at 05:47 AM.

  8. #198
    Join Date
    May 2010
    Posts
    87

    Default

    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.

  9. #199
    Join Date
    Apr 2010
    Posts
    158

    Default

    Quote 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.

  10. #200
    Join Date
    May 2010
    Posts
    87

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •