[Mono-list] Poor Mono performance

[Alan]

The majority of the time in this benchmark is spent doing array bounds
checking. If you change it from a List<T> to a T[], the time taken to
execute the test is about half. This is true on both frameworks. These
kinds of micro benchmarks never give an accurate picture of real world
performance, unless your application actually only iterates List<T>
and sums numbers.

Mono also has different performance characteristics on Windows, Linux
and MacOS, even for testcases as simple as this.

Alan

On 11 March 2013 08:30, Ian Norton
<ian.norton-badrul at thales-esecurity.com> wrote:
> On Sun, Mar 10, 2013 at 02:19:55PM +0000, edward.harvey.mono wrote:
>> > From: mono-list-bounces at lists.ximian.com [mailto:mono-list-
>> > bounces at lists.ximian.com] 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.
>
> Try doing greatest common divisor, mono tends to actually be faster than c!
>
> Ian
>
>> _______________________________________________
>> Mono-list maillist  -  Mono-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-list
> _______________________________________________
> Mono-list maillist  -  Mono-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list