[Mono-dev] large performance drop between boehm and sgen for a parallel app

[Rodrigo Kumpera]

Sure.


On Sat, Dec 7, 2013 at 5:02 PM, Jonathan Shore <jonathan.shore at gmail.com>wrote:

> Probably the best thing i can do here is try to scale this problem down so
> that does not depend on external data and post to bugzilla.  Then someone
> can take a look at the pathelogical sgen GC profile.
>
>
> On Dec 7, 2013, at 1:15 PM, Rodrigo Kumpera <kumpera at gmail.com> wrote:
>
> A perf run with sampling profiling and actual traces would be of some use.
>
> If you have a very large heap, you're probably hitting the limitation of
> on the default serial major collector mono uses.
> You could try to run with the parallel major enabled, but that's
> experimental and has not received enough tunning/testing.
>
>
> On Sat, Dec 7, 2013 at 12:38 PM, Jonathan Shore <jonathan.shore at gmail.com>wrote:
>
>> Here are the results for a trimmed down version of the problem:
>>
>> *Boehm (default settings)*
>> Performance counter stats for '/opt/mono-3.0/bin/mono-boehm --llvm
>> /home/jonathan/Dev/hf/lib/Debug/FeatureGeneratorCSVFile.exe -info -config
>> etc/samples/orderbook-2013-CX-V11.xml -out features-2013-CX.csv':
>>
>>    48579862.522506 task-clock                #    *9.034* CPUs utilized
>>
>>        188,866,824 context-switches          #    0.004 M/sec
>>
>>             46,500 CPU-migrations            #    0.000 M/sec
>>
>>          1,475,427 page-faults               #    0.000 M/sec
>>
>> 140,468,865,368,193 cycles                    #    2.892 GHz
>>
>>    <not supported> stalled-cycles-frontend
>>    <not supported> stalled-cycles-backend
>> 80,012,982,451,027 instructions              #    0.57  insns per cycle
>>
>> 16,967,686,291,478 branches                  #  349.274 M/sec
>>
>>     95,315,728,420 branch-misses             #    0.56% of all branches
>>
>>
>>     *5377*.495775794 seconds time elapsed
>>
>> *SGen (default settings)*
>> Performance counter stats for '/opt/mono-3.0/bin/mono-sgen --llvm
>> /home/jonathan/Dev/hf/lib/Debug/FeatureGeneratorCSVFile.exe -info -config
>> etc/samples/orderbook-2013-CX-V11.xml -out features-2013-CX.csv':
>>
>>   108414200.651113 task-clock                #    *2.049* CPUs utilized
>>
>>         65,792,604 context-switches          #    0.001 M/sec
>>
>>             30,536 CPU-migrations            #    0.000 M/sec
>>
>>        309,928,477 page-faults               #    0.003 M/sec
>>
>> 263,506,866,481,917 cycles                   #    2.431 GHz
>>
>>    <not supported> stalled-cycles-frontend
>>    <not supported> stalled-cycles-backend
>> 130,560,004,191,686 instructions             #    0.50  insns per cycle
>>
>> 27,570,367,199,486 branches                  #  254.306 M/sec
>>
>>    382,673,241,515 branch-misses             #    1.39% of all branches
>>
>>
>>    *52912.*358974732 seconds time elapsed
>>
>> There is a nearly 10x difference in performance between these.  Both were
>> run on 10 cores.   The boehm version achieved a 9 cpu average and the sgen
>> achieved a 2 cpu average + more overhead.
>>
>>
>> On Dec 5, 2013, at 12:48 PM, Rodrigo Kumpera <kumpera at gmail.com> wrote:
>>
>> Are you running boehm in parallel mode? Can you run perf on your
>> application and email us the translated results?
>>
>>
>> On Thu, Dec 5, 2013 at 11:11 AM, Jonathan Shore <jonathan.shore at gmail.com
>> > wrote:
>>
>>> Hi,
>>>
>>> I have a complex parallel application which, when run on 10 threads gets
>>> very close to 1000% cpu with mono-boehm (linux) consistently (running for
>>> hours).   With mono-sgen only achieves  200 - 250% cpu.   This is on a 12 /
>>> 24 core machine.   I need to run sgen eventually because run into the 32
>>> bit limit with boehm from time to time.
>>>
>>> Note that this is with a fairly recent version of mono compiled from git
>>> sources with llvm enabled.
>>>
>>> It is not an application I can easily box up for analysis on bugzilla
>>> due to size of data context, though happy to provide an enviroment to the
>>> mono team if useful.  Wondering whether there is some GC debugging can turn
>>> on that is useful to the mono team?
>>>
>>> Thanks
>>> Jonathan
>>>
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20131208/bdabaab9/attachment.html>