Reply With QuoteI'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
Senior Member
Really? Honestly? You're including Limbo in that?Originally Posted by narciso
Phoronix Member
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
Senior Member
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:
At the end, may you show to me where is related Bastion's slow performance with Mono? From a non biased source?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.
Senior Member
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!
Senior Member
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.
Senior Member
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?
Senior Member
I'm not the one who claimed they "didn't work properly". That was you. Where's your evidence?
Senior Member
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 04:47 AM.
Phoronix Member
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.
Senior Member
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.
Posting Permissions