Announcement

Collapse
No announcement yet.

Mono 2.10, Moonlight 4 Preview 1 Released

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

  • #61
    Originally posted by ciplogic View Post
    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.
    I saw a similar benchmark and Vala was included too. Surprisingly, Vala was noticeably faster than C++ in some of the tests! Mono was the slowest.

    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?
    I wouldn't, because 20-35% is too big performance hit to me (I also don't use Java, because I found it sluggish too). Maybe I could stand if some applications would be made using mono, but only if mono wouldn't came from MS. Using it, we support MS and I don't want to support MS in any single way. There's also too much PR talk from Icaza and from Novell, so there is something wrong (like patents). Btw. someone who chose a name for this project had a good sense of humor. From the Phoronix news:

    Ttiago, an X developer at Nokia, then went to comment on the Microsoft-Nokia deal. "I’m sure MeeGo is not dead by any chance though… Nevertheless, Nokia’s contribution to X11 development will be obviously diminishing. It’s sad. Our Graphics Team were just feeling the first effects of the new introduced culture for pushing whatever work (well the ones we are allowed) to upstream and now all was cracked down. So,unfortunately this won’t happen with the same volume anymore and the collected numbers of 1.10 is definitely a mark for Nokia."
    It's better to use Qt or Vala, because using mono we support .Net and supporting .Net we support MS and Nokia who are our competitors. There's also entire DE (which is great) made using Qt, so logical thing is to support it.

    Comment


    • #62
      Originally posted by smitty3268 View Post
      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.
      In one word: no.

      I've explained why twice already. Here's a third time: imagine that the runtime requires 20MB of memory. If you run a single managed app that requires 4MB, you'll load the system with 24MB (400% overhead). If you run 250 managed apps that each requires 4MB, you'll load the system with 1020MB (2% overhead, which is insignificant)

      C++ has the same problem: the C++ runtime is somewhere between 5-10MB, depending on the compiler. Run a single 4MB C++ app and you have between 25-150% overhead. Run 250 C++ apps and the overhead falls to 0.5-1% - again, insignificant.

      Outisde the VM/runtime, managed and unmanaged applications have similar overhead: a .jpg is a .jpg and a .torrent is a .torrent no matter if you manipulate it in .Net, Python, C++ or C.

      I wouldn't, because 20-35% is too big performance hit to me
      FFS, Java is 15% faster than C++ in this benchmark, so you surely should be using Java then?

      15% difference in CPU time will not make an application feel sluggish, don't be ridiculous.

      Comment


      • #63
        Originally posted by kraftman View Post
        It's better to use Qt or Vala, because using mono we support .Net and supporting .Net we support MS and Nokia who are our competitors. There's also entire DE (which is great) made using Qt, so logical thing is to support it.
        If you support Qt by buying a full license, you support indirectly Nokia and those money may be invested in WP7 integration.
        On a similar fashion, Vala just prove the point of C# as being a sane language to develop in.

        I think you don't use Ubuntu, Fedora or Gentoo, because the installer is written in Python which works tens of times slower than a Mono or C/C++ written application. You wrote your own Vala installer, right? right?
        The single distros that uses Qt or Gtk as far as I know are: OpenSuse which to say nice is "Mono based" (at least on Gnome) or Mandriva (having a Gtk/Qt wizard). Or you use that ugly slow Python, that is interpreted, have slow math and wonderful regex and integration capabilities?

        I took a "typical" micro-benchmark to prove some points:
        - OS/libraries/implementation may matter. Is too easy to draw conclusion, but just a small test prove you damn wrong on almost everything. Measure, come with your numbers and probe for example making a video on youtube that why Pinta
        - typical wisdom like Java is slowest may not be true for a warmed up application taking a source 10 years old (that most people rely about)
        - that some people don't want to know the truth, and even they know it, they ignore it
        - even if for one case C++ is the best option (for tight loops I would likely use Fortran, that makes better code generation, but this is not an option it seem, just C++ or C) and provides 2x improvements, they will mostly get unoticed, what means PI with 2000 digits, computed on a today machine in 0.2 seconds?
        - on a desktop limiting factor if you have your bad logic, that do no caching, and so on, and making a stupid loop that works through some tags (supposedly) are slow for other reasons than JIT/runtime. The question is motly: do you use the right level of abstraction for that level of code?
        - hypocrisy: is not the point that this or that language is slow, is just that people want undefinetly defend their point, even is baseless. Let's imagine that C++ was 5 times faster than Mono, as it were around 5 year ago, what did it mean for real usage? Did you tried ever MonoDevelop on an Atom based machine two years ago? I'm not here to say is lightning fast, but is not a snail: some controls were written in C/C++ for performance reasons (was mostly the editing view) and you could develop in it. Today it works even better and I did test/debug using it and was surprisingly fast. The same about Pinta, Banshee. In Qt, QML is slow, because is interpreted! QtWebKit is slow even uses a JIT. For me KDE starts in some (enough many) seconds because loads the KdeWorkspace, Plasma, a lot of frameworks, icons (Oxygene), etc.
        To compare, start time of XFCE MonoDevelop, and Banshee in it is much faster than KDE + Amarok + QtCreator, right, right?

        Comment


        • #64
          Originally posted by ciplogic View Post
          If you support Qt by buying a full license, you support indirectly Nokia and those money may be invested in WP7 integration.
          This is probably true, so I wouldn't buy a full license. There's always possibility a fork will be made to kick Nokia's out of the game.

          On a similar fashion, Vala just prove the point of C# as being a sane language to develop in.
          Then why not support Vala instead? It is not only faster (just compare Shotwell to F-spot), but it's also not MS.

          I think you don't use Ubuntu, Fedora or Gentoo, because the installer is written in Python which works tens of times slower than a Mono or C/C++ written application. You wrote your own Vala installer, right? right?
          The single distros that uses Qt or Gtk as far as I know are: OpenSuse which to say nice is "Mono based" (at least on Gnome) or Mandriva (having a Gtk/Qt wizard). Or you use that ugly slow Python, that is interpreted, have slow math and wonderful regex and integration capabilities?
          You have some nice ability, because you discovered what my ideal system would look like. You're partially right mentioning Python (which I hate too), but installer isn't something I'm using all the time, so it's less relevant if it's written in C/Python etc. (but it's still important it must be not written in mono - patents/MS).

          I took a "typical" micro-benchmark to prove some points:
          - OS/libraries/implementation may matter. Is too easy to draw conclusion, but just a small test prove you damn wrong on almost everything. Measure, come with your numbers and probe for example making a video on youtube that why Pinta
          - typical wisdom like Java is slowest may not be true for a warmed up application taking a source 10 years old (that most people rely about)
          - that some people don't want to know the truth, and even they know it, they ignore it
          - even if for one case C++ is the best option (for tight loops I would likely use Fortran, that makes better code generation, but this is not an option it seem, just C++ or C) and provides 2x improvements, they will mostly get unoticed, what means PI with 2000 digits, computed on a today machine in 0.2 seconds?
          - on a desktop limiting factor if you have your bad logic, that do no caching, and so on, and making a stupid loop that works through some tags (supposedly) are slow for other reasons than JIT/runtime. The question is motly: do you use the right level of abstraction for that level of code?
          - hypocrisy: is not the point that this or that language is slow, is just that people want undefinetly defend their point, even is baseless. Let's imagine that C++ was 5 times faster than Mono, as it were around 5 year ago, what did it mean for real usage? Did you tried ever MonoDevelop on an Atom based machine two years ago? I'm not here to say is lightning fast, but is not a snail: some controls were written in C/C++ for performance reasons (was mostly the editing view) and you could develop in it. Today it works even better and I did test/debug using it and was surprisingly fast. The same about Pinta, Banshee. In Qt, QML is slow, because is interpreted! QtWebKit is slow even uses a JIT. For me KDE starts in some (enough many) seconds because loads the KdeWorkspace, Plasma, a lot of frameworks, icons (Oxygene), etc.
          The best benchmarks are "try it yourself". I tried Tomboy and Gnote, F-spot and Shotwell, people complain Banshee is damn slow. Guess which apps are the winners here? If Vala application is running smoother and it's not from MS then why are we still talking about mono?

          To compare, start time of XFCE MonoDevelop, and Banshee in it is much faster than KDE + Amarok + QtCreator, right, right?
          I guess XFCE+QtCreator+Amarok is much faster then their mono counterparts. :>

          Comment


          • #65
            Originally posted by kraftman View Post
            This is probably true, so I wouldn't buy a full license. There's always possibility a fork will be made to kick Nokia's out of the game.

            Then why not support Vala instead? It is not only faster (just compare Shotwell to F-spot), but it's also not MS.

            You have some nice ability, because you discovered what my ideal system would look like. You're partially right mentioning Python (which I hate too), but installer isn't something I'm using all the time, so it's less relevant if it's written in C/Python etc. (but it's still important it must be not written in mono - patents/MS).
            As you see, you are flip-flopping (I think you use Ubuntu ) but why not support Vala instead?
            What if MS will attack with a patent about Vala language which is obviously C# based, and _because_ of Community Promise and OIN stuff, will attack just Vala which will be blocked but Mono codebases will remain standing (is a "conspiracy theory scenario" that a lot of anti-mono folks stand). Should you not remove Shotwell or rewrite it in C/GLib only?
            The installer part of Python does not make necessary the installer slow, because installer is IO bound (some of previous talks), Dpgk/Rpm install speed (which is mostly written in C/C++), script configure and so on. This is exactly why Mercurial and TortoiseHG are way faster than SVN in any operations, even Mercurial is Python based and SVN is C++ based. And don't forget about PlasticSCM, which is also way faster than SVN, this one, you know is C#/.Net based.
            At the end Mono is not from Microsoft, but is Free/OSS software covered by Open Invention Network and is corporate backed. Is like Android: even it was attacked by a company (excluding that Android is not OIN backed), it does not equate with the dead of all Android software. If is so, is the same that Unix rights that are now at Novell make you entitled to think that Linux is from Novell, the same creators as Mono. So you should stop using crap from At&t, Novell. What if SCO will attack and win the battle against Novell or IBM? What if Apple have a patented technology in LLVM that blocks future GCC releases? Or Embarcadero (from Borland heritage)? Should you also conclude that compilers are crap from Microsoft and Borland? So you should not use anything under the sun?
            Originally posted by kraftman View Post
            The best benchmarks are "try it yourself". I tried Tomboy and Gnote, F-spot and Shotwell, people complain Banshee is damn slow. Guess which apps are the winners here? If Vala application is running smoother and it's not from MS then why are we still talking about mono?
            :>
            Which applications are winners? In what? Have you really did your benchmark, or you simply look on "virtual memory" and because Mono for example uses more virtual memory. About Banshee people *complained* as being about slow. Did you know that most of Banshee slowness stands in C optimized SqlLite database that your music library plays against? Even using --llvm is documented to not give any visible benefit cause of that? F-Spot and Shotwell are different in may ways, the same about Tomboy. I think for you, as you can see that on plain CPU time, it is obviously an application as Tomboy is not that slow, to stop right now on startup time. Please go to any of your startup scripts and set: MONO_AOT_CACHE environment variable (if you use still Mono) and you will likely have with no other extra setup a fast startup Mono.
            Originally posted by kraftman View Post
            I guess XFCE+QtCreator+Amarok is much faster then their mono counterparts. :>
            Did you tried it? And by how much? (I will not be surprised that still MonoDevelop + Banshee to start faster than QtCreator and AmaroK)
            The point of the phrase was that you should understand that starting slow, is mostly that some applications load more or less frameworks.
            But you as you always move target: "F-Spot is much slower", but by which degree? Slow in startup, as it may be for whatever reason (for example parsing Xml configuration using System.Xml using DOM traversing may be slower than libxml2 C library, JIT time, a not stripped down startup sequence, and so on). Try MONO_AOT_CACHE to identify if the slowness is regarding JIT time or is slow on operations. For me Shotwell is a slimmed down subset of F-Spot, still enough fast and rightly made. For me most of F-Spot slowness was algorithmic: when you navigate in photos it will do twice the resize of pictures, but I think that you will understand that this may be an unsorted bug, not a Mono related performance; tagging happens automatically in all photos both by timeline and by custom tagging: this implementation may be inefficient (I found yet no equivalent powerful implementation in Shotwell). I do think at the end that Shotwell is well written and the F-Spot being an older codebase, for some time almost unmaintained (getting just patches).
            So: "Then why not support Vala instead?", is for whom you put the question? For yourself in your next project? For developer that do hardwork for you and see that there is practically no IDE with a proper Vala debugger (I think that a future MonoDevelop or val(a)ide may introduce it). That you have no migration part if you made a project like 1000 classes (or whatever unit of "information" you may pick) to target Linux as a rewrite is not like renaming files from .cs to .Vala and from .boo to .genie, to target memory leaks with Weak references excluding that you likely have NO tool to spot memory leaks, and no garbage collector to reclaim them? No proper visual environment that integrates in one tool a form of visual editing + vala coding?
            I know, some of my arguments are just about comfort, that me as a developer will gladly lose some percent of performance to make the thing done, at least where this does not matter. Or are you restarting Tomboy at every two minutes and you notice the startup time of 3 seconds? As I've told you, I work in an opensource project (Windows/.Net only) and who knows, if I will target Linux, Mono is _the_ way to do it. It will not happen soon, to be fair, but I will not rewrite in Vala if a "loonatic" will prefer his politically correct language. Will he/she search after that for memory leaks that will definitely appear after this rewrite?

            Comment


            • #66
              Originally posted by smitty3268 View Post
              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.
              Yes, in fact the numbers are much less as difference and you're fully right on the "optimization path" that enters in compilers or not. If you will take benchmarks like Linpack, you will see that Mono is even slower than C++, and again C++ slower than Java, but this microbenchmark was mostly relevant in desktop applications (that most Mono applications target): is integer and string based with some branching in it.
              In my experience using .Net is in general as slow as 50% slower than C++ (in desktop applications) but is mostly unnoticeable, because most of time you stay much more on other components as disk/network access, OS routines, GUI loading/layouting, database computing and result. Anyway, if you will have an operation that asks 0.1 seconds in C/C++, you will likely get 0.15 seconds on Mono.
              Other issue that this benchmark showed was just the idea that in the past the benchmark was against Java client VM version, old version registry allocator (that was one of the reason of Java slowness) that was fixed with client (and server virtual machines) in 2005!? in Java 1.5. So is unfair to say today, after 5 years after the fact that Java is still slow (at least on "tight loop" benchmarks). May not be suitable for games, or whatever one limitation of Java JIT or GC may hit someone, but for certain is no reason to make it a non-starter just for biased (like: "it is slow").
              I did tests with Mono 2.10 (which was on line with the topic of this forum thread), I could do them without SGen GC and without LinearIL, and the results may pose in a much worse posture.
              Can you agree that even 100% slowdown may be hardly noticeable in an application as MonoDevelop, that most of the time CPU stay idling? And about Banshee (that most of its slowness is SqlLite based) is much about taking a better time profiling and find bottlenecks in logic and less about remove one runtime, to make someone (i.e. kraftman) to dream nice because that "evil runtime" will not "spoil" thy application.

              Comment


              • #67
                Originally posted by kraftman View Post
                I guess XFCE+QtCreator+Amarok is much faster then their mono counterparts. :>
                As I've predicted, you are wrong again.
                So I've made a video to back up my claims, that likely will start faster:
                Here is a recorded session: http://www.youtube.com/watch?v=cH-VrnIV-rs
                MonoDevelop + Banshee: minute 1:02 to 1:20 (18 seconds)
                QtCreator + AmaroK: minute 1:40 to 2:05 (25 seconds so approx 40% slower)
                In real life, the difference may be even greater as CPU was a bit "starved" as video recording was occurring, so if was about CPU bottleneck, it was likely much greater.
                Also, I've put on advantage Qt counterpart as the OS may cache some libraries of the Mono applications startup and the difference may be extra two seconds in advantage of Mono (to not think I don't understand how things work and make a benchmark just to extrapolate a deficiency of timings)
                May you give your timings?

                Comment


                • #68
                  Originally posted by ciplogic View Post
                  As you see, you are flip-flopping (I think you use Ubuntu ) but why not support Vala instead?
                  What if MS will attack with a patent about Vala language which is obviously C# based, and _because_ of Community Promise and OIN stuff, will attack just Vala which will be blocked but Mono codebases will remain standing (is a "conspiracy theory scenario" that a lot of anti-mono folks stand). Should you not remove Shotwell or rewrite it in C/GLib only?
                  I'm using Kubuntu and Arch (jumping from one to another from time to time). I'd like to see what patents (if any) Vala violates. What we know for sure there's stuff in mono which shouldn't be, because it's not covered by the Community Promise. Still, it's better relying on Vala, because we don't support MS.

                  At the end Mono is not from Microsoft, but is Free/OSS software covered by Open Invention Network and is corporate backed.
                  It's from MS. Icaza's MS guy, he promotes MS products and works for MS. The same about Novell - they work closely with MS, support their technology and use crappy - non GPL (so Linux unfriendly) licenses for their products. It's not enough to be Free/OSS and to be covered by OIN. The point is to be patent free and to not support competitors (like bsd licensed products usually support their competitors which is funny and stupid same time).

                  Is like Android: even it was attacked by a company (excluding that Android is not OIN backed), it does not equate with the dead of all Android software. If is so, is the same that Unix rights that are now at Novell make you entitled to think that Linux is from Novell, the same creators as Mono. So you should stop using crap from At&t, Novell. What if SCO will attack and win the battle against Novell or IBM? What if Apple have a patented technology in LLVM that blocks future GCC releases? Or Embarcadero (from Borland heritage)? Should you also conclude that compilers are crap from Microsoft and Borland? So you should not use anything under the sun?
                  I don't like Novell nearly the same like MS. What if OIN will attack and win the battle against MS, so it will collapse or what is more likely GCC will block future LLVM releases? MS compilers are indeed crap for me.

                  Which applications are winners? In what? Have you really did your benchmark, or you simply look on "virtual memory" and because Mono for example uses more virtual memory.
                  I ran my favorite benchmarks (run, use, close) and made memory measurements (excluding vm).

                  About Banshee people *complained* as being about slow. Did you know that most of Banshee slowness stands in C optimized SqlLite database that your music library plays against?
                  I didn't know, but why Amarok with SQLite isn't slow then?

                  [/QUOTE] Even using --llvm is documented to not give any visible benefit cause of that? F-Spot and Shotwell are different in may ways, the same about Tomboy. I think for you, as you can see that on plain CPU time, it is obviously an application as Tomboy is not that slow, to stop right now on startup time. Please go to any of your startup scripts and set: MONO_AOT_CACHE environment variable (if you use still Mono) and you will likely have with no other extra setup a fast startup Mono.[/QUOTE]

                  I'm not using mono normally, but if this trick helps then why it's not turned on?

                  Did you tried it? And by how much? (I will not be surprised that still MonoDevelop + Banshee to start faster than QtCreator and AmaroK)
                  The point of the phrase was that you should understand that starting slow, is mostly that some applications load more or less frameworks.
                  This could explain why Amarok didn't start faster. However, Amarok is much more powerful then Banshee.

                  But you as you always move target: "F-Spot is much slower", but by which degree? Slow in startup, as it may be for whatever reason (for example parsing Xml configuration using System.Xml using DOM traversing may be slower than libxml2 C library, JIT time, a not stripped down startup sequence, and so on). Try MONO_AOT_CACHE to identify if the slowness is regarding JIT time or is slow on operations. For me Shotwell is a slimmed down subset of F-Spot, still enough fast and rightly made. For me most of F-Spot slowness was algorithmic: when you navigate in photos it will do twice the resize of pictures, but I think that you will understand that this may be an unsorted bug, not a Mono related performance; tagging happens automatically in all photos both by timeline and by custom tagging: this implementation may be inefficient (I found yet no equivalent powerful implementation in Shotwell). I do think at the end that Shotwell is well written and the F-Spot being an older codebase, for some time almost unmaintained (getting just patches).
                  Yep, F-spot had noticeably slower startup then Shotwell last time I tried. However, it could be like you described.

                  So: "Then why not support Vala instead?", is for whom you put the question? For yourself in your next project? For developer that do hardwork for you and see that there is practically no IDE with a proper Vala debugger (I think that a future MonoDevelop or val(a)ide may introduce it). That you have no migration part if you made a project like 1000 classes (or whatever unit of "information" you may pick) to target Linux as a rewrite is not like renaming files from .cs to .Vala and from .boo to .genie, to target memory leaks with Weak references excluding that you likely have NO tool to spot memory leaks, and no garbage collector to reclaim them? No proper visual environment that integrates in one tool a form of visual editing + vala coding?
                  I know, some of my arguments are just about comfort, that me as a developer will gladly lose some percent of performance to make the thing done, at least where this does not matter. Or are you restarting Tomboy at every two minutes and you notice the startup time of 3 seconds? As I've told you, I work in an opensource project (Windows/.Net only) and who knows, if I will target Linux, Mono is _the_ way to do it. It will not happen soon, to be fair, but I will not rewrite in Vala if a "loonatic" will prefer his politically correct language. Will he/she search after that for memory leaks that will definitely appear after this rewrite?
                  I prefer to use and support Qt more than Vala, because my favorite DE is made using Qt. Some things may be like you have already written, but as far end results aren't so optimistic for mono. Maybe this will change, but I hope it won't, because of the obvious reasons.

                  I'll give you timings tomorrow.

                  Comment


                  • #69
                    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),
                    Just did the bench on Linux (Mint 10 AMD64, slow laptop)


                    $time java Pi 10000 out.txt

                    real 0m7.584s
                    user 0m8.209s
                    sys 0m2.544s
                    $ time ./pi-c 10000 out.txt

                    real 0m6.998s
                    user 0m6.904s
                    sys 0m0.014s
                    $ time ./pi-cpp 10000 out.txt

                    real 0m14.439s
                    user 0m14.252s
                    sys 0m0.029s

                    $ time mono -O=all pi.exe 10000 out.txt

                    real 0m10.828s
                    user 0m10.721s
                    sys 0m0.035s

                    c and c++ versions were compiled with flags "-O3 -msse2"

                    I had a look at the C++ code and it seemd heavily overengeneered. I backported the java code to C++ (just to find out that it looked the same as the original C code) and did the bench for this version again:

                    $time ./pi-cpp2 10000 out2.txt

                    real 0m7.015s
                    user 0m6.915s
                    sys 0m0.010s

                    So we see that C/C++ are basically the same, 2nd is Java and the slowest is mono. However this was quiet an old version of mono (2.6) without LLVM support, so things will probably be faster.

                    Comment


                    • #70
                      [QUOTE=kraftman;179563]I'm using Kubuntu and Arch (jumping from one to another from time to time). I'd like to see what patents (if any) Vala violates. What we know for sure there's stuff in mono which shouldn't be, because it's not covered by the Community Promise. Still, it's better relying on Vala, because we don't support MS.
                      [/QUTOTE]
                      If you relate on Mono technology post, you will see Moonlight dissected, and the single Mono "specific" parts of Mono that are only for Mono may be: the bytecode (MSIL - ECMA-334) and C# language specification (ECMA-335). The rest are in one way or another in a lot of other opensource projects.
                      So considering that Microsoft (or whatever entity that will attack a Mono specific technology that exist in Linux desktop) can attack the things that may be a threat. Vala is C# inspired and you can attack a patent discretionary (as Apple attacked Nokia or HTC, but not Google), theoretically MS can attach with a close notify. Do you want a specific patent? Is the same that most of anti-mono crowd use (none, if you got my point, but the talk is just in case).
                      Another part that MS can attack is to say about bytecode, that even MS made changes in .Net 4 to support multiple platforms and use the same way that Mono did from 1.0 release, so may be a two way attack. Even will be a certain think that MS will win, a Java-to-Dalvik like bytecode converter may be made to run in a modified fronted of Mono Mini VM (this is the core VM).
                      In rest, all the technologis are under threat as Gnome, KDE, Nokia, Cairo antialiasing, etc. It may be a patent anywhere that may be once attacked, but are not specific to Mono, so the talk is as pointless as Netscape/AOL will attack Nokia's QML as it resemble too much with JavaScript, and for this to recommend to anyone to not use QML.
                      Originally posted by kraftman View Post
                      I didn't know, but why Amarok with SQLite isn't slow then?
                      (...)
                      I'm not using mono normally, but if this trick helps then why it's not turned on?
                      Do profiling or see which queries do. And put a bug report (if this is the concern). For my library (of 2K songs) works smooth (for a 2.4 GHz I5 CPU which may be enough fast for this medium collection).
                      Mono work in general by JIT-ting (compiling just as it "hit" methods) so if you put a lot of code at startup sequence, JIT time may be visible. AOT-cache will precompile as a lib-so your bytecode, getting a bit lower performance because for example Mono Mini will notice small functions and it will inline them (but a better startup time). I'm not complaining on startup performance, but if this is what seems to you the most annoying part of your Mono applications, and you are dependent on startup time (as you seem to run just "lightweight logic" applications as Tomboy, Banshee, if you would ever run them) you may enable it.

                      Originally posted by kraftman View Post
                      I prefer to use and support Qt more than Vala, because my favorite DE is made using Qt. Some things may be like you have already written, but as far end results aren't so optimistic for mono. Maybe this will change, but I hope it won't, because of the obvious reasons.
                      I previously said that I like Qt. I was a programmer in Qt around 4 years ago, and GTK one (as GtkMM) around 3 years ago. Gtk applications also look ugly in KDE, and if you dislike them for this reason I also do undestand you fully.

                      Originally posted by kraftman View Post
                      I'll give you timings tomorrow.
                      I wait them.

                      Comment


                      • #71
                        Originally posted by oleid View Post
                        $ time mono -O=all pi.exe 10000 out.txt

                        real 0m10.828s
                        user 0m10.721s
                        sys 0m0.035s

                        (...)
                        $time ./pi-cpp2 10000 out2.txt

                        real 0m7.015s
                        user 0m6.915s
                        sys 0m0.010s

                        So we see that C/C++ are basically the same, 2nd is Java and the slowest is mono. However this was quiet an old version of mono (2.6) without LLVM support, so things will probably be faster.
                        Thank you for doing it! It is really interesting.
                        Yes, I do think that your timings are great, and IMO (at least for my machine setup) the biggest impact was setting the SGen GC in mono's args than LLVM.
                        Also I've noticed that C++ was slower in Linux (I've did not look to C code, mea culpa, was not intended) and may prove that an "over-engineered" solution may be written in C++. The guy from the original site wrote that it was using the typical abstraction level of that language, as C# code was not written with "unsafe" or to do a P/Invoke to get virtually the same time as the best (C language based) solution.
                        I predict that using SGen you will get around 1 second more from Mono (and for certain you will get a full second if you will also set LLVM) so it will be like 7 against 10 seconds (on your hardware configuration).
                        The question remain: if you are proficient with Java or C#, will you write this code in C to get one extra second? Also, just for performance considerations, Java was not the safest choice? With no flag, just running it directly?

                        Comment


                        • #72
                          Originally posted by ciplogic View Post
                          Thank you for doing it! (...)
                          Also I've noticed that C++ was slower in Linux (I've did not look to C code, mea culpa, was not intended) and may prove that an "over-engineered" solution may be written in C++. The guy from the original site wrote that it was using the typical abstraction level of that language, as C# code was not written with "unsafe" or to do a P/Invoke to get virtually the same time as the best (C language based) solution.
                          Your're welcome. I wonder, however, why the C++-version was "over-engineered" and the C# and Java-Versions are not.

                          Originally posted by ciplogic View Post
                          I predict that using SGen you will get around 1 second more from Mono (and for certain you will get a full second if you will also set LLVM) so it will be like 7 against 10 seconds (on your hardware configuration).
                          My laptop just finished compiling mono-2.10 from source. So I can provide an update:

                          $ gmcs -optimize+ pi.cs
                          $ time mono --gc=sgen --llvm pi.exe 10000 out.txt

                          real 0m10.960s
                          user 0m10.911s
                          sys 0m0.029s
                          $ time mono --gc=sgen pi.exe 10000 out.txt

                          real 0m10.952s
                          user 0m10.913s
                          sys 0m0.017s
                          $ time mono pi.exe 10000 out.txt

                          real 0m10.908s
                          user 0m10.900s
                          sys 0m0.005s

                          mono is not getting any faster...

                          Here is another one: compiled java (using gcj)

                          $ gcj -O3 -msse3 Pi.java --main=Pi -o pi-java
                          $ time ./pi-java 10000 out.txt

                          real 0m9.419s
                          user 0m9.351s
                          sys 0m0.023s


                          By the way... there is also a pi benchmark at the language shootout. It might give some additional insight. The haskell version is currently leading, Java performes quiet poor. Even python3 is faster.

                          Comment


                          • #73
                            Originally posted by oleid View Post
                            Your're welcome. I wonder, however, why the C++-version was "over-engineered" and the C# and Java-Versions are not.



                            My laptop just finished compiling mono-2.10 from source. So I can provide an update:

                            $ gmcs -optimize+ pi.cs
                            $ time mono --gc=sgen --llvm pi.exe 10000 out.txt

                            real 0m10.960s
                            user 0m10.911s
                            sys 0m0.029s
                            $ time mono --gc=sgen pi.exe 10000 out.txt

                            real 0m10.952s
                            user 0m10.913s
                            sys 0m0.017s
                            $ time mono pi.exe 10000 out.txt

                            real 0m10.908s
                            user 0m10.900s
                            sys 0m0.005s

                            mono is not getting any faster...

                            Here is another one: compiled java (using gcj)

                            $ gcj -O3 -msse3 Pi.java --main=Pi -o pi-java
                            $ time ./pi-java 10000 out.txt

                            real 0m9.419s
                            user 0m9.351s
                            sys 0m0.023s


                            By the way... there is also a pi benchmark at the language shootout. It might give some additional insight. The haskell version is currently leading, Java performes quiet poor. Even python3 is faster.
                            Great job again!
                            I'm impressed. I've looked on C++ code and I agree with you: C++ version was overengineered.
                            What source site with benchmarks said:
                            "Each time, I did my best to express the program in the idioms and style appropriate to the language, while also trying to achieve the best performance for that language."
                            Looking on C++ code it makes sense to use Stl and iterators and some overhead to appear from using them. This is why I think that this "benchmark" was appropriate, as if you will get even C++ times as in real life /code-bases. I still have to met someone making a copy of that std::vector in a C array, then use a C code (that have no bounds checking and any iterator overhead) to make the computation and put data in vector back. So likely a Qt application written in C++ that will have to do some processing for example to capitalize all tags for all photos in a collection of photos, will use an over-engineered overhead that according to actual code-styles you will see around, will (possibly) work slower than a Mono written codebase, even C++ as code generator may give better code generation for the same constructs.
                            You may ask why Mono for example did not use over-engineered Linq/Generics constructs, and the answer is probably the timing of the benchmark/website.
                            Also I was wrong as I've tested on my Windows machine and I've get some improvement using SGen and LLVM, but your numbers are really a proof I'm wrong. Also I'm a bit dissapointed that for me both (SGen and LLVM) give consistent (-0.3 s for SGen, -0.5 for LLVM) improvement.
                            Note about Debian/Alioth benchmark: PiDigits uses an external library in all implementations (GMP) and the overhead is mostly how fast/slow can access (so is mostly "speed of call") methods of that library. There is no compiled runtime code (as the code you were testing) that you are using. This is why Python3 performs that great! Yes, Python 3 can call faster a library than Java and the overhead of calling/marshaling (to convert from "managed" to "native" and back) may be lower from Py3 than from Java. This is how most applications work: they call external libraries, and (rarely) when they have to process something, they get decent timing.

                            Comment


                            • #74
                              Originally posted by ciplogic View Post
                              Can you agree that even 100% slowdown may be hardly noticeable in an application as MonoDevelop, that most of the time CPU stay idling? And about Banshee (that most of its slowness is SqlLite based) is much about taking a better time profiling and find bottlenecks in logic and less about remove one runtime, to make someone (i.e. kraftman) to dream nice because that "evil runtime" will not "spoil" thy application.
                              Most applications are not limited in cpu throughput these days - there are some obvious exceptions, like photo/video editing, server apps, web browsers, etc., but for the most part it's true.

                              What people notice is if the UI is unresponsive. A 15ms delay is quite noticeable if it happens right when you are trying to open a menu. 100 times that is completely hidden from the user if it doesn't block the interface. Traditionally, garbage collection could cause some problematic delays in higher level languages, but that has been a significant focus of research and seems to be mostly corrected now. I'd really be much more worried about the memory use than CPU, except for a few particular applications.

                              Comment


                              • #75
                                Originally posted by smitty3268 View Post
                                Most applications are not limited in cpu throughput these days - there are some obvious exceptions, like photo/video editing, server apps, web browsers, etc., but for the most part it's true.

                                What people notice is if the UI is unresponsive. A 15ms delay is quite noticeable if it happens right when you are trying to open a menu. 100 times that is completely hidden from the user if it doesn't block the interface. Traditionally, garbage collection could cause some problematic delays in higher level languages, but that has been a significant focus of research and seems to be mostly corrected now. I'd really be much more worried about the memory use than CPU, except for a few particular applications.
                                15 ms delay is noticeable? Or you mistype as 150 ms? Your eye can notice a change at 40 ms (mostly at 24/25 FPS) but on brain it gets like in 20 ms. So you "skip a frame".
                                If you talk about games, I do believe that writing all logic in a VM may be a wrong idea today (excluding you don't do any allocations in game loop and you did previously AOT compiling). If you put on your menu case, most of toolkits are already preprocessing the interface (so layouting may appear at startup time, but not at runtime, for example). Try Pinta and Krita and try to see which is more responsive by your standard.
                                Server apps are rarely CPU starved (excluding that is a rendering farm there), and are IO bound (network/disk/database code). If you talk like databases, for example Oracle query optimizer is written in Java (and it have a great throughput).
                                Even they are slower or faster, in a lot of instances if you can make your interface asynchronous, the feeling of being fast (think on BeOS times) can be achieved on a lower spec machine. Another thing is that if a framework can distribute easier on all cores your algorithm, may solve your problem faster, even your runtime works supposedly 30% slower, if 2 cores algorithm may give to you a typical 60%-80% speedup (I don't talk on rendering cases witch is close to 100% speedup per core), at 4 cores around 250%-300% speedup.
                                Your example with video/photo editing is also a really interesting case: in case you will write any of those applications, the main limitation is your codec (mostly written in assembly) and your framework (like DirectShow, GStreamer, QuickTime) and much less that is written in Mono (Diva), Java or Python (Pitivi).
                                If you noticed, that was all my point, to measure, to leave most biases away, and so on. I don't think that Qt is a bad technology. Either Gtk/Vala (I love GObjectIntrospection idea initiated from Vala's creator). Either Etoile or XFCE. For some still I think Mono is a key technology, at least in cases of migrating applications and for companies that will want to pick Linux as a future platform.
                                I know bad written technologies in Linux, like: VCL (the toolkit of Libre/OpenOffice), confuse TreeView (MVC) implementation in Gtk, buggy redraw apis of Qt combined with a Metacity hacks to make i work right, GCC pre 4.4 bad autovectorizer optimizer, almost non that useful "whole program optimization" that exists at least for 3 years in Visual Studio, and at least for 5 years in Intel Compiler. Even Mono from technological point of view was not that "amazing" 4-5 years ago, a fairly bad JIT (rewritten at least two times, the last reiteration, named LinearIL generates a decent code) and an awful garbage collector. I would love to see a "control panel" written in MoonLight using MoonLight desktop with animations and so on, as Gtk may look a bit outdated (I know that Clutter may give some hopes) or a better file manager. For certain as I see some people whining, will not happen fast (also RedHat/Fedora are typically against Mono so no hope for next one or two years). People may disagree with me and I agree with them, at one level Moonlight is risky, but is not more than OpenOffice that exist in any Ubuntu installation.
                                I don't mind to use FF4 to use Phoronix even I know that JS code will work slower (than C++, whatever), or sometimes may be a 40 ms GC, because I do not notice the impact of it. Anyway, I get half-outraged when people get out of context, out of date, too biased and simply hateful for some that work a lot of time to offer to some a good technology to start with on Linux.

                                Comment

                                Working...
                                X