<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 23, 2012, at 7:27 AM, Rodrigo Kumpera wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Mono os OSX has some performance issues due to multiple factors, some Reimer pointed out, but it's hard to tell without a good profiler run.<div><br></div><div>Boehm doesn't support the fast memory allocator on OSX.</div>
<div>The lack of compiler support for fast TLS is another pain point, this has been mostly addressed on trunk so 2.12 will be closer.</div><div>Another issue is that OSX primitives are much worse than linux's. Things like mutex'es and semephores perform much worse.</div>
<div>Finally, the 32 x 64 bits issue can make a huge difference depending on your code. If you're doing a lot of 64bits math or your</div><div>code is register happy, 32bits will be slower.</div><div><br></div></blockquote><div><br></div><div>I see.  I am using a SpinLock around every (very short lived) transaction.   Perhaps the primitives used in SpinWait have a different performance profile on OSX vs Linux?   Also, all of the transactions involve longs and doubles {comparisons, load/store, some arithmetic).   I am not at all clear on how longs and doubles would be rendered differently in terms of instructions on 32bit vs 64bit.    I thought even in the 32bit world, intel CPUs had a 64bit pipeline for doubles, though probably not for longs.   </div><div><br></div><div>What sort of instrumentation would be useful? </div><br><blockquote type="cite"><div>Jonathan, if you could do an Instruments run on osx and perf on linux of your add and send the decoded results, it would help a lot troubleshoot</div>
<div>the issue.</div><div><br></div><div><br><br><div class="gmail_quote">On Sat, Jan 21, 2012 at 5:28 PM, Jonathan Shore <span dir="ltr"><<a href="mailto:jonathan.shore@gmail.com">jonathan.shore@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I am running a program that does millions of transactions on FIFO queues, etc.   Running on my OSX box (which is on a dual CPU / 8 core Xeon E5520) and on a linux box which is a core I7-950, I found a significant performance difference which is difficult to explain.<div>
<br></div><div>On a single threaded run, the OSX based E5520 took 21 seconds to process 8 million "transactions" and the linux box took only 8 seconds.   The i7-950 is marginally faster (~10% faster) in typical benchmarks that the E5520.</div>
<div><br></div><div>Both runs were done with -llvm enabled and with the same garbage collector.    There are probably 16 - 32 million small objects created during the course of this evaluation, but generally with good locality, so should be easy to GC.</div>
<div><br></div><div>The <b>OSX-based mono performance for this app is 3x slower</b> than the linux performance (whereas for typical programs, say in C, the difference would be about 10%).   Both the linux and OSX boxes have significant memory (in fact the OSX box has more memory).</div>
<div><br></div><div>Finally, the OSX version is using 2.10.8 32bit  and the linux version 2.10.6 64bit.  I doubt that there is a retrogression in performance between 2.10.6.  Thinking is more likely to be an implementation difference between OSX and linux?    I would also think that the 32bit vs 64bit would not make all that much difference?</div>
<div><br></div><div>So I am wondering whether there are differences in implementation between mono on these platforms that could account for a significant performance difference?</div><div><br></div><div>Thanks</div><div>
Jonathan</div></div><br>_______________________________________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com">Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></body></html>