Announcement

Collapse
No announcement yet.

Mono 2.6 Released, Supports LLVM Generation

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

  • #81
    Originally posted by BlackStar View Post
    Hint: the plural of anecdotes is not data.
    Oh so you are aware. Keep that in mind for your next post then.

    Have you found any .net or java apps that compare to QT apps in performance? Nope, didn't think so. Funny that you were defending this position (which I was disputing) and seem to have now conceeded it.

    Do you know which language is used for Paint.Net filters? That's right, it's C#. Check here or, for a concrete example, here.
    I would have assumed so for a C# app.

    Paint.Net has been moving away from GDI+ due to performance issues (source).
    That - AFAICS is referencing only font rendering and the text tool and the fact that new builds are using GDI over GDI+ for it. This is actually harming your arguement even further.

    Even if it didn't use GDI+, it would have used plain GDI, WPF or maybe D3D/OpenGL - there's no other way to render to screen on win32.
    Again veering from the point - which is that in the case of paint.net the only example you have been able to come up with in 8 pages, relies on non .net code to reach even acceptable performance. I think it's safe to say that my original point that in the majority of cases it is significantly slower overall. I'm glad you are also conceeding this point.

    This argument that Paint.Net is using GDI+ so it's not a valid .Net app doesn't make any sense
    I never made that arguement (see previous quote & response)

    Yep here it is again, I have no doubt you're getting tired of me calling you out everytime but hopefully you'll stop misrepresting what I have said in future -

    Straw man: A straw man argument is an informal fallacy based on misrepresentation of an opponent's position.
    * Example

    Person A claims: Sunny days are good.
    Argument Person B: If all days were sunny, we'd never have rain, and without rain, we'd have famine and death. You are obviously wrong.
    Problem: B has falsely framed A's claim to imply that A says that only sunny days are good, and has argued against that assertion instead of the assertion A has made.



    - but then again neither does anything other you have written.
    As you avoided this the last time I will repeat it:

    "If you want a fair analysis you start with a neutral party. Remember the tobacco research that showed that smoking was good for your health? Yeah funded by tobacco companies....lets guess where his wages come from shall we. I do not know him as a person so I cannot judge how impartial he really is and I doubt you do either.
    I cannot believe I have to explain something this simple to you."

    If this makes no sense to you a discussion is something you should not be attempting and it is simply not worth responding to someone who cannot understand this.

    "From the inception intended to show C# in a positive light?" My, are you blinded by hatred.
    "You've been unable to provide a single, valid example and provided a "technical analysis" from an employee of the company who created the product on their company blog? Brilliant."

    That is not hatred, that is logic. Can you not see the context? Before the blog has even been written it is in a context of tremendous bias.

    "Critical thinking gives due consideration to the evidence, the context of judgment, the relevant criteria for making the judgment well, the applicable methods or techniques for forming the judgment, and the applicable theoretical constructs for understanding the problem and the question at hand. Critical thinking employs not only logic but broad intellectual criteria such as clarity, credibility, accuracy, precision, relevance, depth, breadth, significance and fairness."



    This is something most people learn in high school, explaining this time and again until you can understand it is getting awfully tiresome.

    It is obvious that you didn't even make the effort to read the technical analysis - the irony here is that it concludes that C++ is ultimately more efficient than C# (and explains exactly how, where and why).
    I had absolutely no need to. Your arguement was already defeated through logic. You can continue to drone on to yourself about how wonderfully efficient "managed code" (your words, not mine) is, but until there are real world examples where .net can come close to C/C++ you'll just be ridiculed. (See Krita vs Paint.net - even on windows if you like).

    I ask you directly, can *you* provide a valid technical examination of C++ versus C#? Unless you do at least that much, there's no point in continuing this discussion.
    4 Things:

    1) I see what you did there! You just moved the goalposts again, conceeding the point that there are no examples of where it can compare to well written C / C++ in real world scenarios and now only accepting a technical examination.

    2) The onus is on you to provide evidence (and real world examples) to support your wild claims. I am stating the status quo which is that .net is slower than C / C++ in nearly every instance for well written code. You have yet to prove otherwise. In fact in your later posts you _seem_ to by conceeding this also or at least distancing yourself from your own comments.

    3) I see so you've changed the arguement again from QT performance vs Mono/.Net performance to C# vs C++.

    4) What exactly are you asking for here? You seriously want me to go through every performance delta in every use case when you haven't even bothered to provide anything to back up your claims? are you kidding?

    Provide your own robust performance data of C++/QT vs C#/Mono in real world scenarios (any platform, both if you wish) to back up your wild claims or don't bother. Asking me to "disprove" your ridiculous claims is logically flawed. Oh, as you might be able to tell, I'm a QT developer. The original reason I continued responding to you was because your claims in reference to QT being so "bloated" and "inefficient" (show me something cross platform that is less so?) were ridiculous - especially in the context - in comparison to mono/.net which you seemed to have conceeded also. In light of you conceeding each point you originally made I believe the discussion is over.

    Hint: reiterating that .Net is slow without proof won't make your point valid.
    No but listing case after case where it is slow and user after user responding to you backing that up does make the point valid. Especially when you have come up with nothing and no one to back up your point. By your own admission even your own sources betray your arguement.
    Last edited by Hoodlum; 18 December 2009, 09:07 AM.

    Comment


    • #82
      Originally posted by Hoodlum View Post
      Originally posted by BlackStar
      Hint: the plural of anecdotes is not data.
      Oh so you are aware. Keep that in mind for your next post then.

      Have you found any .net or java apps that compare to QT apps in performance? Nope, didn't think so.
      Yet you keep asking for anecdotes. Does cognitive dissonance ring a bell?

      The rest of your post keeps repeating the same old tired bullshit. Do you have any technical data to backup your claim?
      Last edited by BlackStar; 18 December 2009, 09:15 AM.

      Comment


      • #83
        Originally posted by BlackStar View Post
        You can use a memory pool in .Net too and avoid GC overhead. What's your point?
        The point was that you can have just as fast allocations with explicit memory management, by employing the same method of managing your own custom heap. However by not using automatic garbage collecting it will be even faster since automatic garbage collecting adds lots of overhead.


        Originally posted by BlackStar View Post
        You are downplaying the issue of memory fragmentation. This is a real problem in non-trivial applications and the potential solutions are far from simple: use multiple heaps, use custom memory allocators, use memory pools. Each solution has its issues (non-portable, dangerous and non-generic, respectively) which become at least an order of magnitude more complex once you add a 3rd party library that isn't aware of your memory management strategy.

        All this pain for something that is a non-issue in managed environments.
        It's a non-issue in terms of usage, not a non-issue in terms of performance. You can't have it both ways, either ease of use or better performance. Which is what I've been saying all along.

        Originally posted by BlackStar View Post
        Anyway, I'm not making a blanket statement that .Net memory management is faster than anything you could do in native code, that's ridiculous. I'm saying that it has real performance advantages out of the box (again, faster allocations compared to default CRT allocators, less fragmentation).
        Again the faster allocations are a result of managing their own heap, which can be done just as easily without any garbage collection. Less memory fragmentation in this case does not improve performance, since it is due to the gc MOVING blocks of data around which is VERY expensive. The reason it does this defragmentation is NOT because of any speed benefits due to less memory fragmentation, but because it wants to keep the managed heap as small as possible. This is in turn because any memory held by the managed heap will be unavailable by the rest of the system (anything outside the VM).

        Comment


        • #84
          Originally posted by BlackStar View Post
          Yet you keep asking for anecdotes.
          So you cannot mention or provide a single example of any kind, which we could test? Thank you for clearing that up.

          Does cognitive dissonance ring a bell?
          Trying to analyse me because your arguement falls apart? Please.

          The rest of your post keeps repeating the same old tired bullshit.
          Like completely defeating any arguement you had? If you ignore it, it doesn't go away.

          Do you have any technical data to backup your claim?
          You made the claim about .net performance being acceptable, you then referenced how bloated qt was

          The burden of proof is on you to prove your claim.
          I do not have to disprove what you have "claimed" to be right. You have to prove your claim to have any credibility.

          I retorted with the status quo - that mono/.net apps perform badly in comparison to QT apps in an overwhelming majority of cases and especially in the case of significant applications. This is well known, widely experienced and immediately obvious - playing dumb does not make it any less obvious. Literally, pick *any* mono application on any platform for which there is a reasonably well written, equivalent, qt app and we can compare them.


          * This is a good place to start and provides an example for many different types of applications, feel free to use others - any example would be great:

          * Kate - Advanced Text editor for programmers
          * Kedit - A simple text editor with few features, similar to Windows' Notepad
          * KWrite - Text editor
          * DigiKam - Digital photo management
          * Gwenview - Image viewer
          * Kolourpaint - Small bitmap graphics editor (Very similar to MSPaint)
          * Krita - Bitmap graphics editor
          * Okular - Universal document viewer
          * KGet - Download manager
          * KMail - Email client
          * KMess - Instant messaging
          * Konversation - Dedicated IRC client
          * Konqueror - File manager and web browser
          * Kopete - Instant messaging
          * KTorrent - BitTorrent client
          * Akregator - RSS Feed reader
          * Rekonq - Lean web browser based on Webkit
          * Amarok - Audio player and music manager with numerous integrated features
          * JuK - Jukebox and music manager
          * K3b - CD and DVD burning application
          * Kaffeine - Multimedia player
          * Kdenlive - Video editor
          * Rosegarden - Digital audio workstation
          * KPresenter - Presentation application
          * KSpread - Spreadsheet
          * KWord - Word processor
          * KMyMoney - Personal finance manager
          * Kontact - Personal information manager and groupware
          * KOrganizer - Calendar and scheduling
          * Skrooge - Personal finances manager for KDE4
          * KDevelop - Integrated development environment for multiple languages.
          * BasKet Note Pads - Advanced multi-purpose note-taking application
          * Dolphin - File manager

          This is as easy as I can it make for you. I even had to provide a list of applications for you to attempt to make a point with. You have failed time and again to come up with a single example that backs up your claim.

          As you seem unable to hold a discussion, continually avoiding / misdirecting any statement that challenges what you have said (your last response to me being the perfect example, avoiding every point) all the while providing no evidence, no data and no examples there is not much point in continuing.

          Helpful hint: I don't think anyone is going to buy you trying to turn the burden of proof for your claims onto me

          Comment


          • #85
            Originally posted by Hoodlum View Post
            You made the claim about .net performance being acceptable, you then referenced how bloated qt was
            You have no technical arguments so you resort to making stuff up. Great!

            Go back and reread my original post on Qt, then read it once more so you understand it. Go on, I'm waiting.

            Since you seem to fail in reading comprehension, let me break my Qt-related argument down for you:
            1. cross-platform toolkits add bloat compared to using native APIs directly (utorrent and ktorrent measurements illustrate this nicely).
            2. due to #1, using Java or .Net as cross-platform toolkits means bloat, exactly like using Qt as a cross-platform toolkit.
            3. to reduce bloat, you have to get your hands dirty and use native, platform-specific APIs directly, no matter what language you use.

            Do you understand this part of the argument now? Do you disagree with this?

            The burden of proof is on you to prove your claim. I do not have to disprove what you have "claimed" to be right. You have to prove your claim to have any credibility.
            It is you who have made three ridiculous claims:
            1. Java and .Net are too bloated for mobile devices (source)
            2. Java and .Net are too bloated for the desktop (source)
            3. There are no fast .Net apps (source)

            All three claims are trivially simple to disprove:
            1. The vast majority of mobile applications is written in Java (for Android, Nokia, Samsung and most other mobile phones), .Net Compact (for Windows Mobile) and, more recently, Objective-C and Mono (for the iPhone).
            2. There are literally thousands of desktop applications written in Java and .Net or heavily relying on those techonologies: Eclipse, NetBeans, Visual Studio, MonoDevelop, SharpDevelop, Second Life, Sims 3, Unity3d, Paint.Net, Ati Control Center, Gnome Do, Banshee, Tomboy and every single XNA game.
            3. Second Life started using Mono in order to improve performance (source). Not to mention all those XNA games.

            Originally posted by Second Life wiki
            Mono for Second Life" refers to a simulator upgrade which can dramatically speed the running of scripts — especially calculation intensive ones.
            Do you understand that you have no argument here? You have made three ridiculously wrong statements and failed to provide any evidence to back them up.

            Edit: spelling.
            Last edited by BlackStar; 18 December 2009, 04:40 PM.

            Comment


            • #86
              Originally posted by BlackStar View Post
              ...2. There are literally thousands of desktop applications written in Java and .Net or heavily relying on those techonologies: Eclipse, NetBeans, Visual Studio, MonoDevelop, SharpDevelop, Second Life, Sims 3, Unity3d, Paint.Net, Ati Control Center, Gnome Do, Banshee, Tomboy and every single XNA game...
              That doesn't mean they are not bloated though or they wouldn't perform better if they were maiden with QT. Tomboy sucks and Vazu sucks for example (when we speak about performance though, not features). I have not used the others but from an end user experience, whenever I hear for a Desktop app that is written in Java or Mono, I run away.

              Comment


              • #87
                Originally posted by BlackStar View Post
                All three claims are trivially simple to disprove:
                1. The vast majority of mobile applications is written in Java (for Android, Nokia, Samsung and most other mobile phones), .Net Compact (for Windows Mobile) and, more recently, Objective-C and Mono (for the iPhone).
                2. There are literally thousands of desktop applications written in Java and .Net or heavily relying on those techonologies: Eclipse, NetBeans, Visual Studio, MonoDevelop, SharpDevelop, Second Life, Sims 3, Unity3d, Paint.Net, Ati Control Center, Gnome Do, Banshee, Tomboy and every single XNA game.
                3. Second Life started using Mono in order to improve performance (source). Not to mention all those XNA games.
                Trying not to take sides here.

                1. Very true.

                2. The thing is most of those apps you listed are thought of as being slow.
                a. Eclipse - slow
                b. NetBeans - that one actually ran OK for me
                c. VS - doesn't rely on .net, except for the 2010 beta which even MS has acknowledged has performance issues
                d. MonoDevelop/SharpDevelop - haven't used
                e. Second Life - just using it as a scripting language, not a desktop app that needs to remain responsive
                f. Sims 3 - haven't used
                g. Unity 3d - haven't used
                h. Paint.NET - seems ok, but i think they went to a lot of effort to make that true
                i. ATI CC - OK, but doesn't really do that much
                j. Gnome Do, Banshee, Tomboy - slow
                k. XNA - those run OK. A lot of the work is actually being done by unmanaged DirectX code that XNA just wraps around, but OK that's valid.

                3. See 2.e above. Weren't they using Python or some other language to do the scripts before, so when they said it brought a big speedup it was probably just the fact that they were going from an interpreted language to a JIT compiled one.

                Comment


                • #88
                  Originally posted by Apopas View Post
                  That doesn't mean they are not bloated though or they wouldn't perform better if they were maiden with QT. Tomboy sucks and Vazu sucks for example (when we speak about performance though, not features). I have not used the others but from an end user experience, whenever I hear for a Desktop app that is written in Java or Mono, I run away.
                  Let me fix that for you.

                  "That doesn't mean they are not bloated though or they wouldn't perform better if they were maiden with assembly. Office(*) sucks for example (when we speak about performance though, not features). I have not used the others but from an end user experience, whenever I hear for a Desktop app that is written in C or C++, I run away."

                  (*) compared to Lotus, of course, which was orginally written in assembly.

                  That's an argument someone might have made in favor of assembly 15 years ago. We all know how that turned out. :P

                  Originally posted by smitty3268
                  2. The thing is most of those apps you listed are thought of as being slow.
                  "Slow" without qualification is meaningless. Slow in what way? On what hardware? Compared to what?

                  For example, Gnome Do launches and runs fast here (Linux-on-a-8GB-USB-stick), so I don't know why you consider this slow. Tomboy and Banshee are relatively slow to launch, but run fine afterwards - in fact, I can't detect a speed difference between Rythmbox and Banshee in typical operations (importing folders, browsing albums, playing back music).

                  VS2008 seems to run plenty fast even on older hardware (I used to run it on a Pentium 4 with 1GB RAM at my previous job) and yes it does rely on .Net for several parts (its visual editors for example). It's true that VS2010 is being delayed due to performance issues, but it's also true that the new WPF-based editor can handle this without breaking a sweat (warning, your browser may die trying to open this file). That's better than the C++ editor in VS2008 and VS2005, for example.

                  In any case, the fact is that there are tons of desktop application written or relying on .Net and Java technologies, which discounts the notion that these technologies are too slow for the desktop.

                  e. Second Life - just using it as a scripting language, not a desktop app that needs to remain responsive
                  Since when do games not need to remain responsive? If anything, games have much harder performance requirements than desktop applications: fall below 30fps and you are toast! Desktop apps, in comparison, run idle for most of the time.

                  Maybe it's "just" a scripting language but according to this, "In today's Second Life, scripts are everywhere: from simple rotating objects to complicated vehicles, vendors, or attachments that respond to chat commands." To me, it sounds like Second Life is pretty much written as a bunch of scripts (aside from the server components and the core engine, I'd guess).

                  3. See 2.e above. Weren't they using Python or some other language to do the scripts before, so when they said it brought a big speedup it was probably just the fact that they were going from an interpreted language to a JIT compiled one.
                  As far as I know, they were using a custom, compiled scripting language called LSL. Their wiki seems to confirm this, but I don't know the details.

                  Edit: spelling and syntax. Again.
                  Last edited by BlackStar; 19 December 2009, 05:28 AM.

                  Comment


                  • #89
                    Originally posted by BlackStar View Post
                    Let me fix that for you.

                    "That doesn't mean they are not bloated though or they wouldn't perform better if they were maiden with assembly. Office(*) sucks for example (when we speak about performance though, not features). I have not used the others but from an end user experience, whenever I hear for a Desktop app that is written in C or C++, I run away."
                    So C++/assembly = C#/C++ in terms of performance and time a developer needs to complete a program? I highly doubt about that.

                    "Slow" without qualification is meaningless. Slow in what way? On what hardware? Compared to what?
                    In my Athlon64@3000+ with 1.5GB RAM and an optimazed Gentoo system are rather rather slow compared to the equivalent C and C++ applications and they use much more RAM. For that I choosed Transmission over Vazu at first place despite the wealth of features of the first one (the same for JDownlader and Tucan)
                    And again, performance must be seen from an end user experience, not from the developer's point of view. Is rather important your desktop to feel and be fast.

                    For example, Gnome Do launches and runs fast here (Linux-on-a-8GB-USB-stick), so I don't know why you consider this slow. Tomboy and Banshee are relatively slow to launch, but run fine afterwards
                    I do not care (as an end user). I want the apps I use to be light and fast from the start to the end, not only after they decide to run. That's why I study thousands of comparisons and benchmarks between CPUs before I buy one and that's why I don't want to digest my old PIII that still works like a charm without the bloated java and mono apps.
                    The fact that maybe is easier for developers to develop in C# rather than QT is their problem, not mine. When I judge the final products I won't think if they are written in that toolkit or with that language or how much time the poor developer needed to accomplish his task. I will count the seconds the apps need to run and the amount of RAM they use and if they suck compared to the other apps that means my Desktop experience fall apart which means in other words that the developer was egoist and didn;t think the customer/user at all.

                    Comment


                    • #90
                      Originally posted by Apopas View Post
                      So C++/assembly = C#/C++ in terms of performance and time a developer needs to complete a program? I highly doubt about that.
                      So, do you believe that ASM-> C++ entails a bigger drop in performance and dev time compared to C++ -> C# or a smaller drop? Why?

                      I do not care (as an end user). I want the apps I use to be light and fast from the start to the end, not only after they decide to run. That's why I study thousands of comparisons and benchmarks between CPUs before I buy one and that's why I don't want to digest my old PIII that still works like a charm without the bloated java and mono apps.
                      Commendable, but the vast majority of users don't choose applications like that. For example, KDE 4.x is more bloated than KDE 3.x, but almost everyone prefers the former over the latter (before someone takes issue with this again, I'm not saying KDE is bloated in absolute terms. As far as I'm concerned, it could be the most efficient DE ever conceived, but it's a fact that 4.x consumes more resources than 3.x).

                      This means that there are criteria other than pure performance at play. Which criteria? That's up to you to decide. You've picked raw performance (hence Gentoo and minimalist native apps like Transmission over Mac OS X and Vuze). Nothing wrong with that.

                      (For the record, I love Transmission but I also use Vuze (often both at the same time)).

                      The fact that maybe is easier for developers to develop in C# rather than QT is their problem, not mine. When I judge the final products I won't think if they are written in that toolkit or with that language or how much time the poor developer needed to accomplish his task. I will count the seconds the apps need to run and the amount of RAM they use and if they suck compared to the other apps that means my Desktop experience fall apart which means in other words that the developer was egoist and didn;t think the customer/user at all.
                      You display a strange sense of entitlement here. OSS developers don't owe you anything. They don't answer to you - they are free to use *their* technology of choice to develop the applications *they* like. You get to decide if you wish to use their applications or not (for technical, political or personal reasons) - you don't get to dictate their development methodologies, at least not directly.

                      Calling OSS developers egoists because they don't cater to *your* specific needs is flat out wrong.

                      Comment

                      Working...
                      X