[Mono-list] Poor Mono performance

Tue Mar 12 17:47:39 UTC 2013

Nigel,

Ø  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.

Believe me, I got the point of your previous email, it's all good suggestions. (Although when you think about it, you have to admit it's a bit surreal: "you can speed up your program by NOT using advanced data structures or any function calls"... This may not sit very well for complex commercial grade projects. =)

Ø  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.

That's a very good point.

I appreciate the time you took to look into this! And that goes for everybody else who has contributed to this thread so far, thanks for all your thoughts!

--
Imre

From: Nigel Delaney [via Mono] [mailto:ml-node+s1490590n4658984h23 at n4.nabble.com]
Sent: Tuesday, March 12, 2013 9:55 AM
To: Olajos, Imre
Subject: Re: Poor Mono performance

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: [hidden email]</user/SendEmail.jtp?type=node&node=4658984&i=0> [mailto:[hidden email]</user/SendEmail.jtp?type=node&node=4658984&i=1>] On Behalf Of edward.harvey.mono
Sent: Tuesday, March 12, 2013 10:06 AM
To: imreolajos; [hidden email]</user/SendEmail.jtp?type=node&node=4658984&i=2>
Subject: Re: [Mono-list] Poor Mono performance

> From: [hidden email]</user/SendEmail.jtp?type=node&node=4658984&i=3> [mailto:mono-list-

> [hidden email]</user/SendEmail.jtp?type=node&node=4658984&i=4>] On Behalf Of imreolajos

>

> 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  -  [hidden email]</user/SendEmail.jtp?type=node&node=4658984&i=5> http://lists.ximian.com/mailman/listinfo/mono-list

_______________________________________________
Mono-list maillist  -  [hidden email]</user/SendEmail.jtp?type=node&node=4658984&i=6>
http://lists.ximian.com/mailman/listinfo/mono-list

________________________________
If you reply to this email, your message will be added to the discussion below:
http://mono.1490590.n4.nabble.com/Poor-Mono-performance-tp4658877p4658984.html
To unsubscribe from Poor Mono performance, click here<http://mono.1490590.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4658877&code=aW9sYWpvc0BiYWxseXRlY2guY29tfDQ2NTg4Nzd8OTEzNDI5MDMw>.
NAML<http://mono.1490590.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-list/attachments/20130312/c6bd0fb6/attachment-0001.html>