[Mono-dev] Mac Boehm CG question

[Tom Philpot]

I reran the revised test case Matteo provided here: https://bugzilla.novell.com/show_bug.cgi?id=402833

Here are the results with NO_PTHREAD_TRYLOCK defined (i.e. before)
ws1048-snow:~ tom.philpot$ /opt/mono/bin/mono Main.exe 
One Thread (method1) time=00:00:00.6318450
One Thread (method2) time=00:00:00.6434430
Two Thread time=00:00:03.7889390
ws1048-snow:~ tom.philpot$ /opt/mono/bin/mono Main.exe 
One Thread (method1) time=00:00:00.6311450
One Thread (method2) time=00:00:00.6421380
Two Thread time=00:00:03.7577420


Here are the results without NO_PTHREAD_TRYLOCK defined (i.e. after)
ws1048-snow:~ tom.philpot$ /opt/mono/bin/mono Main.exe 
One Thread (method1) time=00:00:00.6295460
One Thread (method2) time=00:00:00.6389300
Two Thread time=00:00:00.2641640
ws1048-snow:~ tom.philpot$ /opt/mono/bin/mono Main.exe 
One Thread (method1) time=00:00:00.6306050
One Thread (method2) time=00:00:00.6370260
Two Thread time=00:00:00.2639220

This was on a Mac Pro 2.66 Ghz on 10.6. I haven't run them on 10.5.

Tom

On Jan 25, 2010, at 5:16 PM, matteo tesser wrote:

> Hi,
> about an year ago I posted the following bug
> https://bugzilla.novell.com/show_bug.cgi?id=402833
> because  we realized that the performance problem in our multi-thread
> app was related to memory management:
> 
> By removing the #define line as you proposed, the performance problem
> disappear and bug 402833 seems resolved.
> At the moment I made also some preliminary tests on our multi-thread
> app and performances improve considerably.
> 
> Matteo
> 
> 
> On Mon, Jan 25, 2010 at 10:59 PM, Tom Philpot <tom.philpot at logos.com> wrote:
>> Rodrigo,
>> Thanks for the input. Any of the other Mono/MacOS X folks have an opinion on
>> this change? I've been running our heavily multi-threaded app which embeds
>> Mono and haven't seen any issues. We're going to start removing this #define
>> on our build machine and our dev's Mono installs and see if we can detect
>> any issues since the speed up is so significant in certain cases in our app.
>> Tom
>> 
>> On Jan 22, 2010, at 2:08 PM, Rodrigo Kumpera wrote:
>> 
>> pthread mutexes on OSX are ridiculously slow. So no matter what you do, GC
>> performance will be significantly worse than on linux.
>> But we should check if this change is ok if it does give a nice boost.
>> 
>> 
>> 
>> On Fri, Jan 22, 2010 at 8:05 PM, Tom Philpot <tom.philpot at logos.com> wrote:
>>> 
>>> While investigating some performance problems in our application which
>>> uses the embedded Mono runtime on Mac OS X targeting 10.5 and 10.6, I
>>> noticed that several operations spent an extreme amount of time in GC_lock.
>>> That code lead me back to gcconfig.h where NO_PTHREAD_TRYLOCK is defined.
>>> I've commented out that #define it on my local Mono build and things seem
>>> MUCH faster. In fact I'm now able to do real work on more than 2 threads
>>> without a ton of overhead.
>>> 
>>> The question is now, does this check still need to be there for later
>>> versions of Mac OS X? The original commit was back in August 2003, which was
>>> probably around the timeframe of 10.2 and 10.3 and definitely before the
>>> Intel Macs. Also, since I don't have a PPC to test on, I didn't comment that
>>> #define.
>>> 
>>> 
>>> ws1048-snow:mono tom.philpot$ svn diff libgc/include/private/gcconfig.h
>>> Index: libgc/include/private/gcconfig.h
>>> ===================================================================
>>> --- libgc/include/private/gcconfig.h    (revision 150077)
>>> +++ libgc/include/private/gcconfig.h    (working copy)
>>> @@ -329,7 +329,7 @@
>>>  #    define GETPAGESIZE() getpagesize()
>>>       /* There seems to be some issues with trylock hanging on darwin.
>>> This
>>>          should be looked into some more */
>>> -#     define NO_PTHREAD_TRYLOCK
>>> +//#     define NO_PTHREAD_TRYLOCK
>>>  #   elif defined(__arm__)
>>>  #    define ARM
>>>  #    define mach_type_known
>>> 
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> 
>> 
>> 
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> 
>>