Mono 2.10, Moonlight 4 Preview 1 Released

[ciplogic]

It was just example and analogy. MS OOXML has very big relation with mono, because mono and MS OOXML are Microsoft techs (both lobbied by Icaza btw). Microsoft wants people to use its technology, because they want to have it under control.

"This is a personal web page. Things said here do not represent the position of my employer. " - Miguel de Icaza
Source: http://tirania.org/blog/
What Microsoft and Icaza lobbied with informed choices, or less informed, is not equal to link Mono with whatever of his oppinions.
He is biased and he is entitled to, at least on his blog!
Do you want MS format for office files, to not succeed is fine, just don't pick bad analogies and try to improve logic associations.

[oleid]

another update

Another update:

Just wanted to check, what the performance penalty of using c++ classes like string + vector vs. plain C arrays is. Therefore I took the C version of the code and replaced the int array with a vector<int> and the char array with string (and removed the free, and copied the IO stuff from the C++ version). Guess what? It's faster, even faster than the plain C version



$ time ./pi-cpp4 10000 out2.txt

real0m6.643s
user0m6.633s
sys0m0.006s

The C version was around 6.9 s.

[ciplogic]

Another update:
(...)
$ time ./pi-cpp4 10000 out2.txt

real0m6.643s
user0m6.633s
sys0m0.006s

The C version was around 6.9 s.

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 and no: you change the collection, but you did not use the same paradigm (which made overengineered the first solution in first place). You just prove the Smitty point that a compiler can optimize at it hits (or not) some optimizations. I'm gladly surprized on those results. Did you used iterators, or used vector with an indexer to visit all data?
I do know and I to agree with you, C++ can generate better code than Mono (was true already in Windows/Visual Studio 2010 results). The issue is that if you still use the lowest paradigm (here C one, that was matching great with compiler optimizations) you will get great performance, but a lot of C++ projects do not work in this way.
Also the point of benchmarks were not to prove that Mono was the fastest, but that in a specific scenario, things may change and even your information (or mine, that proves in many ways innacurate on Linux/GCC) should be tested before drawing conclusions.
Linpack (also known as LAPack) was ported to C# and Java and _this_ benchmark may show even a greater difference, and to check my honesty, you may look for this same text (Linpack in this tread) as a case of Mono being already slower (I've tested it, and should be at least 2x slowdown, compared with C++) but in typical code is now how people use Mono (or .Net) and little people wrote everything (the tendency is that you can see photo processing in JavaScript if you sow Chrome Experiments) where it make no sense in that specific language. LibXML2 is faster than System.Xml, but may not be visible in practice.
Which conclusions will you draw from your benchmarks? Will you use Mono (you already did for those benchmarks at least ) knowing that you have in worst case implementation a 2X slowdown? If you will can, will you rewrite a Qt code that go from supposedly 2 seconds to a 0.7 seconds (to be rewritten in C like style), will you consider to rewrite that code and provide a patch?

[monraaf]

The guy will backport fixes after this? I've heard that Gnote is a dead project now, isn't so?

I've heard that Tomboy is a dead project now, isn't so? Why don't you check yourself before making such comments?

You know the tendency of Mono proponents to spread FUD about competing products sure doesn't help its cause. If anything it adds to the perception that Mono is a not a framework that has a merit of its own, but is there because of its vocal advocates pushing it with lies, deception and politics.

[ciplogic]

I've heard that Tomboy is a dead project now, isn't so? Why don't you check yourself before making such comments?

You know the tendency of Mono proponents to spread FUD about competing products sure doesn't help its cause. If anything it adds to the perception that Mono is a not a framework that has a merit of its own, but is there because of its vocal advocates pushing it with lies, deception and politics.

I've made wrong assumptions based on blog entries: http://www.figuiere.net/hub/blog/?Gnote not on application availability (as I don't use an app to save 10 M of RAM) and as I'm registered to Planet Gnome, I've get from time to time notifications about Tomboy but I've don't remember anything about GNote (excluding the fuss about porting in initial releases)
Mea culpa for my mistakes. Read lies and non factual statements as degree of correctness and I think that I stand pretty much ok, but still I want to make clear that I apologize for my mistake!

[oleid]

(...)Did you used iterators, or used vector with an indexer to visit all data?(...) The issue is that if you still use the lowest paradigm (here C one, that was matching great with compiler optimizations) you will get great performance, but a lot of C++ projects do not work in this way.

It's C++ vectors with indexer, no iterators. And to be honest, I'd never use anything different for that case.

[oleid]

(...)Did you used iterators, or used vector with an indexer to visit all data?(...) The issue is that if you still use the lowest paradigm (here C one, that was matching great with compiler optimizations) you will get great performance, but a lot of C++ projects do not work in this way.

It's C++ vectors with indexer, no iterators. And to be honest, I'd never use anything different for that case.

[kraftman]

Install Tomboy and see if is installed WinForms, so is isolated by your main product, probably is not there (is not, but just check). On Windows on the other hand is preinstalled as Mono come as a full package. Is like QtWebkit that is a Webkit ripoff that may break things from Apple (Webkit is an Apple hosted project) so it may pose similar risks as WinForms. Should we not use Qt for this reason? Don't you find this logic bogus? And what if WebKit will be blocked from Qt? Will mean that Qt applications will use QtGecko in future, not that we have to remove all Qt applications as they pose risks.

Why you are telling me I should check if Tomboy installs winforms or not while winforms are delivered in mono packages which have to be installed to make Tomboy run.

You state a bug/crash that happen on your machine in F-Spot and that's why Gnote was made that fast by one developer. Which is the relation!?

There wasn't supposed to be some relation. I didn't benchmark F-spot, because it crashed.

I don't think that you wrote programs that were larger than some hundred of lines, where using a framework (even is Qt, or C++ STL library) is very important, if not mandatory. I've seen codebases of 14.000 classes, that are like 5 million lines of code, which was hand-made, not generated. Was one of the ugliest in my life experience.
I think you can imagine that porting is not developing: think that some one wrote a versioning system and pin down bugs for two or three years. And after other one skip his hard work spotting bugs, reporting and fixing buggs (that take most of development time, I sow that on average I change 500 lines of code per day in a 2 year time, and this with paid tools like Resharper, Visual Studio Pro, not toys like SharpDevelop or Gedit C# syntax highlighter) but he will translate line with line, probably he will get likely around 3-4000 lines of code per day as I will run the compiler and see where it crash and do a global replace. (I don't want to submine his contribution, but to get a scale of what you imply). So line to line conversion prove almost nothing. The guy will backport fixes after this? I've heard that Gnote is a dead project now, isn't so?

So if it's so easy to port mono projects the good option is to port every mono project to another language - it's quite easy and the final product is more efficient. I thought mono on Linux is dead, but maybe not yet.

You're not a developer, right? Garbage collection, (Generics/Linq even are not as big as stated), var keyword, a decent IDE are the first ones that appear right now in my mind, and the wide range of availability of the code. Performance wise is even faster than Qt/C++ if you use Qt collection framework (or STL/Boost collections). Also you can develop a C# code that works on Windows, Linux (not on your Linux though ), major phones, OS X, web servers, some browsers (as Silverlight, Moonlight). And all those work without an interpreter, as is Python (that I see as biggest Linux "competitor" as abstractions, target, probably the REPL support is the thing that is missing, but just on non Mono distributions). The competing choices as platform availability are Oracle's Java and Adobe's Flash.

No, I'm not. I'm just playing a little with Qt and C++. About performance I don't remember you should something which would backup your claims. Does mono run on Android? If not, it doesn't run on major phones.

[kraftman]

"This is a personal web page. Things said here do not represent the position of my employer. " - Miguel de Icaza
Source: http://tirania.org/blog/
What Microsoft and Icaza lobbied with informed choices, or less informed, is not equal to link Mono with whatever of his oppinions.
He is biased and he is entitled to, at least on his blog!
Do you want MS format for office files, to not succeed is fine, just don't pick bad analogies and try to improve logic associations.

Things said there do represent very well the position of his employer.

[ciplogic]

Why you are telling me I should check if Tomboy installs winforms or not while winforms are delivered in mono packages which have to be installed to make Tomboy run.

So let's test again your claims:

$ sudo su
# apt-get install tomboy
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libappindicator0.1-cil libgnome-vfs2.0-cil libgnome2.24-cil libgnomepanel2.24-cil libgtkspell0 liblaunchpad-integration1.0-cil libmono-addins-gui0.2-cil
Suggested packages:
monodoc-gtk2.0-manual evolution tasque
The following NEW packages will be installed:
libappindicator0.1-cil libgnome-vfs2.0-cil libgnome2.24-cil libgnomepanel2.24-cil libgtkspell0 liblaunchpad-integration1.0-cil libmono-addins-gui0.2-cil tomboy
0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
Need to get 38.4kB/1,017kB of archives.
After this operation, 4,907kB of additional disk space will be used.
Do you want to continue [Y/n]?

Also by default WinForms is not installed in Ubuntu 10.10 (so no risk here), the same about XSP, if you think that ASP.NET may have a tricky patented technology. Anyway, to make an analogy, both Gnome and KDE use an implementation of WebKit by default (Gnome in help, KDE in Konquerror or QtWebKit in general) so you should remove KDE as have technologies that once Apple may want to attack.(is a fallacious argument but have more bases as installed technologies). And we should rewrite all code to use Mozilla's Gecko engine.

So if it's so easy to port mono projects the good option is to port every mono project to another language - it's quite easy and the final product is more efficient. I thought mono on Linux is dead, but maybe not yet.
No, I'm not. I'm just playing a little with Qt and C++. About performance I don't remember you should something which would backup your claims. Does mono run on Android? If not, it doesn't run on major phones.

Any final project is easier to be rewritten in other platform as you don't have to bother with bug fixing and such. At the end everything that is written in Vala can be taken as C output and after this look to any inefficiencies that Vala compiler does (do you know that by default Vala checks about NULL pointer!?) and rewrite them in a slimmer C code. And if you will apply to all libraries/codebases that Vala use, you will get a significant speedup. When will you rewrite Shotwell from Vala to C? Or C++? I've already asked you: when a rewritten of your Arch or Ubuntu installer in optimized C, who knows, from 15 minutes that Ubuntu asks, may get down to 14:35. As for my needs, if you have time, I love Mercurial that is written in Python. Will you write it in C++? But at least its frontend? (TortoiseHG that is also Python based)
Does Mono run on Android? Yes, and it does it faster than default Android VM (look for MonoDroid and also here.