Edward, > If you want to do a performance comparison, you need to find a job that you > actually care about, and hardware that you actually care about, and test on > that.
This may surprise you, but this is a job I care about on a hardware I care about. I have simplified it a lot, of course - the actual job I'm trying to do in a similar fashion will run for days and even weeks in a distributed fashion both on Windows .NET and on Mono on Linux boxes (and possibly even Macs). So, any performance issue with Mono gets amplified and I'm curious why Mono seems so much worse than .NET for even a simple case like the one I presented in the sample program. -- Imre -----Original Message----- From: edward.harvey.mono [mailto:[email protected]] Sent: Sunday, March 10, 2013 7:20 AM To: Olajos, Imre; [email protected] Subject: RE: [Mono-list] Poor Mono performance > From: [email protected] [mailto:mono-list- > [email protected]] On Behalf Of imreolajos > > Hi all! > > SpeedTest.cs > <http://mono.1490590.n4.nabble.com/file/n4658877/SpeedTest.cs> Did you read that code? All it does is a bunch of adds and multiplies. If that were *seriously* representing your workload, you would use C or assembly. The reason you code in .Net or mono is for the sake of high level classes and stuff that make development faster than coding C++. As long as performance is good enough, you call it and end product. If you need to tweak performance more, you need to dig lower level into C/C++/asm. There are lots of times when, as a programmer, you have to accept some performance sub-optimization with .Net or mono, just because the pre-packaged class or whatever you're building on top of doesn't do *exactly* what you want it to do. That's the price you pay for using a fully managed, high level, rapid development programming language and framework. For example, if you want a Queue that guarantees uniqueness... The standard queue doesn't guarantee uniqueness and the standard Hashset doesn't guarantee order. So you'd have to go find something else, or use a combination of Queue & Hashset, which is a sub-optimization caused by the fact that the data structure available to you isn't precisely what you want. In any event - the comparison of performance between .Net and mono is a valid thing to care about, if you have a valid test. Here's what you should focus on, if you care: The .Net framework and mono class library is a *huge* set of stuff. Microsoft has separate teams of developers for each category of stuff, and mono pulls in code from hundreds or thousands of independent sources. Guess what that means? Sometimes .Net will be faster, and sometimes mono will be faster. It depends on the specific class and version and OS (and even cpu) that you're running on. It depends specifically what you're doing. I don't have specifics, but here's a hypothetical: You might find that .Net 3.5 System.Drawing.Drawing2D.Blend running on windows 7 with an Intel 64bit processor might perform half as well as with the AMD 64bit processor, and mono 2.4 in centos might be 3x slower, but when you switch to mono 2.10 in fedora, it might be 2x faster than the fastest .Net, and when you try .Net 4 or 4.5, they might have optimized it ... You might find that one of these things has a slower startup and a faster runtime ... Thus making it better for certain types of Blend operations, while being worse for other datasets. I know this one in particular: General consensus on the Internet is that System.Security.Cryptography.AESManaged has a faster startup time and slower runtime than System.Security.AESCryptoServiceProvider. Even though they both do the same thing, they're each optimized differently. And guess what, from one version of .Net to another version... From one version of mono to another ... AESManaged performance will vary. And the performance depends on whether or not you have AES-NI instruction in your CPU (that produces approx 10x performance difference) and it depends on which version of .Net first included support for the AES-NI, and it depends which version of mono first included support for AES-NI. If you want to do a performance comparison, you need to find a job that you actually care about, and hardware that you actually care about, and test on that. You cannot make any generalization and expect it to have any validity, unless you *extremely* thoroughly benchmark all the different variables ... Change the CPU's, the OS's, 32bit and 64bit, with and without specialized hardware instruction sets, with and without certain Service Packs and KB patches applied ... Run on windows, mac, linux, ... Nobody does this much performance evaluation. You cannot make a generalization. _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
