Mono has traditionally had a reputation as being a lot slower than .NET- perhaps that isn't the case any more either? It would be great to see some independent third party figures on this.
It's funny that the MS created C# is one of very few languages that lets you make native apps in iOS, Android and WP.
If you can in _any way_ achieve a method of using the existing android ui components and making them faster, this is a massive win.
Games (and often multimedia creation apps) have been rolling their own UI for a long time.
So games have always been the fastest, most optimized performers on any platform.
This isn't about games though - this is about regular ol' apps, many of which are incredibly slow and could really use the 8x performance improvement that these folks have been able to achieve.
As a mobile dev myself, I don't think mobile platforms are moving away from Obj-C or Java. Sure, we have a lot of custom-built widgets to overcome shortcomings in what Google/Apple provides, but ultimately they're subject to the same performance limitations that plague the stock widgets. Nobody out there is digging into low-level OpenGL optimizations to write a custom navigation bar, for example.
Most devs use some kind of wrapper library like Cocos2d to take the pain out of raw OpenGL, of course, and they can usually get by with much simpler library of widgets than the OS itself has to provide.
IMHO, the biggest problem with Windows Phone 7 (that wasn't emphasized much in all comparisons to iOS or Android) is the lack of support for native code. Whether this was done for legitimate reasons (like portability between ARM and x86) is not really important, what's important is that C++ is the language most games are written in and if you lack the support for it, then most games will only get ported if your platform is a clear winner, which is not the case yet for Windows Phone or Google TV ... therefore from what I know, Windows Phone 8 will have support for native code, because it badly needs it.
So I wouldn't worry too much about it.
We need to consider memory consumption too. Dalvik obviously uses less memory than regular JVM, and probably less than mono if I were to guess.
Also not sure about how optimized are the C# sources in relation to the Java sources
For example, in the Mandelbrot benchmark there are several differences
- Java uses more arrays
- C# and Java use different break conditions
- Calculations are done differently (with similar results)
Overall they're doing the same things, the C# is more like I remember it, so I'm guessing the Java code has some smart tricks up its sleeve
Here is the Java source for binary-trees, which is 6x faster than c#. http://shootout.alioth.debian.org/u64q/program.php?test=bina... C#: http://shootout.alioth.debian.org/u64q/program.php?test=bina...
Notice that the Java code multi-threaded, while the C# version is single-threaded. And the Q6600 being used there has 4 cores.
http://shootout.alioth.debian.org/u64q/program.php?test=bina...
In general, HotSpot is a more advanced VM that Mono is. They support dynamic recompilation at a higher optimization level, which we do not.
This is part of the debate in Google vs Oracle. Google could have used HotSpot had they figured out some agreement, but instead ended up with Dalvik which lacks many of the advanced optimizations of HotSpot.
That said, java -server compared against out of the box Mono 2.10.8 is not an apple's to apple's comparison, it is by no means "regular Java". That is Java tuned with some specific parameters. It comes at the expense of interactive time, Mono's default is fast-JIT, and fast startup.
Java -server uses a fixed heap, this means that you must preallocate how much memory the application will use during its entire lifetime. This is good for performance because the GC knows that it only has to scan for example memory between points A and B. 2 comparisons is all you need during GC to scan. Meanwhile, Mono is uses a dynamic heap, which means that it can grow its memory usage based on demand (no need to fine tune the maximum heap every time your app crashes due to a low setting) and can return the released memory to the OS. This complicates GC, because now we cant just compare against 2 values, we need to consider every object in the scope of a series of differently sized heaps.
With Mono 2.11, you can force your app to go fixed heap; The only people that really have a use for this are HPC people and a handful of server people. To be honest, most people dont want to configure the max heap of their server apps by crashing and trial and error.
The second component is that Mono's default is aimed for desktop/mobile configurations, not server loads. If you want to use server loads, run Mono with the --llvm flag: you will have very slow startup times, but you will get code quality that is essentially the same code quality that you get from an optimizing C compiler nowadays.
As for Mono vs Dalvik memory use, in practice people run Mono with Dalvik (Mono for Android), not in standalone mode, so we end up paying for Dalvik's memory footprint. But I agree, it would be nice to find out how much memory it actually uses.
Considering that we get the benefits of a more advanced GC, value types and generics while Java does not, it just seems like we would use less memory for comparable loads.
Since at least Java 5 the default on machines with 2 or more processors and 2GB or more memory has been -server. That's what regular out-of-the-box Java is on those machines.
Do many new laptops not have 2 processors and have less than 2GB?
Whats more bizarre is that windows phone 7 does not have a development kit for using C/C++. Only C#/XNA. I've heard on HN that this may change for WP8. I hope so.
I can develop ONE piece of core logic, and have it run on iOS, Android, Windows, Mac, even web (via NativeClient). I posted an AskHN about this earlier today (though not much interest). That sounds like a win.
I like C# although mono always failed to be nearly as good as .NET and that hindered C# a lot.
If microsoft had realized it and made .NET multiplaform as well, and open source, we may live in a different world today. Heck, Microsft could be leading.
But then again, rewritting the past is easier said than done.
I would expect the opposite - some runtimes do not allow exceptions, RTTI, dynamic_casting, or simply ABI interworkings due to name mangling and calling conventions for methods. Also virtual inhertiance and it's interworkings (where the this pointer is stored, and how multiple virtual ihneritance is done).
V8 is also C++, but lots of other successfull VM's are written in "C"
I like "C" because it's more limiting, hence I won't see templates overused, or latest trick used (SFINAE). It's also easier for me to read.
Also at binary level things are simpler - here is your function, and it's name, it takes this and this as parameter, and returns this and that, also follows this convetion (stdcall, pascal, fortran, etc.)
With C++ my biggest pain has been name mangling. I'm not sure why this was not standartized. It's actually much better that the name of the function automatically contains what types it can take, which would've been much easier for dynamic binding, but then you have GNU, MSVC and others totally differs on how they mangle the name (and from version to version it changes a lot). Also exception handling (mingw/cygwin/msvc - there is big confusion there, and on binary compability level it's hard to combine one with another).
My last show-stopper for C++ was - on this platform you can' t use this feature. For example on certain game consoles exceptions are not allowed. So you go with longjmp/setjmp, but then this would not unwind the stack and call destructors.
Most of all, I got bitten by a heavily templated math library - it was much faster with optimizations than the one before, but without (debug) it was several times slower than same one before it. Why? Because it was relying on inlining everything, and back then gcc for playstation2 was not really inlining everything, even if it was forced.
So every overloaded operation (matrix by matrix, or matrix by vector) was actually function call.
There is another gotcha - sometimes overloaded C++ operators lose their ability to short-cut. For example overloading && and || would not longer short-cut, and many other gotchas.
Most of all, I can't stand boost - it's just too huge.
But I'm totally fine with C++ the simple way (whatever this is) - best example for me is ZeroMQ lib - it's C++ internally, they limit themselves to not use exceptions, and provide "C" interface by default. This makes it very easy to use from other languages - python, lua, ruby, etc.
My choice right now is Lua + C - for fun & experimentation. I also dabbled with Common Lisp, but haven't touched code in it in months, might get back at it later...
You're right, a standardized mangling scheme would have been nice... but there's always 'extern "C"' if you need a C++ function from asm or a linker script.
Compilers really should short-circuit &&/||... were you using some kind of experimental compiler?
Then again, Linus said C++ developers were dumb and C was better.
Boost is almost a second standard library (it is one reference source used in the standards process), and it demonstrates a lot of what's cool and awful about C++. Boost invented a lot of the smart pointer classes that are now standard and save a lot of boilerplate that makes memory management in C annoying. Boost has things like Asio, which lets you write portable synchronous/asynchronous network code. On the other hand, it has Spirit, which is a massive abuse of operator overloading which is at once both impossibly complex and nifty/convenient.
Linus's opinion is worth noting, but he's hardly the best source.
And that's not a bad thing. I love C#/.Net (one of my projects, Tagxedo, was built with Silverlight), but given Microsoft doesn't have even the slightess will to push it, we may as well move on, or find some way to ride Mono. C++ is currently on my mind since it covers all ground (sans UI, which you still have to do anyway), probably in a way more straight-forward than Mono.
Derived from Win8 != WinRT- could just be the kernel and not app model.
I guess Armin Ronacher's blog post here makes a pretty good introduction:
That's one reason why the Mono implementation was always suboptimal, because implementing that API on top of poll, epoll, kqueue and the like is not really straightforward. It's also the reason for why the attempts to build alternative web servers are using bindings straight to libevent, bypassing the socket API.
The original plan was indeed for .NET to be portable to non-Windows platforms, but Windows-specific details have leaked in nonetheless.
- Microsoft has released a cross-platform CLR ("Rotor"). Win/Mac/BSD I believe. - C# and the CLR are ECMA specifications. - A lot of the class libs are definitely not Windows only. - Microsoft also has Silverlight (CLR) running on Mac, if that counts.
The whole .NET stack, apart from some Windows specific libraries (some COM+ management stuff, Win Forms) were definitely made to be cross-platform.
IIRC Rotor was more of a proof of concept, only supporting .Net 1, and later 2.0. It could not be built that easily either, and not bootstrapped.
Early C# (1.1 and 2.0) and the CLR specs were posted to ECMA, then it stopped. I think they published some more of it to ECMA much later, and some of the class platform too but it's still incomplete for .Net to be even remotely called an ECMA standard.
Silverlight does work on Mac, but on Linux you have to use Moonlight.
All in all, the Mono team went much, much farther than Microsoft, but it is impressive for Microsoft to have shown so much effort and so clear intent towards cross-platform support.
It costs $400 for a license, though. But boy I am tempted... I know, I know- you need to go with the native languages for the best experience. But keeping a huge chunk of my codebase between platforms is a very, very interesting idea to me.
Never forget about the users.
I get that there is a tradeoff involved, but the Mono-x products are in an interesting space. They aren't webviews (like PhoneGap), they aren't a weird JS hybrid (like Titanium)- they're full native experiences. You'll get some newly released features later (I imagine), but the user experience really shouldn't be affected that much.
With MonoTouch, you still write against the native iOS UI. Therefore, from the user's perspective, your app is native.
Since the UI is the same, the only thing that could be different between an ObjC and MonoTouch app is performance. In my experience there's no noticeable performance hit with MonoTouch except for app startup time (my MonoTouch app takes about 2 seconds to startup on a 3gs)
What about doing this improves the experience?
But MonoDevelop could sure use a lot of love...
The good news is that the community edition of IJ is Open Source (Apache licensed, IIRC) and there are quite a few existing language editors built on top of it. It isn't a rich client platform à la Eclipse or NetBeans, but I doubt such a thing would be required to win the affections of those who are unhappy using MonoDevelop.
iOS is more challenging, since F# depends on some dynamic-ish features of .NET that are not currently supported by MonoTouch on iOS.