Genetec, on of the largest Video Management systems does everything in Mono.
Giving Mono Souper Powers
21–29 of 29 posts
Re: Giving Mono Souper Powers
#22Genetec, on of the largest Video Management systems does everything in Mono.
Nop, they use old dotnet framework, on windows, even for their embedded stuff. They use C# and F#.
Re: Giving Mono Souper Powers
#23I have a more general question: has anyone here built a truly portable app using Mono (i.e. one that runs on several platforms, has a reasonable number of active users and is supported) and can share some insights regarding performance and other issues? If you started today, would you still use Mono?
OpenSimulator [1] runs on .NET and Mono (for Linux and Mac).
That reminds me, the annual OpenSimulator Community Conference is this weekend [2].
It's a very mature project now, has been around more than a decade. I guess if it were started today, it would use .NET Core.
Re: Giving Mono Souper Powers
#24I've tried using Souper on a number of occasions to micro-optimize handwritten LLVM code and every single time it just returned the same code to me with different formatting. Has anyone else had better success with it? Perhaps all my cases where already optimal, but I have a hard time believing that. Or perhaps I should try again since it's been a few years.
Re: Giving Mono Souper Powers
#25I have a more general question: has anyone here built a truly portable app using Mono (i.e. one that runs on several platforms, has a reasonable number of active users and is supported) and can share some insights regarding performance and other issues? If you started today, would you still use Mono?
Emby - an alternative to Plex.
I have run it on Linux, and did not find any issues. Everything still worked.
Well, actually, it has/had a memory leak. Not sure if that's just on the Linux platform.
Re: Giving Mono Souper Powers
#26I've tried using Souper on a number of occasions to micro-optimize handwritten LLVM code and every single time it just returned the same code to me with different formatting. Has anyone else had better success with it? Perhaps all my cases where already optimal, but I have a hard time believing that. Or perhaps I should try again since it's been a few years.
I think some people tend to think like a compiler when they write code, and when you do, you less often get interesting compiler driven improvements. You are already folding constant expressions, lifting loop invariants out of loops etc.
Re: Giving Mono Souper Powers
#27I have a more general question: has anyone here built a truly portable app using Mono (i.e. one that runs on several platforms, has a reasonable number of active users and is supported) and can share some insights regarding performance and other issues? If you started today, would you still use Mono?
Syncplicity, a desktop file synchronization application, uses Mono on MAc.
The UI is native: WPF on Windows, Objective C on Mac. The core synchronization logic is shared C# code. (Objective C and C# co-exist via Pinvokes and function pointers.)
We started with Mono in 2010 before a lot of the modern tools, libraries, ect. At the time mono was very buggy. Now, Mono is a lot more stable.
As far as insights go:
We originally had, on Mac, a C# UI built with a (now obsolete) framework called MonObjC. The problem with MonObjC was that the only way to understand it was to be an Objective C expert; and it didn't always wrap the APIs in ways we needed. Thus, when we had some lawyer come and tell us that they didn't like the license, we just rewrote everything to PInvoke into shim C functions that call into Objective C. Thus, IMO, when in doubt, PInvoke into native code instead of fighting a compatibility layer.
Our Mac app packaging is all homegrown, primarily because our application predates the more modern mono packaging. I haven't tried the newer app packaging that comes with Visual Studio on Mac. IMO, make sure you understand app packaging.
Quite frankly, we've always had trouble with live debugging. (This might be due to our older packaging scheme.)
Ultimately, you need to understand the cost of writing something twice. When you work with Mono, or any cross platform framework / language / ect, you won't "write once." Instead, you will write once, debug on all platforms, and then add a bunch of special cases. Then, the developers who work on platform X will make a change that breaks platform Y because it wasn't covered in a unit test. Sometimes the cost of writing something twice really is worth it compared to the tradeoffs. (This certainly is the case with our UI, where we want a 100% native UI.)
Edit: We use dependency injection. (Via code, not a framework.) We have a lot of base classes in common code, and then platform-specific subclasses to handle special cases.
Re: Giving Mono Souper Powers
#28Does anyone know how well does mono to LLVM perform in contrast to standard RyuJIT on .Net Fx or .Net Core?
Re: Giving Mono Souper Powers
#29I have a more general question: has anyone here built a truly portable app using Mono (i.e. one that runs on several platforms, has a reasonable number of active users and is supported) and can share some insights regarding performance and other issues? If you started today, would you still use Mono?
Not a developer of it, but banshee was one of my favorite media players and ran on mono. I moved away from it, because it took too much CPU compared to deadbeef.