Page 4 of 7 FirstFirst ... 23456 ... LastLast
Results 31 to 40 of 62

Thread: Mono Developers Renew Their Love For Microsoft

  1. #31
    Join Date
    Feb 2013
    Posts
    233

    Default

    Quote Originally Posted by Pajn View Post
    I really like C# as a language. But the way Microsoft treat is I'm never gonna use it when I have the choice.
    Microsoft need to create a full standard and make an open implemention the reference.

    Also with Java 8 i feel less urge to use C#
    Microsoft does give you a much better choice than C#: F#

    Scala is better than Java (and C#) in almost every way. Even Java 8. I do hope the Scala team updates to JDK 8 and provides platform lambda compatibility. Android is the big problem that pushes everyone for JDK 6 compatibility.

    C# has a zillion technical problems, major ugly technical problems, but beyond those, it's not a platform-agnostic, general purpose language. It's an integration langauge for Microsoft tech stacks. If you don't want a Microosft centric tech stack, C# and .NET usually doesn't make sense.

  2. #32
    Join Date
    Feb 2013
    Posts
    233

    Default

    Quote Originally Posted by ciplogic View Post
    This is not true anymore.
    I can say that there are definitely parts where Mono and .Net (and to some extend Java) are faster than C++:
    When http://benchmarksgame.alioth.debian.org/ was alive, C/C++ generally ran the fastest, Java behind that, C#/MS .NET behind that, and Mono was much slower than MS.NET.

    Quote Originally Posted by ciplogic View Post
    There is one case when Mono runs virtually the same as C++: on iOS as it uses the same compiler/optimizations as a C++ compiler would do it.
    citations? I'm skeptical of this.

    Beyond the speed, those kinds of porting layers often add a lot of unwanted complexity to the application development stack. They add extra layers that have be debugged through in the case of problems.

  3. #33
    Join Date
    Feb 2013
    Posts
    233

    Default

    Quote Originally Posted by directhex View Post
    This is a Javaism. Hotspot allocates enormous amounts of memory.

    Mono isn't particularly RAM-heavy.
    I've seen Java allocate lots of memory on really small benchmark apps, but on larger apps, in my experience, it depends on how much data your app loads in memory. Java doesn't add much overhead. I wrote code that loaded 4.5 GB of binary data into memory and performed data analysis. The Java app took ~4.5GB of RAM. I believe the JVM had a few megs of overhead, but that's just a rounding error with data that large.

  4. #34
    Join Date
    Apr 2008
    Location
    Saskatchewan, Canada
    Posts
    462

    Default

    Quote Originally Posted by DanLamb View Post
    Java doesn't add much overhead.
    That entirely depends on how you process the data. Load gigabytes into an array and you'll probably be fine. Load gigablytes into an array of Byte objects, and you could find it takes 10x or more RAM than you thought you were going to need, because that becomes an array of pointers to allocated objects.

  5. #35
    Join Date
    Feb 2013
    Posts
    233

    Default

    Quote Originally Posted by movieman View Post
    That entirely depends on how you process the data. Load gigabytes into an array and you'll probably be fine. Load gigablytes into an array of Byte objects, and you could find it takes 10x or more RAM than you thought you were going to need, because that becomes an array of pointers to allocated objects.
    Sure, Java lets you write inefficient code. No language is idiot proof. If you use a totally inappropriate data structure you can get terrible results.

  6. #36
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote Originally Posted by DanLamb View Post
    When http://benchmarksgame.alioth.debian.org/ was alive, C/C++ generally ran the fastest, Java behind that, C#/MS .NET behind that, and Mono was much slower than MS.NET.
    First of all, the benchmarks are different, and probably you understood that what I stated it was: "in some cases".

    I am working to an (non conforming) implementation that rewrites CIL into C++. I can say that 1:1 translation from CIL operations to C++ (using smart pointers), makes C++ code to be 16x times slower than .Net (ver 4.5). If an optimizer is applied over C++ inefficiencies you can get like 20-30% faster with C++.

    [1] http://coderefractor.blogspot.com/20...c-be-fast.html
    [2] http://coderefractor.blogspot.com/20...very-fast.html

    This is my analysis on the subject, so I can give to you some reasons this is the case, but I want to make sure that you understand that I am impartial in the review. In fact, if you read the first review, I advertised Java at least for performance (I don't like the language, but the runtime is decent... it will be even more after Java 9 when probably they will succeed to split the runtime using Jigsaw).

    Quote Originally Posted by DanLamb View Post
    citations? I'm skeptical of this.

    Beyond the speed, those kinds of porting layers often add a lot of unwanted complexity to the application development stack. They add extra layers that have be debugged through in the case of problems.
    Here are some citations:
    [1] http://docs.xamarin.com/guides/ios/a...s/compilation/
    [2] http://www.mono-project.com/Mono:Run...mentation:LLVM

    It looks to me that you consider that Mono is an emulator of .Net or something of this sort. Mono has it's own compiler that reads IL, "evaluates it" and generates at the end native code. If the optimizer runs well it should generate fairly good code. Using the default Mono optimizer (named Mini) you will not get highly performant code. But you have either to add an extra flag (-O=all) or change the optimizer (using LLVM, the backend optimizer used into C++ compilers in LLVM world) so you can get fairly good code.

    The memory part as it was told, is just a Java issue, not necessarily a .Net one, just to make clear to you: adding a 1 byte variable that is a stack/value data to a List in C#, should add 1 byte as memory consumption (a List is as both in Java and C# has some capacity that is extended when a threshold is hit, sometimes the addition is zero, sometimes is bigger), but when in Java is 16 bytes: all data in Java is 8 byte rounded and you have the reference associated data + 1 byte itself (+7 bytes for padding). Given this, the extra layers you seem to talk are mostly in Java world.

    A very simple comparison in memory consumption is running for real applications: opening the same project (CodeRefractor) inside:
    - Xamarin Studio 4.2.1 - a SharpDevelop ported to Gtk#: 108 936 K
    - SharpDevelop 4.4 : 87 924 K
    - Visual Studio Express 2013: 175 584K
    In fact SharpDevelop is using WPF/WinForms only, XS is a mix of C controls (GTK#) and C# and Visual Studio is mostly C++ with some C# interoperability.

    Maybe you can explain what you mean with "those kinds of porting layers often add a lot of unwanted complexity". You mean things like WPF? Xml, or things like that? In fact I think is just the opposite: having a framework makes you to not make the same mistake twice. The unwanted complexity is inside every library doing heavy stuff: data binding, xml processing, internationalization. Making it by your own will always make it harder to fix and debug, or maybe I'm missing your point.

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

    Default

    Later:
    Quote Originally Posted by DanLamb View Post
    (...)C# has a zillion technical problems, major ugly technical problems, but beyond those, it's not a platform-agnostic, general purpose language. It's an integration langauge for Microsoft tech stacks. If you don't want a Microosft centric tech stack, C# and .NET usually doesn't make sense.
    Of course what you're saying and implying is wrong at many levels. It made sense when it was made: it was intended to be the best way to develop Windows applications, but by extension if it was made the best way to develop applications for clients/enterprise, it may work well for different operating systems. Even more, most of the CPUs were weaker than 1 GHz when .Net was made, and today we have in every (smart)phone more MHz (GHz) than the desktops of that time.

    Is C# platform agnostic? It was from the day one: Rotor .Net implementation was working on BigEndinan/PowerPC/OS X, and Micro .Net was running on embedded (albeit on an interpreter). Taking Mono as running on many more platforms: Linux, iOS, Android, NaCl, makes that C# to be even more platform agnostic. In comparison the CIL is more platform agnostic than is JVM: JVM does not run in iOS, on Android the bytecodes are different (albeit are bootstrapped from the original JVM bytecodes).

    The single "major" detail that .Net offers and Mono doesn't are regarding COM related (which is to be expected, yet there is no problem, as CORBA in Java or any similar Java implementations are not JVM agnostic), although you can run .Net remoting with .Net host and Mono client (or vice-versa), and C++/CLI parts which are extensions that are not related with C# in itself.

    F# is a great language, and I don't want to make it any less valuable this part, also Scala (or Kotlin), but I think that every time when Linux loses a platform (like Mono, Adobe AIR), or a runtime it loses: choice, applications and eventually is a reason for people to not run Linux at their home. This is why we need Qt as much as Java as much as Mono. I love OpenRA (try it, is it a fun game), and is my distro will remove Mono, I will have to install other distro.

    Probably you know/noticed: Steam on Windows is .Net based, and no user is complaining on this (and they shouldn't). If they later would use Mono as their Linux client, will you remove all your Steam library because of it?

  8. #38
    Join Date
    Feb 2013
    Posts
    233

    Default

    Quote Originally Posted by ciplogic View Post
    I can say that 1:1 translation from CIL operations to C++ (using smart pointers), makes C++ code to be 16x times slower than .Net (ver 4.5).
    I believe your point that you _can_ make C++ code that runs poorly. You _can_ make any language or toolset run poorly. That's usually not very meaningful. What's usually relevant is comparing code normally written toolset A vs B or at comparing reasonably optimized code with A vs B.

    the blog post you linked said gcc was the fastest, then Java, then .NET, and MinGW the slowest... This isn't consistent with your assertion.

    Quote Originally Posted by ciplogic View Post
    The memory part as it was told, is just a Java issue, not necessarily a .Net one, just to make clear to you: adding a 1 byte variable that is a stack/value data to a List in C#, should add 1 byte as memory consumption (a List is as both in Java and C# has some capacity that is extended when a threshold is hit, sometimes the addition is zero, sometimes is bigger), but when in Java is 16 bytes: all data in Java is 8 byte rounded and you have the reference associated data + 1 byte itself (+7 bytes for padding). Given this, the extra layers you seem to talk are mostly in Java world.
    For language debates, you can write a large ArrayList<Integer> or ArrayList<Byte> in Java to demonstrate a massive amount of Object boxing memory overhead.

    Of course, in real life, a Java developer would just use int[] or byte[] instead and there's no boxing overhead and almost zero memory overhead at all. The ArrayList<Byte> example is true in that Java _does_ let you write bad code, and Java really does have a flaw in that it requires boxing overhead with generics for pre Java 1.4 compatibility reasons, but it's dishonest in that that isn't a realistic scenario.

    Additionally, Scala offers Array[Int] with no boxing overhead and no performance overhead. Additionally, it doesn't even have a separate legacy array syntax with separate casting rules, so it's more elegant in that sense as well.

    Additionally, even in C#, int[] often outperforms List<int>, so there is still the confusion and complexity there too:
    http://www.dotnetperls.com/array-memory

    Quote Originally Posted by ciplogic View Post
    Maybe you can explain what you mean with "those kinds of porting layers often add a lot of unwanted complexity". You mean things like WPF? Xml, or things like that? In fact I think is just the opposite: having a framework makes you to not make the same mistake twice. The unwanted complexity is inside every library doing heavy stuff: data binding, xml processing, internationalization.
    No, a framework or library is fine.

    But iOS development and all the tools and libs are really designed in an extremely Apple-centric Objective-C centric world. Using a tool that lets you write in a completely different language with either some type of cross compilation or micro VM adds extra complexity.

  9. #39
    Join Date
    Feb 2013
    Posts
    233

    Default

    Quote Originally Posted by ciplogic View Post
    Is C# platform agnostic? It was from the day one: Rotor .Net implementation was working on BigEndinan/PowerPC/OS X, and Micro .Net was running on embedded (albeit on an interpreter). Taking Mono as running on many more platforms: Linux, iOS, Android, NaCl, makes that C# to be even more platform agnostic. In comparison the CIL is more platform agnostic than is JVM: JVM does not run in iOS, on Android the bytecodes are different (albeit are bootstrapped from the original JVM bytecodes).
    Sure, C# is multi-platform. But it has been designed and influenced almost entirely by Microsoft, which is completely partisan vendor, which does make it less agnostic.

    Often, C# adds features strictly to accommodate another Microsoft product, for example. The overwhelmingly dominant IDE of choice is completely Windows only. LINQ's database features are mostly MS database specific. C# does run on other platforms, but it's not a vendor agnostic, politically neutral, tool.

    Java does run on iOS, btw, although I wouldn't advise it.

  10. #40
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote Originally Posted by DanLamb View Post
    I believe your point that you _can_ make C++ code that runs poorly. You _can_ make any language or toolset run poorly. That's usually not very meaningful. What's usually relevant is comparing code normally written toolset A vs B or at comparing reasonably optimized code with A vs B.

    the blog post you linked said gcc was the fastest, then Java, then .NET, and MinGW the slowest... This isn't consistent with your assertion.
    So let's clarify: MSIL/CIL describes some operations, like additions, loops, etc. If you translate them one to one into C++ "as is" you will get 16x slowdown. I can recommend to write some code in C#, and use CodeRefractor at level zero of optimizations to see what I mean. Probably it doesn't worth the hassle, but this is what is the statement based on.

    What you see here when GCC gets better is the code after you get these operations written in an intermediate format, applied optimizations and after that this code is given to a C++ compiler to optimize it more. Just after somewhat advanced optimizations like a lot of propagation optimizations, loop invariant code motion, and escape analysis, you can get that C++ to perform faster than .Net, but even so, you cannot get more than 20-30%. (you can get for specific cases, "happy cases").


    Quote Originally Posted by DanLamb View Post
    (...) (you describe clearly that is a boxing overhead)

    Additionally, even in C#, int[] often outperforms List<int>, so there is still the confusion and complexity there too:
    http://www.dotnetperls.com/array-memory
    (...)
    No, a framework or library is fine.

    But iOS development and all the tools and libs are really designed in an extremely Apple-centric Objective-C centric world. Using a tool that lets you write in a completely different language with either some type of cross compilation or micro VM adds extra complexity.
    I agree and I know what you mean. First of all let's clarify: this doesn't make a person writing bad code to not have a more code usage. The "round of 8 bytes" of every data set and boxing make Java to consume much more than the dataset you want to represent. C# doesn't need this and this is a good thing.

    Also, even you state that List<int> is slower than int[], which happens to be true, but is really marginal: the downspeed is in bounds checking and some extra data set to not make useless reaallocations inside the List structure. But in the same time it is not 10x more memory wasteful (like Java) and it doesn't need to have Hotspot to mitigate a lot of casts that are needed because of boxing.

    In fact I don't know any real benchmark that using List<T> you will get such of a big overhead (compared with array) as is in Java world: both performance wise or Java wise.

    Quote Originally Posted by DanLamb View Post
    Sure, C# is multi-platform. But it has been designed and influenced almost entirely by Microsoft, which is completely partisan vendor, which does make it less agnostic.

    Often, C# adds features strictly to accommodate another Microsoft product, for example. The overwhelmingly dominant IDE of choice is completely Windows only. LINQ's database features are mostly MS database specific. C# does run on other platforms, but it's not a vendor agnostic, politically neutral, tool.

    Java does run on iOS, btw, although I wouldn't advise it.
    It could be as you say, but it isn't in practice.

    C++ was probably made for describing business logic, and metaprogramming and was targetted for Unix development. This doesn't make C++ to not be very good for other environments (including Windows).

    In comparison, C# and Linq/database features are not related. Linq can be used from Boo, VB.Net, or any .Net language with a decent support of lambdas. It could be written in C# (which it is) but it doesn't relate with the fact that Linq (as technology) to be Windows centric. I use Linq day by day, and I don't target Windows or Sql server. Even I do programming on Windows (let's say), Linq can be used against Xmls, collections (arrays, List<T>), etc. which have no relation with the support of C#. Is like COM described earlier: is a .Net feature and the minimal C# support that it has for COM, or for enums to map WinAPI classes, it make it capable to map also C structs from GTK+, I don't see why it couldn't.

    In fact on the face value, PInvoke was more clean than anything Java dreamed on and it was made cross platform in the first iterations of Mono. There are demos in 2008 taking WinForms applications from Windows and run them in Mono/WinForms on Linux with no code change. This doesn't happen with any Dalvik application which you run them on desktop. Isn't it? Java 7 was announced less than a week ago as supported by Dalvik, when async/await support (VS 2012 feature, VS launched in October 2012) was ready as for start of 2013 in the master branch in Mono. So the "VM differences" as for me hold less water than comparing with Java world, isn't it?

Posting Permissions

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