Ah okay, should also read emails more before responding. Just saw the multiply versus add difference in the order of operations. I just have no idea why you would do so many operations inside the Advance method to effect a simple change, that still seems very strange.
From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of Olajos, Imre Sent: Tuesday, March 12, 2013 12:09 PM To: [email protected] <mailto:[email protected]> Subject: Re: [Mono-list] Poor Mono performance 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:[email protected]] 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] [[hidden email]] On Behalf Of Robert Jordan [[hidden email]] Sent: Monday, March 11, 2013 2:15 PM To: [hidden email] 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] http://lists.ximian.com/mailman/listinfo/mono-list _______________________________________________ Mono-list maillist - [hidden email] 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.ht ml To unsubscribe from Poor Mono performance, click here <http://mono.1490590.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscrib e_by_code&node=4658877&code=aW9sYWpvc0BiYWxseXRlY2guY29tfDQ2NTg4Nzd8OTEzNDI5 MDMw> . <http://mono.1490590.n4.nabble.com/template/NamlServlet.jtp?macro=macro_view er&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNa mespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.No deNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_ema ils%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> NAML
_______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
