[Mono-list] Poor Mono performance

Mon Mar 11 16:47:09 UTC 2013

I think this is important to address. The biggest grievance I have with
Mono (and that many I've spoken with have) is the poor performance. It
seems like most of this thread is just excusing away the poor performance,
but not trying to address it. It really is a problem.

On Mon, Mar 11, 2013 at 10:44 AM, Olajos, Imre <IOlajos at ballytech.com>wrote:

> Alan,
>
> So, I did try your suggestion and replaced List<int> with int[]. It did
> improve the performance of the code, but as I suspected, it also improved
> the performance in .NET, so the relative performance difference between the
> two CLIs is still 80-90%:
>
> Windows .NET = 0.479 sec
> Mono 3.0.6 with -O=unsafe option = 0.882 sec
>
> --
> Imre
>
> -----Original Message-----
> From: Olajos, Imre
> Sent: Monday, March 11, 2013 9:19 AM
> To: mono-list at lists.ximian.com
> Subject: RE: [Mono-list] Poor Mono performance
>
> Alan,
>
> This is NOT just a benchmark - my actual code looks similar to this,
> except it does a lot more things inside the body of the do-while loop.
>
> > If you change it from a List<T> to a T[], the time taken to execute the
> test is about half.
>
> I'm sure that's true (and I will try that), but what I'm more curious
> about is why the big difference in the RELATIVE performance between .NET
> and Mono? If I change my code to speed it up in Mono, I'm sure that'll
> speed it up just as much in .NET, too - so, the relative performance of the
> code will remain more or less the same between the two CLIs. Is there
> anything I can do that would bring their relative performance difference
> closer to each other (e.g. below 20-25%)?
>
> By the way:
>
> > The majority of the time in this benchmark is spent doing array bounds
> checking.
>
> I got the same poor performance from Mono with the -O=unsafe option, which
> I thought turns off array bounds checking, too.
>
> --
> Imre
>
>
> -----Original Message-----
> From: Alan [mailto:alan.mcgovern at gmail.com]
> Sent: Monday, March 11, 2013 2:07 AM
> To: Ian Norton
> Cc: edward.harvey.mono; mono-list at lists.ximian.com; Olajos, Imre
> Subject: Re: [Mono-list] Poor Mono performance
>
> 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
>
> _______________________________________________
> Mono-list maillist  -  Mono-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-list/attachments/20130311/9e7f5a26/attachment.html>