Announcement

Collapse
No announcement yet.

Mono Developers Renew Their Love For Microsoft

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    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.

    Comment


    • #32
      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.

      Comment


      • #33
        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.

        Comment


        • #34
          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).

          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.

          Comment


          • #35
            Later:
            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?

            Comment


            • #36
              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.

              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:
              Test the memory usage of arrays and Lists. Arrays can be used in a more efficient way.


              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.

              Comment


              • #37
                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.

                Comment


                • #38
                  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").


                  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:
                  Test the memory usage of arrays and Lists. Arrays can be used in a more efficient way.

                  (...)
                  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.

                  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?

                  Comment


                  • #39
                    Originally posted by ciplogic View Post
                    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").
                    This sounds reasonable.

                    Originally posted by ciplogic View Post
                    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.
                    ...
                    But in the same time [C#] is not 10x more memory wasteful (like Java)
                    Claiming Java is 10x more memory wasteful is ridiculous. Even you don't believe that. The Mono guys purposefully design benchmarks like that, but that is deceptive in that you won't see anything so dramatic in more normal world scenarios. JVM has larger fixed memory overhead so you see a large percentage difference on a "hello world" program. But when you start loading actual data into memory, you won't see a dramatic memory difference like that.

                    If you load a byte[] in Java or a Array[Byte] in Scala, there is very close to zero overhead. I already agreed that it is a good thing that C# generics works with value types without a boxing overhead. You are just blowing that minor benefit out of proportion. Scala basically gives you the same benefit, where you don't have boxing overhead on somethign like Array[Byte].

                    Originally posted by ciplogic View Post
                    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#.
                    Sure, the in-memory LINQ functionality isn't permanently bound to C# or Microsoft and it could be potentially adopted by other non-Microsoft ecosystems. And if it makes sense to do so, it should adopted, regardless of passed history and politics.

                    However, LINQ isn't an originator and isn't unique in it's functionality. Scala natively provdes the functionality of in-memory LINQ, long before LINQ ever existed, and does it more seamlessly than LINQ where it's not this disjoint syntax separate from the rest of the language. Scala has arguably better technology, it's lacking the trademarked brand name, and Microsoft marketing, and all that, which isn't important to many people.

                    Originally posted by ciplogic View Post
                    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).
                    Same argument. If C# is technologically beneficial in other platforms, it can and should be adopted for technical reasons, regardless of whatever political issues have plagued that past.

                    I agree with this sentiment, but C# isn't even good technology. It has minor advantages over Java like reified generics and lack of generics related boxing (which Scala fixes) and native unsigned primitives (which isn't hard to work around). But C# is _far_ behind a more modern language like Scala. To quote myself in response to someone asking "Can you provide examples of legacy hacks and how Scala, Haskell and F# are actually better than languages like C# or Java?":

                    Originally posted by DanLamb View Post
                    Java has this horrific convention of writing getters/setters everywhere because you can't change a variable to a function without breaking source + binary compatability.

                    C# automates this with properties, but in some ways it's even worse. There is no reason C# should have both mostly redundant language constructs of variables/fields and properties. You can have a local variable, but not a local property. You can have an instance variable, but generally you can always replace it with an instance property. "readonly" works on instance/class fields, but not properties and not local variables, and it's different from const. If you want a read only property, that uses a completely separate syntax. Props can be overridden, variables can not. The "var" type inference mechanism works with local variables, but not instance variables or class variables or properties or function return values. What a complete chaotic mess!!

                    Scala has var (read/write) and val (read only) and that's it. Whether you use them as local var/vals, instance var/vals, or singleton var/vals, they work the same and use the same syntax and don't need a myriad of weird rules and legacy syntaxes and keywords. Type inference works in all cases and also works similarly with function return types.

                    null. Scala/F# support null for Java/C# interop, but native Scala/F# otherwise doesn't use null at all. Option is a much better solution than null. C#'s nullable types are a much weaker partial solution, which is why Microsoft's newer F# uses Option.

                    Arrays. C#/Java both started with arrays and added generics as a separate system later. Arrays should use the generics syntax. And they should use the same casting rules. Scala does, Java/C# do not. Java/C# have arrays that can downcast (covariance) which is a mistake that they can't fix for legacy reasons as you can write code that compiles but fails at runtime.

                    I mentioned LINQ. Scala does all the in-memory stuff that LINQ does in the core language where C# has this separate disjoint syntax bolted on.

                    Ternary operator. C/Java/C#/JavaScript use the ternary operator, because they don't have "if" expressions that return a value like Ruby, Scala, or most other modern languages. The ternary operator also doesn't extend cleanly to multiple else if conditions or multi-line expressions like an "if" expression.

                    Partial functions. C had switch/case statements which was carried over into JavaScript/C#/Java. This is similar to a mathematical partial function (a function defined for only some range of inputs like a logarithm function). Scala basically replaces the C-era switch/case with native partial function support.

                    Native support for tuples is extremely useful.

                    Native support for pattern matching is huge. This dove tails with Option btw.

                    Native support for currying. You can approximate it with C#/Java, but it's nice to have native support.

                    Look at Scala's parser combinator library for an example of some useful, practical code that really showcases the conciseness and elegance of Scala in a way that would be far more bulky in Java/C#.
                    Originally posted by ciplogic View Post
                    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.
                    It's much worse than that. Dalvik doesn't support the major Java 7 enhancements, specificially the NIO.2 library which Google helped write, and Invoke Dynamic byte code. The Android toolset just supports soms superficial petty Java 7 syntax improvements, which is barely better than nothing.

                    The dated Java support is almost surely due to the legal battles with Oracle. I presume Google has been working to phase out Java and replace with something else, and that just hasn't been ready to announce.

                    IMO, there are much better languages than Java: Scala, Haskell, Ocaml, Rust, etc. But worse than Java, is using a completely out of date, legacy version of the language that is incompatabile with much of the more recent developments.

                    I am not downplaying this disaster, but are you just gloating? I never claimed Mono had this problem.

                    The async issue seems to be a tangent. Scala has super nice syntax for dealing with async programming, and I believe that can compile to Dalvik binaries.

                    Comment


                    • #40
                      Originally posted by DanLamb View Post
                      Claiming Java is 10x more memory wasteful is ridiculous. Even you don't believe that. The Mono guys purposefully design benchmarks like that, but that is deceptive in that you won't see anything so dramatic in more normal world scenarios. JVM has larger fixed memory overhead so you see a large percentage difference on a "hello world" program. But when you start loading actual data into memory, you won't see a dramatic memory difference like that.
                      (...)
                      Same argument. If C# is technologically beneficial in other platforms, it can and should be adopted for technical reasons, regardless of whatever political issues have plagued that past.

                      I agree with this sentiment, but C# isn't even good technology. It has minor advantages over Java like reified generics and lack of generics related boxing (which Scala fixes) and native unsigned primitives (which isn't hard to work around). But C# is _far_ behind a more modern language like Scala. To quote myself in response to someone asking "Can you provide examples of legacy hacks and how Scala, Haskell and F# are actually better than languages like C# or Java?":
                      (...)
                      I am not downplaying this disaster, but are you just gloating? I never claimed Mono had this problem.
                      You claimed two things here:
                      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.
                      Given this "impartial view", I think is appropriate to give this kind of responses. And the numbers are not given by a Mono enthusiast (like myself), but by Java guys like an expert working on Twitter claims that JVM is huge on memory. Taking it from his slides:
                      - smallest object: 16 bytes
                      - (empty) array of bytes: 24 bytes
                      - class A {
                      byte x;
                      }
                      class B extends A {
                      byte y;
                      }
                      new A(): 24 bytes, new B(): 32 bytes
                      -
                      class C {
                      Object obj = new Object();
                      }
                      new C() = 40 bytes
                      - Guava MapMaker.makeMap() takes 2272 bytes!
                      MapMaker.concurrencyLevel(1).makeMap() - 352 bytes

                      - Corba like Thrift can also be heavy (Thrift is a Twitter project): "It adds between 52 and 72 bytes of overhead per object."

                      So, what remained for me to "prove" are the following:
                      - Mono is not just a poor's man CLR (or .Net). Because performance wise (as was quoted) gives the same optimizations (given you pick LLVM which is not default) as a C++ runtime
                      - C# is not MS centric (it runs just well on Mono and with not impaired functionality)
                      - C# it makes sense on some platforms which are not Windows (like Linux, or iOS or Android) maybe even more than Java. The reason: at the end is created a native binary that is executed so it can run faster than let's say... Java on some devices (like Android and/or iOS). I know about RoboVM which is pre-alpha (like my tool too) and it can compile some Java apps on iOS

                      What about C# vs Scala. I don't know. I cannot comment (too much), because as much as you say, it looks to me that Scala has some ups and downs. Scala looks to me a more OOP that tries to describe as much as possible functional features, when C# added them later (via Linq). Maybe is not a clean syntax, but feature wise on practical side it looks that in some parts C# is clearly superior:
                      - PInvoke and native platform integration working with any OS (also to falsify your statement that C# is not platform agnostic)
                      - dynamic object: you can do dynamic programming. The syntax is worse than Mirah, or IronRuby or IronPython, of course, but you can do it fairly natural and the generated code is fast too.
                      - async/await is more than an actors or task based programming, and is supported on Mono (which is the topic of this article), not because it offers something more (which it does), but because the whole states are written by the compiler. This is why is so good experience running Windows Phones or modern WPF applications

                      Comment

                      Working...
                      X