Announcement

Collapse
No announcement yet.

Mono 2.10, Moonlight 4 Preview 1 Released

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

  • #46
    Originally posted by RealNC View Post
    So out of 100 applications only 1 is CPU-bound? You need a reality check. About 50% of the apps I use are CPU-bound.
    Are you participating in some kind of research/compute project? Because in my daily workflow...
    - browser: network-bound
    - mail client: network- and disk-bound
    - messenger: typing speed-bound
    - video player: CPU-bound! (at 10% utilization)
    - image viewer: GPU-bound (2d rendering)
    - visual studio (et al): disk-bound
    - libreoffice: disk-bound
    - virtualbox: disk-bound
    - gedit/scite: whatever
    - new games: GPU bound
    - old games: CPU bound at 400fps

    Other than specialized applications, almost everything else would benefit more from an SSD rather than a new processor. This is common wisdom nowadays.

    They don't teach COBOL, so how's that "the same"?
    It's a much-needed tool that has been renewed and enhanced over the years to implement mission-critical systems. Ever heard of OO COBOL and COBOL.Net?



    All of them fine technologies for their own purposes, uses and goals. I don't see C# and .NET stuff on the list.
    It wasn't invented yet.

    Why was that invented again instead of using one of the above you listed?
    Why invent Gnome when we have KDE or Linux when we have AT&T Linux?

    Oh yeah, MS likes to do their own thing instead of using standardized, already existing stuff.
    Like Apple and most other corporations. Sadly.

    Also, I wonder why they invented C# instead of Python#...
    Because they called it IronPython rather than Python#.

    Oh, could it be that people want C-like languages? You know, of the type you refer to as "COBOL-like, deprecated and ancient crap" while at the same time praising C# even though it has got a big, freaking "C" in its name and is close to C++?
    C# shares more with Java than with C++. You could call it Java done right.

    Yes, because for non-VM languages we already have C and C++.
    And because noone wants non-VM languages if one can avoid it.

    Comment


    • #47
      If Mono is so great to develop for then where are all those awesome Mono apps? It's not like Mono is something new, in fact it has been available on Linux for many years now.

      We had F-Spot, which was so buggy, slow and memory hungry that when Shotwell came around distros quickly replaced it. Unsurprisingly this happened not without resistance and FUD from the Mono political activists. Then there's Tomboy, which someone reimplemented for fun in a very short time in C++, and called it Gnote. Again the Mono zealots were not happy with this to make an understatement. So basically there's only Banshee, which builds on top of the gstreamer framework written in C.

      I think this is a very poor result for a framework so much praised by its evangelists. Clearly most devs for the Linux platform have not any need nor any interest in Mono. And perhaps the Mono devs themselves are more busy with evangelicalism then with writing any code.

      So why are these Mono zealots trying to impose Mono on the Linux desktop? I have never heard of Pascal devs or Java devs holding what's basically a political campaign for said languages to be part of a default install of any Desktop environment or distro. Yet the Mono activist sees it as a God given right that Mono should be included.

      I'm sorry but Mono has no merit on the Linux desktop only theoretical bla bla how great it is, come with some killer apps then we'll talk.

      Comment


      • #48
        Oh, look, a troll!

        There are more than enough great Mono applications if you open your mind and look with unclouded eyes. Of course, you prefer your pathetic circular arguments, wherein you dismiss everything Mono-based out of hand and then proceed to say that Mono doesn't have any killer apps. Sad.

        Oh, a killer app? Second Life, with 21 million users. Go cry in a corner now.

        Comment


        • #49
          Originally posted by BlackStar View Post
          Are you participating in some kind of research/compute project? Because in my daily workflow...
          - browser: network-bound
          Not these days. Everyone is in a race for the fastest JavaScript engine. CPU bound.
          virtualbox: disk-bound
          No, that's definitely CPU-bound.

          - new games: GPU bound
          And CPU-bound.

          All in all, about 50%, as I said.

          It wasn't invented yet.
          It's invented now and they still don't teach that stuff.

          Why invent Gnome when we have KDE or Linux when we have AT&T Linux?
          License issues. Also, hackers have fun coding new stuff.

          Like Apple and most other corporations. Sadly.
          Apple re-used LOTS of stuff. Really, really lots. Objective-C (oh year, "C" again huh?), BSD stuff, NeXT stuff, etc.

          Because they called it IronPython rather than Python#.
          And still, C# is what most use.

          C# shares more with Java than with C++. You could call it Java done right.
          No. C# is much closer to C++ than to Java. Microsoft Chief Architect Anders Hejlsberg said (http://windowsdevcenter.com/pub/a/or...berg_0800.html) that:

          "One of the key differences between C# and these other languages, particularly Java, is that we tried to stay much closer to C++ in our design. C# borrows most of its operators, keywords, and statements directly from C++. We have also kept a number of language features that Java dropped."

          And because noone wants non-VM languages if one can avoid it.
          And you can prove that how exactly? Let's take a look at sourceforge.net projects and see how many of them use a non-VM language.

          Comment


          • #50
            Originally posted by RealNC View Post
            Not these days. Everyone is in a race for the fastest JavaScript engine. CPU bound.

            No, that's definitely CPU-bound.
            Javascript improvements are in the order of ms. Network latencies total in seconds for modern websites with multiple scripts and image elements. Browsers are definitely network-bound - but browser makers cannot do anything about that so they focus on secondary bottlenecks instead.

            virtualbox
            And CPU-bound.
            No, really not. I've been using VBox and VMWare for years and disk performance is by far the slowest part. CPU plays a role but it's quite small (VBox performs almost identically on my dual-core Core 2 and my quad-core Phenom 2 in actual use).

            License issues. Also, hackers have fun coding new stuff.
            Exactly. That's why Mono exists: license issues and hacker fun.

            No. C# is much closer to C++ than to Java. Microsoft Chief Architect Anders Hejlsberg said (http://windowsdevcenter.com/pub/a/or...berg_0800.html) that:

            "One of the key differences between C# and these other languages, particularly Java, is that we tried to stay much closer to C++ in our design. C# borrows most of its operators, keywords, and statements directly from C++. We have also kept a number of language features that Java dropped."
            All three languages share syntax, but C# really is much closer to Java than C++:

            - generics (like Java) rather than C++ templates
            - lack of preprocessor (like Java)
            - modules (like Java) rather than headers
            - common object hierarchy (like Java)
            - single inheritance (like Java)
            - boxing and implicit reference types (like Java) rather than slicing and explicit references/pointers
            - well-defined primitives (like Java)
            - VM-based (like Java)
            - intrusive garbage collection (like Java)

            That's for versions 1.0 and 2.0, however. C# 3.0 and 4.0 takes cues from Javascript and Python and goes to play in functional fields.

            And you can prove that how exactly? Let's take a look at sourceforge.net projects and see how many of them use a non-VM language.
            Ever tried looking for a job in software engineering? Java/C#/PHP/Python/Javascript outnumber C/C++ 10 to 1.

            Comment


            • #51
              Originally posted by BlackStar View Post
              Ever tried looking for a job in software engineering? Java/C#/PHP/Python/Javascript outnumber C/C++ 10 to 1.
              The vast majority of those jobs are for apps running on servers or inside a company. The numbers are the opposite when it comes to applications intended to be sold to consumers.

              Anyway, I agree that C# is Java done right. They've added a bunch of little C++ features into it that Java left out, but there's no question which ones are closer to each other.

              But couldn't disagree more strongly with your assertion that if everything was written in .net memory usage wouldn't go up at all. That's crazy talk, there. I wouldn't be too worried about CPU (at least for the vast majority of applications) but I've never seen a managed code app do anywhere close to decent in terms of memory usage. I'm sure it has a lot to do with the way everything is managed off the heap and sticks around. Maybe eventually this is a problem that languages can solve, but it hasn't happened yet.

              Comment


              • #52
                Phoronix, you still suck.

                You STILL can't edit posts.

                Originally posted by smitty3268 View Post
                The vast majority of those jobs are for apps running on servers or inside a company. The numbers are the opposite when it comes to applications intended to be sold to consumers.
                Which suggests that languages like .NET are very good for developer productivity, but not so good for making apps that don't annoy people (i.e. bad responsiveness, high resource requirements, etc.)

                Comment


                • #53
                  Originally posted by BlackStar View Post
                  Javascript improvements are in the order of ms. Network latencies total in seconds for modern websites with multiple scripts and image elements. Browsers are definitely network-bound - but browser makers cannot do anything about that so they focus on secondary bottlenecks instead.
                  Try JavaScript games in Chrome, for example. Or GMail. If you like having a browser that is slow as molasses, that's your right. I prefer a fast, fluid browser. Those "secondary" bottlenecks count too. And with more apps moving to the web and using JavaScript/AJAX, this is becoming more and more important.

                  You can argue all day long, but speed matters in browsers.

                  No, really not. I've been using VBox and VMWare for years and disk performance is by far the slowest part. CPU plays a role but it's quite small (VBox performs almost identically on my dual-core Core 2 and my quad-core Phenom 2 in actual use).
                  If virtualization in VMWare and vbox wasn't optimized like hell already (because virtualization is inherently CPU- and memory throughput-bound, and needs good resource and memory management, you know, the stuff C# does away with), disk speed would be the least of your worries. If clicking that start menu inside a Windows 7 guest would take 2 seconds to register, you wouldn't care about disk speed.

                  And btw, how can vmware (or whatever) be disk-bound anyway. It's like saying your whole PC is disk-bound. Well, yeah, duh! Your host OS is too. But there's nothing *inherently* disk bound in virtualization.

                  All three languages share syntax, but C# really is much closer to Java than C++
                  Sorry, I'll take the word of the persons who invented C# over yours. No offense.

                  Ever tried looking for a job in software engineering? Java/C#/PHP/Python/Javascript outnumber C/C++ 10 to 1.
                  Yes, that's web development. Software-engineering is not just web development. And no one is arguing here that you should develop web apps in C, so what exactly was your point here?

                  Comment


                  • #54
                    Originally posted by smitty3268 View Post
                    The vast majority of those jobs are for apps running on servers or inside a company. The numbers are the opposite when it comes to applications intended to be sold to consumers.
                    Well, most user-facing applications I've had to buy recently actually installed .Net, so I'd argue that's not quite correct. In any case, server and internal line-of-business apps probably outnumber end-user apps by an order of magnitude or so - and those LOBs tend to be written in .Net et al today.

                    But couldn't disagree more strongly with your assertion that if everything was written in .net memory usage wouldn't go up at all. That's crazy talk, there.
                    You'd be right if I had ever said that.

                    I wouldn't be too worried about CPU (at least for the vast majority of applications) but I've never seen a managed code app do anywhere close to decent in terms of memory usage. I'm sure it has a lot to do with the way everything is managed off the heap and sticks around. Maybe eventually this is a problem that languages can solve, but it hasn't happened yet.
                    Virtual memory indeed goes way up, because .Net reserves around 10MB for each app on startup. However, this memory isn't committed until it's actually used - you may run out of address space sooner (a non-issue with 64bit CPUs) but you won't run out of memory because of this. Virtual memory != memory usage (don't trust your task manager).

                    You get a fixed memory overhead for the runtime and BCL, which is amortized among all managed applications. This is trivial anyway (in the order of single-digit MBs) and the more managed applications you run, the less important it becomes.

                    You get *decreased* memory fragmentation which is the largest issue for long-running applications (fragmentation acts like an insidious memory leak that can cause an app to run out of memory even when enough free memory exists).

                    Finally, .Net supports both stack and heap allocations (unlike Java which always goes to the heap unless the runtime can guess correctly). Stack allocations are actually an important part of performance-oriented .Net code.

                    (That said, most of the issues with Mono memory usage stem from the god-awful GTK# bindings, not from the runtime itself.)

                    Originally posted by RealNC
                    Sorry, I'll take the word of the persons who invented C# over yours. No offense.
                    You really didn't understand what he was actually comparing, I'm afraid. Try rereading that blurb and refer smitty3268's post for clarification.

                    Yes, that's web development. Software-engineering is not just web development. And no one is arguing here that you should develop web apps in C, so what exactly was your point here?
                    Who said anything about web development? Let me ask you again: have you tried looking for any softeng jobs recently?

                    The offerings for C++ are slowly but surely going down.

                    Comment


                    • #55
                      @RealNC
                      In my experience JS is by far not the fastest thing I can think: AdBlock makes for certain much snappier those webpages (in FF 3.6 compared with last Chrome without enabling the AdBlock extension), the fact to not start any extra plugins (like flash on most sites excluding the main view of Youtube). Did you ever tried GMail on IE8 (not 9)? I really felt it snappier (I'm not a fan of IE8 in anyway) and for certain it runs in an interpreter. A JIT will help, but certainly, even IE9 is the *slowest* of all JIT JS around there, in all benchmarks that are in their site they shine! Because they have a lot of systems optimized for browsers. They show that sometimes a browser can be GPU bound and in a lesser measure CPU bound.
                      Even it will be, JS works like 10 times slower (at best!) than C++ (compared with Mono/.Net that is in 1.5-2x slower on typical usage). So why people use JavaScript? Because is not native, it's GCed, JIT-ted and *productive*.
                      About responsivity, memory resources and so: did you ever measure those? Or you work just with biases like: you start a big application as NetBeans, and you conclude that start slower than GEdit, so it means that Java *sux*? A desktop project I work on removed a framework (SCSF) and rewrite that part in it's "raw" implementation (this was not because we wanted to run fast, the reasons were for other technical reasons) and the project I'm working gained around 2 seconds on startup. In the last time profiling of that application it runs like this: 3.5 seconds start time from which identifiable time is like: loading libraries, UI layouting, start OpenGL subsystem, Direct3D one, browser control one (used for help). .Net identifiable overhead? Around 0.2 seconds.
                      Did you heard about Magika? Is a .Net game. I don't wanna you to play it, it will likely not run in Wine. What about XPand Rally? Its a rally game engine is written in Java. I think even if you will be put in front of real numbers (which most people don't care) you will see that probably Java/.Net/JS are not the best performers (in your specific benchmark) may be just enough to a lot of use-cases.
                      Even you will may say: look, Magika don't use C# everywhere, it will eventually go to GPU that is written in C++/asm/whatever, or kernel. This is all about! Is about to use proper tool for proper job. Sometimes, if you are on a small team, you stay one week (or one month), investigate the overhead of a technology and peek the leanest one. Can be sometimes to not be C++? For certain, because overhead comes from: build times, "nice" template errors, hard to write and to read code, linker errors, IDEs that don't have proper refactors, memory leaks, slow performance if you use STL and you will get bounds checking that is not removed by your compiler, or simply that you copy all collection instead of sending "const references", slow performance on reference counted code like smart pointers (mostly in loops), relatively hard to find a generic driver for Sql (probably Qt is the single option, if you don't want to work directly with SqlLite, MySql and so on), high skilled personnel just to start your project, no static check analyzers for your code.
                      Don't take my word for it but you may find millisecond range high performance transaction code in Java (like in London Stock Exchange), aviation (that have both real-time requirements and robustness), a lot of banking systems (replacing mostly Cobol/C/C++ codebases).
                      I also recommend to you to start two tools side by side with similar functionality: Visual C# Express and SharpDevelop. C# Express is mostly written in C++, when SharpDevelop is completely written in C#. Judge for yourself which is faster (take SharpDevelop 3 to compare with VS 2008, and SD 4 to compare with VS 2010 as they have similar technologies inside them). At least on my machine, SD starts a bit faster, and after this in almost all operations is MUCH faster than C++ counterpart: build times, navigating through classes and so on.
                      If you just use Linux as you hate Microsoft, try Pinta with Krita. I do think you will hate Pinta (cause of Mono), but regardless of your preference, judge performance using the same measure: both code is unlikely written in assembler so you will get similar timings. Also, if you find an operation that Pinta is slow, I recommend you to run in Mono/LLVM to get better timings.

                      Comment


                      • #56
                        Originally posted by BlackStar View Post
                        You'd be right if I had ever said that.
                        Previously:
                        Take a good look at your Linux and/or Windows installation. Most programs are not running in a VM. Now imagine how well that system would run if everything was running inside .NET. What would the memory and CPU usage look like?
                        Identical, quite likely. The BCL can be shared between applications and 99.9% of them are not CPU-bound anyway.
                        Sounds to me like that's exactly what you said.

                        Comment


                        • #57
                          Originally posted by smitty3268 View Post
                          Previously:

                          Take a good look at your Linux and/or Windows installation. Most programs are not running in a VM. Now imagine how well that system would run if everything was running inside .NET. What would the memory and CPU usage look like?
                          Identical, quite likely. The BCL can be shared between applications and 99.9% of them are not CPU-bound anyway.
                          Sounds to me like that's exactly what you said.
                          What I said: the cost of one application vs multiple applications is identical (the VM is shared).

                          What you understood: the VM doesn't have a cost.

                          I didn't say what you thought I said.

                          Applications themselves don't start using more memory just because you run them inside a VM: a pointer is a pointer, a vtable is a vtable and a bitmap is a bitmap no matter what (in fact, Java can actually compress pointers to reduce memory usage, but that's beside the point). The cost comes from the VM, which is amortized among all applications - the more managed applications you run, the more the VM cost is amortized.

                          Comment


                          • #58
                            Originally posted by kraftman View Post
                            Why I don't want mono on Linux:
                            it's slow, it's crap from ms ...
                            I've tried to put your wording on test. Mostly on slow part which is a part of concern.
                            So I've took one multi-language mini-benchmark (to be fair, was the first on order of relevance that I found) about computing Pi digits.
                            As many may found is mostly integer + string operations that match most of today desktop application benchmarks.
                            So the benchmark was published around 10 years ago, showing that likely picking C++ or C was the best choice, C#/Delphi may be a good choice that in any way was better than Java.
                            Here is the benchmark and source-codes on reference: http://www.tempest-sw.com/benchmark/
                            As a lot of people will find limiting the high values of benchmark, also making things to distant as much as possible (what is the difference between 170 ms against 230 ms for 2000 digits on my machine? I cannot spot with my eyes, to be fair).
                            My machine is in short i5-540M, a lot of RAM, Win7 64. I've used against runtimes I found just once to download and I've excluded Python, Perl and so on, which will be slower than Mono and .Net.

                            So I've computed all benchmarks with arguments: 20000 out.txt (meaning compute Pi with 20000 digits and write the output to out.txt) and this is the timing:
                            .Net 3.5SP1/4.0 (32 bit): 20935 ms.

                            Mono 2.10:
                            mono --gc=sgen --llvm TimmedPi.exe (32 bit): 20608 ms.
                            mono --gc=sgen -O=all TimmedPi.exe (32 bit): 21028 ms.

                            JDK 7.0 (64 bit): 15584 ms. I did install 32 bit but cause of my incompetence I've got class not found at startup, I really ask anyone who wants to test this code to do it.
                            VS/C++ 2010, I've got the best timing based on all options I found on Release configuration, and I've checked a lot!: C++: 17738 ms
                            So, Java is the *fastest* here and:
                            - C++ is 13.82% slower than Java
                            - C#/Mono/LLVM: 32.24 % slower than Java / 16.17% slower than C++
                            - C#/.Net: 34.33 % slower than Java / 18.02% slower than C++
                            - C#/Mono: 34.93 % slower than Java / 18.54% slower than C++

                            I've tried timings on Linux but I think I've did something terribly wrong and GCC gets on my machine around 25 seconds (so it gets worse than Mono), Mono timing remains constant and Java is around 16.5-17 seconds (again the fastest). The reason I don't want to show those results to make people to try by themselves those "benchmarks" and to notice how right they are and based on those to get the right conclusion.
                            Will you not use an easier to use language (as C#) if you will know from scratch that will run around 20-35% times slower than the best optimized platform you can run, if you feel comfortable in it?

                            Comment


                            • #59
                              Originally posted by BlackStar View Post
                              What I said: the cost of one application vs multiple applications is identical (the VM is shared).

                              What you understood: the VM doesn't have a cost.

                              I didn't say what you thought I said.

                              Applications themselves don't start using more memory just because you run them inside a VM: a pointer is a pointer, a vtable is a vtable and a bitmap is a bitmap no matter what (in fact, Java can actually compress pointers to reduce memory usage, but that's beside the point). The cost comes from the VM, which is amortized among all applications - the more managed applications you run, the more the VM cost is amortized.
                              No, what was said that running everything in the system in .NET would result in a big memory usage increase. You then replied it wouldn't. And now in your last response, i'm not even sure what your final position was.

                              So, I'll just ask clearly again: Everything running in .NET, memory usage goes way up? Or not? You have 1 word to reply.

                              Comment


                              • #60
                                Originally posted by ciplogic View Post
                                I've tried timings on Linux but I think I've did something terribly wrong and GCC gets on my machine around 25 seconds (so it gets worse than Mono), Mono timing remains constant and Java is around 16.5-17 seconds (again the fastest). The reason I don't want to show those results to make people to try by themselves those "benchmarks" and to notice how right they are and based on those to get the right conclusion.
                                Will you not use an easier to use language (as C#) if you will know from scratch that will run around 20-35% times slower than the best optimized platform you can run, if you feel comfortable in it?
                                You should be very careful drawing conclusions from these sorts of micro-benchmarks. What you've shown isn't that a language is 30% faster than another one, but just that its compiler has an optimization for that specific case being tested which is 30% faster. The situation could be completely reversed on another benchmark.

                                Comment

                                Working...
                                X