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

[Jonathan Shore]

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/20131207/578afe61/attachment-0001.html>