[Mono-list] Poor Mono performance

Tue Mar 12 16:54:17 UTC 2013

Edward and Imre - Wow, okay your results definitely didn't mesh with mine,
very strange things are afoot... On my windows 7 with an Intel i7 3.4 GHz
processor I had substantially different runtimes comparing mono and .NET
4.5.  Below shows the 2x2 factorial for compiler versus runtime.  These
results do not change much across replicates, and basically there is a
massive performance difference between .NET and mono when I ran it.  I don't
know if at this stage this is due to cache misses/etc.  Looking at the IL
produced by the two different compilers, there are some differences in the
methods and they load the different methods at different positions in the
table, in any event there is a clear difference between all of these 4
except the two mono treatments.  I wonder if this is a .NET 4 v 4.5 thing?

Compiler

CLI

Time

mcs 

Mono 2.10.9

1.9 s

mcs 

.NET 4.5

.93 s

Visual Studio

Mono 2.10.9

1.87 s

Visual Studio

.NET 4.5

0.64 s

Imre  -  you missed the point of my email, and obviously I could have made
the program a lot faster than I did.  The point is that your program is
generally slow for other reasons, though you seemed to be worried about
using Arrays or Lists which is peanuts compared to other things you could
do.  In particular, in both Mono and .NET, method calls are expensive.  In
my experience, adding numbers and incrementing values takes no time compared
to calling the method that does these things.  I was suggesting you should
do the following things:

1 - Make sure the method is inlined, avoid the method call.

2 - Do not insert the for loop inside a useless do while loop.  You are
checking conditions inside and outside the method and likely preventing
important optimizations like caching the list.count property.  I don't know
what you are trying to do, but note that if you replace the do/while code
with the code below, than you inline the Advance method, can still do
everything inside the loop and it is over an order of magnitude faster on
either .NET or Mono.  Not sure if you can do this with your code, but the
point is mono v. .NET performance differences pale in comparison to the
nested for-loop-method-call-inside-do-while-loop performance penalty you are
paying right now. 

       for (int index = counters.Count - 1; index >= 0; --index)

               {

                    ++counter;

                    if (counters[index] == (totals[index] - 1))

                    {

                        counters[index] = 0;

                        continue;

                    }

                    else

                    {

                        ++counters[index];

                    }

                    //All kinds of other stuff can be done here....

                }

-N

-----Original Message-----
From: mono-list-bounces at lists.ximian.com
[mailto:mono-list-bounces at lists.ximian.com] On Behalf Of edward.harvey.mono
Sent: Tuesday, March 12, 2013 10:06 AM
To: imreolajos; mono-list at lists.ximian.com
Subject: Re: [Mono-list] Poor Mono performance

> From:  <mailto:mono-list-bounces at lists.ximian.com>
mono-list-bounces at lists.ximian.com [mailto:mono-list- 

>  <mailto:bounces at lists.ximian.com> bounces at lists.ximian.com] On Behalf Of
imreolajos

> 

> SpeedTest.cs

> < <http://mono.1490590.n4.nabble.com/file/n4658877/SpeedTest.cs>
http://mono.1490590.n4.nabble.com/file/n4658877/SpeedTest.cs>

Ok, you've provided some source code, you said it is important to you, and
it represents your real life work load.  You've said you had some
performance problems with it and would like to know why and what to do about
it ...  Other people here have commented that it seems we're avoiding the
problem.

So, I'll bite:

I downloaded the file you linked above, and compiled it, .Net 4 Windows 7
x86_64 dual core intel i5.  It ran in 3.3 sec.  I then ran on the exact same
machine in windows mono 2.10.9 and it ran in 3.66 sec.  To eliminate
sampling error, I ran repeatedly, and alternatingly.  Windows 3.4, Mono
3.41, Win 3.3, Mono 3.41, Win 3.3, Mono 3.43

While the mono performance is a little lower, it's not dramatic.

I then set var totals = new List<int>() { 10, 10, 100, 100, 1000 }; to make
the job run longer, and ran again.  Win 32.7, Mono 32.8, Win 32.4, Mono 32.9

Even less dramatic.

I set the totals list back to the original presets.  Deployed the .exe to a
slightly slower windows 7 x86_64 virtual machine with 2 cpu's and 1 g ram,
and also deployed (and recompiled) to a fedora 17 x86_64 machine, mono
2.10.8 installed via yum.  The win & lin machines have identical system
specs, running on the same host hardware.  win 4.9, lin 3.2, win 4.9, lin
3.2, win 4.9, lin 3.2

The most dramatic result we're seeing in any of these tests, is that mono
for linux is significantly faster than .Net for this particular task, while
mono for windows is slightly slower than .Net.  Again, specifically for this
test case in this configuration.  I would not be comfortable generalizing
anything from this.  I bet you'll see different results with different patch
levels of Windows or linux, different versions of .Net, different versions
of mono, different on 32bit vs 64bit hardware, etc.

_______________________________________________

Mono-list maillist  -   <mailto:Mono-list at lists.ximian.com>
Mono-list at lists.ximian.com
<http://lists.ximian.com/mailman/listinfo/mono-list>
http://lists.ximian.com/mailman/listinfo/mono-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-list/attachments/20130312/f7c9e14e/attachment-0001.html>