Announcement

Collapse
No announcement yet.

Mono 2.10, Moonlight 4 Preview 1 Released

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

  • smitty3268
    replied
    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.

    Leave a comment:


  • ciplogic
    replied
    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.

    Leave a comment:


  • oleid
    replied
    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.

    Leave a comment:


  • ciplogic
    replied
    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?

    Leave a comment:


  • ciplogic
    replied
    [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.

    Leave a comment:


  • oleid
    replied
    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.

    Leave a comment:


  • kraftman
    replied
    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.

    Leave a comment:


  • ciplogic
    replied
    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?

    Leave a comment:


  • ciplogic
    replied
    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.

    Leave a comment:


  • ciplogic
    replied
    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?

    Leave a comment:

Working...
X