[Mono-list] Poor Mono performance
Olajos, Imre
IOlajos at ballytech.com
Tue Mar 12 16:09:21 UTC 2013
Nigel,
Of course, yours runs a lot faster, that's because you've substantially changed the loop: it's not looping through all 10*10*100*100*100 iterations any more, it only does 10+10+100+100+100 iterations now. You're also no longer incrementing 'counter' for each iteration. (My real life code does a lot of object creations and function calls in place of where I put a counter++ in the do-while loop body of my original code.)
--
Imre
From: Nigel Delaney [via Mono] [mailto:ml-node+s1490590n4658944h83 at n4.nabble.com]
Sent: Monday, March 11, 2013 1:14 PM
To: Olajos, Imre
Subject: Re: Poor Mono performance
I played around a bit with this and also noticed a very substantial MS
versus MONO difference, some notes on this:
*The biggest performance difference here is not the mono vs. .NET but rather
how the program is written. Right now the bulk of the code on both Mono and
.NET is spent on the do-while loop, and this is a HUGE waste of repeated
method calls. Every increment of an array element involves a method call,
and I could drop the runtime of the program about two orders of magnitude by
writing a different advance function as shown at the end of this email.
That function can't really be inlined properly by either MS or mono, and the
runtime goes from about 1.9 seconds on my machine to .01 seconds with this
change, though the code does the same thing. If the code you are writing in
practice does look like this, it can be improved a lot by having the called
method not return until a condition is met, rather than returning, checking
the condition, and calling again.
*Strangely, after the code is changed to accommodate this, mono and MS on
my test machine appear to have an unbelievably large difference in speed.
This appears to be "fake" differences due to how the startime variable is
set and nothing to do with the execution speed of the main method. If
starttime is reset inside the method by setting it again after printing it
to the console, the performance difference disappears. There still appears
to be a <2X mono performance penalty when mono is used with a List type, but
with an array for the counters, I seem to get the same results on mono and
ms.
If you try the program below, I would be interested to know if the speed was
equivalent on your machine for mono and .net. One problem is that it is so
fast on both now that it is hard to compare.
-Nigel
PS It would still be nice to have a way to view the emitted assembly code on
windows in mono so could compare with the ms clr.
//improved program
using System;
using System.Collections.Generic;
namespace SpeedTest
{
class SpeedTest
{
static void Main(string[] args)
{
var totals = new int[] { 10, 10, 100, 100, 100 };
var counters = new int[] { 0, 0, 0, 0, 0 }; ;
int counter = 0;
//Variable needs to be set again after printing, otherwise
result is wrong
var startTime = DateTime.Now;
Console.WriteLine("START TIME: {0}", startTime.ToString());
startTime = DateTime.Now;
int total = 1;
for(int i=0;i<totals.Length;i++) {
total*=totals[i];
}
Console.WriteLine("Total = {0}", total);
Console.WriteLine("Dif= {0}", (DateTime.Now -
startTime).ToString());
Advance(counters,totals);
//just to make sure it doesn't avoid the advance method call
Console.WriteLine(counters[2].ToString());
var endTime = DateTime.Now;
Console.WriteLine();
Console.WriteLine("END TIME: {0}", endTime.ToString());
Console.WriteLine("RUN TIME: {0}", (endTime -
startTime).ToString());
Console.ReadLine();
}
static void Advance(int[] current, int[] total)
{
for (int index = current.Length - 1; index >= 0; --index)
{
while(current[index] != (total[index] - 1))
{
++current[index];
}
}
}
}
}
________________________________________
From: [hidden email]</user/SendEmail.jtp?type=node&node=4658944&i=0>
[[hidden email]</user/SendEmail.jtp?type=node&node=4658944&i=1>] On Behalf Of Robert Jordan
[[hidden email]</user/SendEmail.jtp?type=node&node=4658944&i=2>]
Sent: Monday, March 11, 2013 2:15 PM
To: [hidden email]</user/SendEmail.jtp?type=node&node=4658944&i=3>
Subject: Re: [Mono-list] Poor Mono performance
On 11.03.2013 17:19, Olajos, Imre wrote:
> Is there anything I can do that would bring their relative performance
> difference closer to each other (e.g. below 20-25%)?
So you didn't find the well-hidden "--make-me-as-fast-as-ms"
switch, did you? :)
You're comparing MS' 64-bit runtime with a 32-bit Mono w/out LLVM support
and with a pretty slow GC (under Windows).
Since Windows isn't Mono's prime-time OS, you may want to try under 64-bit
Linux (where you can have LLVM and alternative GCs), identify bottlenecks
and file bugs with appropriate test cases.
Robert
_______________________________________________
Mono-list maillist - [hidden email]</user/SendEmail.jtp?type=node&node=4658944&i=4>
http://lists.ximian.com/mailman/listinfo/mono-list
_______________________________________________
Mono-list maillist - [hidden email]</user/SendEmail.jtp?type=node&node=4658944&i=5>
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-tp4658877p4658944.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/90209dbd/attachment-0001.html>
More information about the Mono-list
mailing list