Sure.
On Sat, Dec 7, 2013 at 5:02 PM, Jonathan Shore <jonathan.sh...@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 <kump...@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.sh...@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 <kump...@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.sh...@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@lists.ximian.com >>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>> >> >> >> > >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list