Announcement

Collapse
No announcement yet.

Mono 2.8 Is Out With C# 4.0, Better Performance

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

  • movieman
    replied
    Originally posted by BlackStar View Post
    Fair enough but COME ON, Gnome is *not* pushing Mono. That's ridiculous!
    If a Mono application is part of the offical Gnome release, how can Gnome not be pushing Mono? I wouldn't have Mono installed on my PC at all if it didn't come with Gnome; I'm guessing there's probably some magic I can do to uninstall the Mono-reliant parts while keeping the rest but now it's installed there's not much point spending the time to figure that out.

    Leave a comment:


  • pingufunkybeat
    replied
    Still, with the number of people using Banshee and F-Spot and the like, it would suck really hard for them if those things got killed or went proprietary.

    And screw the edit window. It's 5 seconds, not 1 minute. If Michael does not want people to post here, he should just say so.

    Leave a comment:


  • pingufunkybeat
    replied
    Yeah, the connection of GNOME to Mono is unfortunate, but it's not fair to claim that GNOME is pushing Mono. There are many people in there who value software freedom, after all.

    Leave a comment:


  • BlackStar
    replied
    That's why DEPENDING on closed technology is a no-no for a system with so many powerful enemies. This is the reason why RMS raised hell over Qt back in the day, and why he has rallied against Java for so many years. It's an irony of fate that GNOME (which is a part of GNU) is pushing Mono now.
    Fair enough but COME ON, Gnome is *not* pushing Mono. That's ridiculous!


    Currently the only application written with the Mono bindings is the notetaking application Tomboy which has been part of GNOME since version 2.16 released in 2006. Tomboy will of course continue to be available in GNOME 3.0, but no component introduced explicitly in GNOME 3.0 will depend on Mono - GNOME Shell is written in C and Javascript, Zeitgeist and the GNOME Activity Journal use Python. And by the way, you can safely remove Tomboy if you don't like it. Alternatively Gnote can be used which is a port of Tomboy to C++. Other Mono based applications like F-Spot and Banshee are not officially part of the GNOME release and have alternatives such as Shotwell, Rhythmbox and others.
    Emphasis mine. A single application with a readily-available substitute.

    Leave a comment:


  • pingufunkybeat
    replied
    Originally posted by BlackStar View Post
    That's no different from the FAT patents. I acknowledge the danger but I am forced to ignore it - as are all software developers today. If worse comes to worst, we will adapt and survive, as we always have.
    Yes, but if you start needing a license for FAT, I can simply reformat all the drives using FAT and I'm done with it. A bit of a nuissance when dealing with USB sticks, but nothing would change for my everyday work. Any link with FAT can be removed by every Linux distribution by simply recompiling the kernel.

    If half of your desktop depends on Mono, it will be quite a hit if you have to give up on all that software and/or rewrite it in C.

    That's why DEPENDING on closed technology is a no-no for a system with so many powerful enemies. This is the reason why RMS raised hell over Qt back in the day, and why he has rallied against Java for so many years. It's an irony of fate that GNOME (which is a part of GNU) is pushing Mono now.

    Leave a comment:


  • BlackStar
    replied
    Originally posted by makomk View Post
    Ah, I beg its pardon, I was confusing the patent I actually found with what I was looking for at the time. The actual patent is rather broader - it covers any use of delegates and events in .Net that complies with Microsoft's coding style (which requires them to take exactly two arguments: the event source and a package of parameters for the event). This still affects Gtk#, though.
    Ouch, this just goes to show how broken the patent system is. This patent shouldn't have been granted in the first place, it's way too broad.

    Hopefully, though I'm pretty sure it's been scheduled to replace the old one imminently for years.
    Yes, they started working on this a few years bug but only ramped up after 2.4. It's going to be the default in 3.0 around Jan/Feb or so. Finally!

    It's not why they're suing, but there's no reason they couldn't sue Mono too using the same patents. The only Java-specific patent is the security model one (which isn't actually used on Android and is only there for compatibility); the rest are generic VM patents. Dalvik is very much like the CLR in that it's a register-based VM, unlike the stack-based JVM. If they can stretch the patents widely enough to encompass Dalvik...
    Which, again, goes to show how broken the patent system is. Google claims that those patents aren't valid anyway - we'll see how that works out in the end.

    In other words, you either have to put in a huge amount of developer work to optimise stuff that shouldn't need optimising - or you can skip that, buy Windows and run your software on a decent .Net implementation for less overall cost. This isn't just hypothetical; I've seen an open source C# project (OpenSim) end up having to do this. sgen should hopefully reduce this issue in the future, but it's still not considered production ready.
    Huge amount? No, not at all: Value types are built into C# and a memory pool can be implemented in ~50 lines of code (and probably less in Python).

    Note that these optimizations are equally valid in C or C++ if you care about performance or memory fragmentation - only there you don't have a GC to fall back on, so everything else is much more painful to implement.

    Originally posted by kraftman
    Last time I said mono garbage collector sucks a lot you didn't agree and you said something like it's one of the best gc, but now they're replacing it. Funny. :>
    You need to refresh your memory: Mono is currently using Boehm GC which is one of the best collectors written in C++. Saying that it sucks is preposterous.

    Novell has now create a new GC that performs better for Mono, but only after tons of effort. This is no small feat and it doesn't mean that Boehm sucks.

    Originally posted by pingufunkybeat
    You will have to worry if your software starts costing money to run in the future. Like, if everyone distributing Mono needs to pay a patent license.
    That's no different from the FAT patents. I acknowledge the danger but I am forced to ignore it - as are all software developers today. If worse comes to worst, we will adapt and survive, as we always have.

    Leave a comment:


  • pingufunkybeat
    replied
    Originally posted by makomk View Post
    In other words, you either have to put in a huge amount of developer work to optimise stuff that shouldn't need optimising - or you can skip that, buy Windows and run your software on a decent .Net implementation for less overall cost. This isn't just hypothetical; I've seen an open source C# project (OpenSim) end up having to do this.
    And this is the whole reason why .Net exists

    Originally posted by BlackStar
    *You* don't have to worry. Novell does.
    You will have to worry if your software starts costing money to run in the future. Like, if everyone distributing Mono needs to pay a patent license.

    See, Microsoft is in the business of writing and selling software. If they find out to sell you Mono, they will.

    Leave a comment:


  • kraftman
    replied
    Originally posted by BlackStar View Post
    I've been testing the new GC and its performance is pretty good. It will replace the old one in a few months.
    Last time I said mono garbage collector sucks a lot you didn't agree and you said something like it's one of the best gc, but now they're replacing it. Funny. :>

    Leave a comment:


  • makomk
    replied
    Originally posted by BlackStar View Post
    Linky, please.
    Ah, I beg its pardon, I was confusing the patent I actually found with what I was looking for at the time. The actual patent is rather broader - it covers any use of delegates and events in .Net that complies with Microsoft's coding style (which requires them to take exactly two arguments: the event source and a package of parameters for the event). This still affects Gtk#, though.

    Originally posted by BlackStar View Post
    I've been testing the new GC and its performance is pretty good. It will replace the old one in a few months.
    Hopefully, though I'm pretty sure it's been scheduled to replace the old one imminently for years.

    Originally posted by BlackStar View Post
    Nope, sorry. Oracle is not suing Google because Dalvik has anything in common with .Net. They are suing because Java is much less open than they would like you to believe.
    It's not why they're suing, but there's no reason they couldn't sue Mono too using the same patents. The only Java-specific patent is the security model one (which isn't actually used on Android and is only there for compatibility); the rest are generic VM patents. Dalvik is very much like the CLR in that it's a register-based VM, unlike the stack-based JVM. If they can stretch the patents widely enough to encompass Dalvik...

    Originally posted by BlackStar View Post
    You can certainly construct corner cases where Python performs better than Mono, but Mono tends to perform significantly better in the well-optimized case (value types and/or memory pooling to avoid runtime allocations). Using sgen, you can also get away with some pretty crazy stuff, like hundreds of gen-0 allocations.
    In other words, you either have to put in a huge amount of developer work to optimise stuff that shouldn't need optimising - or you can skip that, buy Windows and run your software on a decent .Net implementation for less overall cost. This isn't just hypothetical; I've seen an open source C# project (OpenSim) end up having to do this. sgen should hopefully reduce this issue in the future, but it's still not considered production ready.

    Leave a comment:


  • BlackStar
    replied
    Originally posted by makomk View Post
    Actually, it turns out that Gtk# infringes on at least one Microsoft patent that's cleverly designed to entrap any GUI framework based on .Net that didn't carefully avoid it.
    Linky, please.

    Oh, and Mono's garbage collector? It sucks. It's far worse than Java's, even if you go back and use Java versions from the mid-90s. The new "--gc=sgen" option should bring it closer to the JVM in performance, but it's still experimental.
    I've been testing the new GC and its performance is pretty good. It will replace the old one in a few months.

    Funny you should say that. It turns out that the Dalvik VM that Oracle are suing Google over has far more in common with .Net and Mono than it does with the JVM.
    Nope, sorry. Oracle is not suing Google because Dalvik has anything in common with .Net. They are suing because Java is much less open than they would like you to believe.

    It is impossible to create a valid, open-source Java implementation. Look up the bitter history behind Apache, Sun and project Harmony, if you don't believe me. Sun (and now Oracle) just barely tolerates OpenJDK and makes it almost completely impossible to re-implement the spec independently.

    Check this blog for an in-depth analysis of the situation: http://www.jroller.com/scolebourne/

    So if you use Mono, not only do you have to worry about Microsoft's patents on .Net, you have to worry about Oracle's patents on Java too! (Whereas if you use the JVM, neither of these is an issue - there's a patent license for Oracle's patents and Java predates Microsoft's patents.)
    *You* don't have to worry. Novell does.

    Those patents are likely to apply equally well to any modern VM. The only reasonable course of action is to ignore them completely.

    Depends on how exactly your app is affected by the garbage collection penalty, I think. For software that needs to avoid the latency created by periodic GC, creates a lot of short-lived objects, or worse still does both, Mono could actually be worse than Python.
    You can certainly construct corner cases where Python performs better than Mono, but Mono tends to perform significantly better in the well-optimized case (value types and/or memory pooling to avoid runtime allocations). Using sgen, you can also get away with some pretty crazy stuff, like hundreds of gen-0 allocations.

    But memory latency is only part of the picture and stuff like threading do favor Mono a lot.

    Leave a comment:

Working...
X