* [Caml-list] Behaviour of an OCaml program: any possible GC improvement?
@ 2012-10-24 10:08 David MENTRE
2012-10-24 10:33 ` John Whitington
2012-10-24 10:38 ` Török Edwin
0 siblings, 2 replies; 20+ messages in thread
From: David MENTRE @ 2012-10-24 10:08 UTC (permalink / raw)
To: caml users
Hello,
I'm using OCaml 3.11.2 on Linux (Debian Squeeze 6.0) x86_64 platform.
I have a program that exhibits the following gprof profile. A lot of
time is spent in the GC (more than 56 %). Is there anything I can do
with respect to the GC? Otherwise, this program is a typical symbolic
manipulation program, handling trees made of Sum types and small lists
of them (1 to 3 elements).
"""
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls s/call s/call name
35.95 190.95 190.95 279963 0.00 0.00 mark_slice
19.63 295.22 104.27 477027 0.00 0.00 sweep_slice
9.79 347.23 52.01 88113 0.00 0.00 camlMap__map_181
6.72 382.95 35.72 3712176346 0.00 0.00 caml_page_table_lookup
6.23 416.06 33.11 756990 0.00 0.00 caml_oldify_mopup
4.60 440.47 24.41 3919716797 0.00 0.00 caml_fl_allocate
3.92 461.31 20.84 3925371187 0.00 0.00 caml_oldify_one
3.06 477.56 16.25 4125151093 0.00 0.00 caml_fl_merge_block
2.56 491.15 13.59 3919716670 0.00 0.00 caml_alloc_shr
1.44 498.82 7.67 3882908903 0.00 0.00
camlData_typing__apply_269
1.31 505.78 6.96 3919716670 0.00 0.00 allocate_block
1.14 511.81 6.03 1 6.03 6.03 caml_realloc_ref_table
0.69 515.45 3.64 3897784282 0.00 0.00 caml_curry2_1
0.43 517.76 2.31 caml_set_allocation_policy
0.41 519.96 2.20 1513980 0.00 0.00 clear_table
0.40 522.09 2.13 caml_fl_reset
0.34 523.90 1.81 74 0.02 0.02 camlMap__iter_175
0.23 525.11 1.21 7109929 0.00 0.00 caml_gc_message
0.19 526.14 1.04 127 0.01 0.01 caml_add_to_heap
0.17 527.04 0.89 756990 0.00 0.00 caml_oldify_local_roots
0.11 527.61 0.57 8826439 0.00 0.00 caml_curry2
0.05 527.90 0.29
camlData_typing__print_vset_177
0.03 528.07 0.17 5946696 0.00 0.00 camlFormat__kpr_643
0.03 528.22 0.15 10355866 0.00 0.00 camlFormat__doprn_654
0.03 528.36 0.14 10179867 0.00 0.00
camlFormat__advance_loop_299
0.02 528.47 0.11 95566619 0.00 0.00 caml_modify
0.02 528.57 0.11 26632458 0.00 0.00 camlFormat__peek_queue_214
0.02 528.68 0.11 16452591 0.00 0.00
camlFormat__format_pp_token_255
0.02 528.78 0.10 15479410 0.00 0.00 caml_putblock
0.02 528.88 0.10 15457716 0.00 0.00 camlPervasives__output_218
0.02 528.96 0.08 caml_c_call
[ ... snipped all functions <= 0.01 % ... ]
Best regards,
david
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Caml-list] Behaviour of an OCaml program: any possible GC improvement?
2012-10-24 10:08 [Caml-list] Behaviour of an OCaml program: any possible GC improvement? David MENTRE
@ 2012-10-24 10:33 ` John Whitington
2012-10-24 12:30 ` David MENTRE
2012-10-24 10:38 ` Török Edwin
1 sibling, 1 reply; 20+ messages in thread
From: John Whitington @ 2012-10-24 10:33 UTC (permalink / raw)
To: David MENTRE; +Cc: caml users
Hi David,
David MENTRE wrote:
> Hello,
>
> I'm using OCaml 3.11.2 on Linux (Debian Squeeze 6.0) x86_64 platform.
>
> I have a program that exhibits the following gprof profile. A lot of
> time is spent in the GC (more than 56 %). Is there anything I can do
> with respect to the GC? Otherwise, this program is a typical symbolic
> manipulation program, handling trees made of Sum types and small lists
> of them (1 to 3 elements).
Can you supply the section under "caml_call_gc"? For example:
> 0.00 0.03 1/4988 camlPdfutil__fun_2922 [136]
> 0.00 0.03 1/4988 camlPdfutil__takewhile_reverse_inner_1655 [133]
> 0.00 0.03 1/4988 camlPdfutil__ilist_1873 [135]
> 0.00 0.03 1/4988 camlPdf__x1_1414 [130]
> 0.00 0.03 1/4988 camlPdfread__lex_object_at_1344 [132]
> 0.00 0.03 1/4988 camlPdfread__process_parse_dictionary_1440 [103]
> 0.00 0.03 1/4988 camlPdfread__parse_dictionary_1451 <cycle 1> [97]
> 0.00 0.03 1/4988 camlPdfread__parse_to_tree_1473 <cycle 1> [131]
> 0.00 0.03 1/4988 camlHashtbl__insert_bucket_1068 [129]
> 0.00 0.07 2/4988 camlPdfwrite__fun_1642 <cycle 1> [110]
> 0.00 0.07 2/4988 camlPdfread__mkpairs_1442 [112]
> 0.00 0.07 2/4988 camlPdfread__fun_2689 <cycle 1> [111]
> 0.00 0.10 3/4988 camlPdfread__lex_name_1217 <cycle 1> [92]
> 0.00 0.14 4/4988 camlPdf__fun_1934 [98]
> 0.00 0.14 4/4988 camlHashtbl__replace_1112 [96]
> 0.00 1.93 56/4988 camlPdfread__lex_string_1230 [32]
> 0.00 2.93 85/4988 camlPdfwrite__strings_of_pdf_1131 <cycle 1> [24]
> 0.00 3.79 110/4988 camlPdfread__lex_number_1211 [28]
> 0.00 5.10 148/4988 camlPdfgenlex__lex_item_1109 [45]
> 0.00 8.86 257/4988 camlHashtbl__mem_1122 [42]
> 0.00 13.24 384/4988 camlPdfread__parse_array_1452 <cycle 1> [35]
> 0.00 13.34 387/4988 camlList__rmap_f_1070 <cycle 1> [34]
> 0.00 31.34 909/4988 camlPdfread__parse_R_inner_1422 [26]
> 0.00 40.23 1167/4988 camlList__rev_append_1051 [23]
> 0.00 50.30 1459/4988 camlPdfread__lex_object_at_1352 <cycle 1> [21]
> [7] 65.5 0.00 171.97 4988 caml_call_gc [7]
> 0.00 171.97 4988/4988 caml_garbage_collection [8]
This is usually a good starting point.
Thanks,
--
John Whitington
Director, Coherent Graphics Ltd
http://www.coherentpdf.com/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Caml-list] Behaviour of an OCaml program: any possible GC improvement?
2012-10-24 10:08 [Caml-list] Behaviour of an OCaml program: any possible GC improvement? David MENTRE
2012-10-24 10:33 ` John Whitington
@ 2012-10-24 10:38 ` Török Edwin
2012-10-25 10:06 ` David MENTRE
1 sibling, 1 reply; 20+ messages in thread
From: Török Edwin @ 2012-10-24 10:38 UTC (permalink / raw)
To: caml-list
On 10/24/2012 01:08 PM, David MENTRE wrote:
> Hello,
>
> I'm using OCaml 3.11.2 on Linux (Debian Squeeze 6.0) x86_64 platform.
>
> I have a program that exhibits the following gprof profile. A lot of
> time is spent in the GC (more than 56 %). Is there anything I can do
> with respect to the GC? Otherwise, this program is a typical symbolic
> manipulation program, handling trees made of Sum types and small lists
> of them (1 to 3 elements).
You can try tuning the Gc parameters:
http://caml.inria.fr/pub/docs/old-311/libref/Gc.html
Try increasing minor_heap_size, and major_heap_increment and see if there is any improvement.
Also look at Gc.stat() and see how many major collections and live words you have.
--Edwin
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Caml-list] Behaviour of an OCaml program: any possible GC improvement?
2012-10-24 10:33 ` John Whitington
@ 2012-10-24 12:30 ` David MENTRE
2012-10-24 12:39 ` John Whitington
0 siblings, 1 reply; 20+ messages in thread
From: David MENTRE @ 2012-10-24 12:30 UTC (permalink / raw)
To: John Whitington; +Cc: caml users
Hello,
2012/10/24 John Whitington <john@coherentgraphics.co.uk>:
> Can you supply the section under "caml_call_gc"?
Here it is:
"""
index % time self children called name
0.00 0.00 1/756990 caml_check_urgent_gc [217]
0.00 0.09 152/756990 caml_alloc_small [72]
0.00 0.81 1353/756990 caml_alloc_string [49]
0.00 449.61 755484/756990 caml_garbage_collection [3]
[1] 84.8 0.00 450.50 756990 caml_minor_collection [1]
0.07 347.04 756990/756990 caml_major_collection_slice [4]
0.03 103.37 1513980/1513980 caml_empty_minor_heap [7]
0.00 0.00 756990/756990 caml_final_do_calls [335]
-----------------------------------------------
<spontaneous>
[2] 84.6 0.03 449.61 caml_call_gc [2]
0.00 449.61 755484/755484 caml_garbage_collection [3]
-----------------------------------------------
0.00 449.61 755484/755484 caml_call_gc [2]
[3] 84.6 0.00 449.61 755484 caml_garbage_collection [3]
0.00 449.61 755484/756990 caml_minor_collection [1]
0.00 0.00 755484/810852
caml_process_pending_signals [334]
-----------------------------------------------
0.07 347.04 756990/756990 caml_minor_collection [1]
[4] 65.3 0.07 347.04 756990 caml_major_collection_slice [4]
190.95 34.61 279963/279963 mark_slice [5]
104.27 16.33 477027/477027 sweep_slice [6]
0.77 0.00 4541940/7109929 caml_gc_message [44]
0.00 0.10 5644/5644 start_cycle [77]
0.00 0.00 5643/5643 caml_compact_heap_maybe [201]
-----------------------------------------------
190.95 34.61 279963/279963 caml_major_collection_slice [4]
[5] 42.5 190.95 34.61 279963 mark_slice [5]
34.52 0.00 3587324874/3712176346
caml_page_table_lookup [16]
0.10 0.00 559926/7109929 caml_gc_message [44]
0.00 0.00 1/1 realloc_gray_vals [293]
0.00 0.00 5643/5643 caml_final_update [382]
0.00 0.00 5643/5644 caml_fl_init_merge [381]
-----------------------------------------------
104.27 16.33 477027/477027 caml_major_collection_slice [4]
[6] 22.7 104.27 16.33 477027 sweep_slice [6]
16.25 0.00 4125151092/4125151093 caml_fl_merge_block [18]
0.08 0.00 477027/7109929 caml_gc_message [44]
0.00 0.00 1/1 caml_finalize_channel [489]
-----------------------------------------------
0.03 103.37 1513980/1513980 caml_minor_collection [1]
[7] 19.5 0.03 103.37 1513980 caml_empty_minor_heap [7]
33.11 66.54 756990/756990 caml_oldify_mopup [8]
2.20 0.00 1513980/1513980 clear_table [31]
0.89 0.20 756990/756990 caml_oldify_local_roots [47]
0.26 0.00 1513980/7109929 caml_gc_message [44]
0.05 0.11 9737302/3925371187 caml_oldify_one [10]
0.00 0.00 1513980/1513980 caml_final_empty_young [330]
-----------------------------------------------
33.11 66.54 756990/756990 caml_empty_minor_heap [7]
[8] 18.8 33.11 66.54 756990 caml_oldify_mopup [8]
20.75 45.79 3908232537/3925371187 caml_oldify_one [10]
[...]
"""
Best regards,
d.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Caml-list] Behaviour of an OCaml program: any possible GC improvement?
2012-10-24 12:30 ` David MENTRE
@ 2012-10-24 12:39 ` John Whitington
2012-10-24 12:45 ` Edgar Friendly
2012-10-24 13:19 ` David MENTRE
0 siblings, 2 replies; 20+ messages in thread
From: John Whitington @ 2012-10-24 12:39 UTC (permalink / raw)
To: David MENTRE; +Cc: caml users
Hi,
David MENTRE wrote:
> Hello,
>
> 2012/10/24 John Whitington<john@coherentgraphics.co.uk>:
>> Can you supply the section under "caml_call_gc"?
> <spontaneous>
> [2] 84.6 0.03 449.61 caml_call_gc [2]
> 0.00 449.61 755484/755484 caml_garbage_collection [3]
<spontaneous> means gprof can't find the calling function(s). Are you
sure you've used the -p both for compiling all source files and also
when linking them into the final executable?
--
John Whitington
Director, Coherent Graphics Ltd
http://www.coherentpdf.com/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Caml-list] Behaviour of an OCaml program: any possible GC improvement?
2012-10-24 12:39 ` John Whitington
@ 2012-10-24 12:45 ` Edgar Friendly
2012-10-24 12:53 ` John Whitington
2012-10-24 13:19 ` David MENTRE
1 sibling, 1 reply; 20+ messages in thread
From: Edgar Friendly @ 2012-10-24 12:45 UTC (permalink / raw)
To: caml-list
On 10/24/2012 8:39 AM, John Whitington wrote:
> David MENTRE wrote:
>> <spontaneous>
>> [2] 84.6 0.03 449.61 caml_call_gc [2]
>> 0.00 449.61 755484/755484 caml_garbage_collection [3]
> <spontaneous> means gprof can't find the calling function(s). Are you
> sure you've used the -p both for compiling all source files and also
> when linking them into the final executable?
This line in the original profile might explain:
> 9.79 347.23 52.01 88113 0.00 0.00 camlMap__map_181
I'm guessing there's a lot of calls to Map.map, and this is causing all
the garbage. As part of the stdlib, it wouldn't automatically be
compiled for profiling, no?
E.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Caml-list] Behaviour of an OCaml program: any possible GC improvement?
2012-10-24 12:45 ` Edgar Friendly
@ 2012-10-24 12:53 ` John Whitington
0 siblings, 0 replies; 20+ messages in thread
From: John Whitington @ 2012-10-24 12:53 UTC (permalink / raw)
To: Edgar Friendly; +Cc: caml-list
Hi,
Edgar Friendly wrote:
> On 10/24/2012 8:39 AM, John Whitington wrote:
>> David MENTRE wrote:
>>> <spontaneous>
>>> [2] 84.6 0.03 449.61 caml_call_gc [2]
>>> 0.00 449.61 755484/755484 caml_garbage_collection [3]
>> <spontaneous> means gprof can't find the calling function(s). Are you
>> sure you've used the -p both for compiling all source files and also
>> when linking them into the final executable?
>
> This line in the original profile might explain:
>> 9.79 347.23 52.01 88113 0.00 0.00 camlMap__map_181
> I'm guessing there's a lot of calls to Map.map, and this is causing all
> the garbage. As part of the stdlib, it wouldn't automatically be
> compiled for profiling, no?
You would expect to see some calls to caml_call_gc from functions in
David's code (statistically, some allocations triggering gc would come
from the user code).
So just <spontaneous> for the whole thing is very suspicious, especially
for long-running code - see all the 1/4988 etc. lines in my original
example.
--
John Whitington
Director, Coherent Graphics Ltd
http://www.coherentpdf.com/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Caml-list] Behaviour of an OCaml program: any possible GC improvement?
2012-10-24 12:39 ` John Whitington
2012-10-24 12:45 ` Edgar Friendly
@ 2012-10-24 13:19 ` David MENTRE
2012-10-24 13:27 ` John Whitington
2012-10-24 13:38 ` Oliver Bandel
1 sibling, 2 replies; 20+ messages in thread
From: David MENTRE @ 2012-10-24 13:19 UTC (permalink / raw)
To: John Whitington; +Cc: caml users
2012/10/24 John Whitington <john@coherentgraphics.co.uk>:
> <spontaneous> means gprof can't find the calling function(s).
:-(
> Are you sure
> you've used the -p both for compiling all source files and also when linking
> them into the final executable?
I just checked. Yes, I'm using -p for both compilation and linking.
Would it be due to my old ocaml version?
Best regards,
d.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Caml-list] Behaviour of an OCaml program: any possible GC improvement?
2012-10-24 13:19 ` David MENTRE
@ 2012-10-24 13:27 ` John Whitington
2012-10-24 13:38 ` Oliver Bandel
1 sibling, 0 replies; 20+ messages in thread
From: John Whitington @ 2012-10-24 13:27 UTC (permalink / raw)
To: David MENTRE; +Cc: caml users
Hi David,
David MENTRE wrote:
> 2012/10/24 John Whitington<john@coherentgraphics.co.uk>:
>> <spontaneous> means gprof can't find the calling function(s).
>
> :-(
>
>> Are you sure
>> you've used the -p both for compiling all source files and also when linking
>> them into the final executable?
>
> I just checked. Yes, I'm using -p for both compilation and linking.
> Would it be due to my old ocaml version?
On Linux, profiling with gprof has worked for a long time, so I doubt
it. I'm afraid I have no other suggestions.
Gprof on Mac OS X doesn't seem to work with modern versions of the XCode
tool chain. There is something called "instruments" instead, but I've
not investigated it - I build on linux to profile.
--
John Whitington
Director, Coherent Graphics Ltd
http://www.coherentpdf.com/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Caml-list] Behaviour of an OCaml program: any possible GC improvement?
2012-10-24 13:19 ` David MENTRE
2012-10-24 13:27 ` John Whitington
@ 2012-10-24 13:38 ` Oliver Bandel
2012-10-24 14:30 ` David MENTRE
1 sibling, 1 reply; 20+ messages in thread
From: Oliver Bandel @ 2012-10-24 13:38 UTC (permalink / raw)
To: caml users
Am 24.10.2012 um 15:19 schrieb David MENTRE <dmentre@linux-france.org>:
> 2012/10/24 John Whitington <john@coherentgraphics.co.uk>:
>> <spontaneous> means gprof can't find the calling function(s).
>
> :-(
>
>> Are you sure
>> you've used the -p both for compiling all source files and also when linking
>> them into the final executable?
>
> I just checked. Yes, I'm using -p for both compilation and linking.
And did you touched all your ml files after activating these switches?
Not, that you recompiled only some of the files... and the others
were compiled before adding -p switch?
Ciao,
Oliver
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Caml-list] Behaviour of an OCaml program: any possible GC improvement?
2012-10-24 13:38 ` Oliver Bandel
@ 2012-10-24 14:30 ` David MENTRE
2012-10-24 15:09 ` David MENTRE
0 siblings, 1 reply; 20+ messages in thread
From: David MENTRE @ 2012-10-24 14:30 UTC (permalink / raw)
To: Oliver Bandel; +Cc: caml users
Hello Oliver and John,
2012/10/24 Oliver Bandel <oliver@first.in-berlin.de>:
>>> Are you sure
>>> you've used the -p both for compiling all source files and also when linking
>>> them into the final executable?
>>
>> I just checked. Yes, I'm using -p for both compilation and linking.
>
> And did you touched all your ml files after activating these switches?
> Not, that you recompiled only some of the files... and the others
> were compiled before adding -p switch?
Yes but... OK, found it! I was compiling .mli files with ocamlc
instead of ocamlopt -p.
But, after recompiling everything from scratch and redoing my tests
(taking care of erasing old gmon.out file), I have the same result
(with <spontaneous> calling caml_call_gc). :-(
Best regards,
d.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Caml-list] Behaviour of an OCaml program: any possible GC improvement?
2012-10-24 14:30 ` David MENTRE
@ 2012-10-24 15:09 ` David MENTRE
2012-10-24 16:07 ` AW: " Gerd Stolpmann
[not found] ` <1351094817.12207.11@samsung>
0 siblings, 2 replies; 20+ messages in thread
From: David MENTRE @ 2012-10-24 15:09 UTC (permalink / raw)
To: Oliver Bandel; +Cc: caml users
Hello,
2012/10/24 David MENTRE <dmentre@linux-france.org>:
> But, after recompiling everything from scratch and redoing my tests
> (taking care of erasing old gmon.out file), I have the same result
> (with <spontaneous> calling caml_call_gc). :-(
For the sake of completeness, I installed latest OCaml 4.00.1 (for the
recall, Linux x86_64 platform), recompiled everything from scratch and
re-did my tests. I obtain roughly the same results and the same
<spontaneous> calling caml_call_gc. :-(
There should be something obvious that I missed.
"""
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls s/call s/call name
32.54 155.97 155.97 35791 0.00 0.01 mark_slice
19.87 251.24 95.26 58230 0.00 0.00 sweep_slice
12.35 310.42 59.18 88113 0.00 0.00 camlMap__map_1150
6.66 342.34 31.92 94021 0.00 0.00 caml_oldify_mopup
6.57 373.81 31.47 1986040761 0.00 0.00 caml_page_table_lookup
4.66 396.17 22.36 3792214394 0.00 0.00 caml_fl_allocate
4.33 416.94 20.77 3799622226 0.00 0.00 caml_oldify_one
3.39 433.18 16.24 3873315118 0.00 0.00 caml_fl_merge_block
2.51 445.20 12.03 3792214239 0.00 0.00 caml_alloc_shr
1.38 451.83 6.63 3882908903 0.00 0.00
camlData_typing__apply_1255
1.26 457.88 6.05 3792214239 0.00 0.00 allocate_block
1.20 463.62 5.74 1 5.74 5.74 caml_realloc_ref_table
0.49 465.99 2.37 188042 0.00 0.00 clear_table
0.44 468.09 2.10 3881730105 0.00 0.00
camlData_typing__fun_1445
0.42 470.08 1.99 caml_fl_reset
0.31 471.57 1.50 caml_set_allocation_policy
0.28 472.90 1.33 896098 0.00 0.00 caml_gc_message
0.24 474.06 1.16 74 0.02 0.02 camlMap__iter_1144
0.22 475.12 1.06 155 0.01 0.01 caml_add_to_heap
0.11 475.64 0.53 camlData_typing__fun_1430
0.07 475.98 0.34
camlData_typing__print_vset_1115
0.06 476.29 0.31 94021 0.00 0.00 caml_oldify_local_roots
0.04 476.46 0.17 10355866 0.00 0.00 camlFormat__doprn_1525
0.03 476.61 0.15 95566109 0.00 0.00 caml_modify
0.03 476.74 0.13 5946696 0.00 0.00 camlFormat__kpr_1514
0.03 476.86 0.12 10179867 0.00 0.00
camlFormat__advance_loop_1173
0.02 476.97 0.11 16452591 0.00 0.00
camlFormat__format_pp_token_1134
0.02 477.05 0.08 15459066 0.00 0.00 caml_putblock
0.02 477.13 0.08 16452612 0.00 0.00 camlFormat__add_queue_1087
[...]
granularity: each sample hit covers 2 byte(s) for 0.00% of 479.32 seconds
index % time self children called name
0.00 0.11 25/94021 caml_alloc_small [75]
0.00 0.56 133/94021 caml_alloc_string [51]
0.02 394.48 93863/94021 caml_garbage_collection [3]
[1] 82.4 0.02 395.15 94021 caml_minor_collection [1]
0.02 297.93 94021/94021 caml_major_collection_slice [4]
0.01 97.19 188042/188042 caml_empty_minor_heap [7]
0.00 0.00 94021/94021 caml_final_do_calls [353]
-----------------------------------------------
<spontaneous>
[2] 82.3 0.04 394.50 caml_call_gc [2]
0.00 394.50 93863/93863 caml_garbage_collection [3]
-----------------------------------------------
0.00 394.50 93863/93863 caml_call_gc [2]
[3] 82.3 0.00 394.50 93863 caml_garbage_collection [3]
0.02 394.48 93863/94021 caml_minor_collection [1]
0.00 0.00 93863/97401
caml_process_pending_signals [352]
-----------------------------------------------
0.02 297.93 94021/94021 caml_minor_collection [1]
[4] 62.2 0.02 297.93 94021 caml_major_collection_slice [4]
155.97 29.41 35791/35791 mark_slice [5]
95.26 16.33 58230/58230 sweep_slice [6]
0.84 0.00 564126/896098 caml_gc_message [43]
0.00 0.10 4652/4652 start_cycle [76]
0.00 0.01 4651/4651 caml_compact_heap_maybe [135]
-----------------------------------------------
155.97 29.41 35791/35791 caml_major_collection_slice [4]
[5] 38.7 155.97 29.41 35791 mark_slice [5]
29.31 0.00 1849494323/1986040761
caml_page_table_lookup [16]
0.11 0.00 71582/896098 caml_gc_message [43]
0.00 0.00 1/1 realloc_gray_vals [269]
0.00 0.00 4652/4652 caml_final_update [377]
0.00 0.00 4652/4653 caml_fl_init_merge [375]
-----------------------------------------------
95.26 16.33 58230/58230 caml_major_collection_slice [4]
[6] 23.3 95.26 16.33 58230 sweep_slice [6]
16.24 0.00 3873315117/3873315118 caml_fl_merge_block [18]
0.09 0.00 58230/896098 caml_gc_message [43]
0.00 0.00 1/1 caml_finalize_channel [477]
-----------------------------------------------
0.01 97.19 188042/188042 caml_minor_collection [1]
[7] 20.3 0.01 97.19 188042 caml_empty_minor_heap [7]
31.92 62.08 94021/94021 caml_oldify_mopup [8]
2.37 0.00 188042/188042 clear_table [29]
0.31 0.07 94021/94021 caml_oldify_local_roots [58]
0.28 0.00 188042/896098 caml_gc_message [43]
0.05 0.10 9383144/3799622226 caml_oldify_one [14]
0.00 0.00 188042/188042 caml_final_empty_young [344]
-----------------------------------------------
31.92 62.08 94021/94021 caml_empty_minor_heap [7]
[8] 19.6 31.92 62.08 94021 caml_oldify_mopup [8]
20.71 41.37 3787931806/3799622226 caml_oldify_one [14]
-----------------------------------------------
[...]
"""
Best regards,
david
^ permalink raw reply [flat|nested] 20+ messages in thread
* AW: [Caml-list] Behaviour of an OCaml program: any possible GC improvement?
2012-10-24 15:09 ` David MENTRE
@ 2012-10-24 16:07 ` Gerd Stolpmann
2012-10-24 17:23 ` Martin Jambon
[not found] ` <1351094817.12207.11@samsung>
1 sibling, 1 reply; 20+ messages in thread
From: Gerd Stolpmann @ 2012-10-24 16:07 UTC (permalink / raw)
To: David MENTRE; +Cc: Oliver Bandel, caml users
I don't think you can do much here by just setting parameters. (Btw.,
there is no need to compile the mli's with -p.)
I've seen high CPU for garbage collection frequently for mainly
functional programs. It's their nature - you generate lots of
short-living intermediate results. You can change that only by changing
the algorithm, e.g. by caching results that would otherwise be
recomputed again. Some improvement is also possible with simple tricks,
e.g. if you have something like
Number 0
where Number is from an algebraic type, and you use this term
frequently, consider to add a constant for it,
let n0 = Number 0
so this isn't reallocated all the time (even: if n=0 then n0 else
Number n). If this term is used often, this makes a noticeable
difference.
Gerd
Am 24.10.2012 17:09:12 schrieb(en) David MENTRE:
> Hello,
>
> 2012/10/24 David MENTRE <dmentre@linux-france.org>:
> > But, after recompiling everything from scratch and redoing my tests
> > (taking care of erasing old gmon.out file), I have the same result
> > (with <spontaneous> calling caml_call_gc). :-(
>
> For the sake of completeness, I installed latest OCaml 4.00.1 (for the
> recall, Linux x86_64 platform), recompiled everything from scratch and
> re-did my tests. I obtain roughly the same results and the same
> <spontaneous> calling caml_call_gc. :-(
>
> There should be something obvious that I missed.
>
> """
> Flat profile:
>
> Each sample counts as 0.01 seconds.
> % cumulative self self total
> time seconds seconds calls s/call s/call name
> 32.54 155.97 155.97 35791 0.00 0.01 mark_slice
> 19.87 251.24 95.26 58230 0.00 0.00 sweep_slice
> 12.35 310.42 59.18 88113 0.00 0.00
> camlMap__map_1150
> 6.66 342.34 31.92 94021 0.00 0.00
> caml_oldify_mopup
> 6.57 373.81 31.47 1986040761 0.00 0.00
> caml_page_table_lookup
> 4.66 396.17 22.36 3792214394 0.00 0.00
> caml_fl_allocate
> 4.33 416.94 20.77 3799622226 0.00 0.00
> caml_oldify_one
> 3.39 433.18 16.24 3873315118 0.00 0.00
> caml_fl_merge_block
> 2.51 445.20 12.03 3792214239 0.00 0.00 caml_alloc_shr
> 1.38 451.83 6.63 3882908903 0.00 0.00
> camlData_typing__apply_1255
> 1.26 457.88 6.05 3792214239 0.00 0.00 allocate_block
> 1.20 463.62 5.74 1 5.74 5.74
> caml_realloc_ref_table
> 0.49 465.99 2.37 188042 0.00 0.00 clear_table
> 0.44 468.09 2.10 3881730105 0.00 0.00
> camlData_typing__fun_1445
> 0.42 470.08 1.99 caml_fl_reset
> 0.31 471.57 1.50
> caml_set_allocation_policy
> 0.28 472.90 1.33 896098 0.00 0.00 caml_gc_message
> 0.24 474.06 1.16 74 0.02 0.02
> camlMap__iter_1144
> 0.22 475.12 1.06 155 0.01 0.01 caml_add_to_heap
> 0.11 475.64 0.53
> camlData_typing__fun_1430
> 0.07 475.98 0.34
> camlData_typing__print_vset_1115
> 0.06 476.29 0.31 94021 0.00 0.00
> caml_oldify_local_roots
> 0.04 476.46 0.17 10355866 0.00 0.00
> camlFormat__doprn_1525
> 0.03 476.61 0.15 95566109 0.00 0.00 caml_modify
> 0.03 476.74 0.13 5946696 0.00 0.00
> camlFormat__kpr_1514
> 0.03 476.86 0.12 10179867 0.00 0.00
> camlFormat__advance_loop_1173
> 0.02 476.97 0.11 16452591 0.00 0.00
> camlFormat__format_pp_token_1134
> 0.02 477.05 0.08 15459066 0.00 0.00 caml_putblock
> 0.02 477.13 0.08 16452612 0.00 0.00
> camlFormat__add_queue_1087
> [...]
> granularity: each sample hit covers 2 byte(s) for 0.00% of 479.32
> seconds
>
> index % time self children called name
> 0.00 0.11 25/94021 caml_alloc_small [75]
> 0.00 0.56 133/94021 caml_alloc_string
> [51]
> 0.02 394.48 93863/94021
> caml_garbage_collection [3]
> [1] 82.4 0.02 395.15 94021 caml_minor_collection [1]
> 0.02 297.93 94021/94021
> caml_major_collection_slice [4]
> 0.01 97.19 188042/188042
> caml_empty_minor_heap [7]
> 0.00 0.00 94021/94021 caml_final_do_calls
> [353]
> -----------------------------------------------
> <spontaneous>
> [2] 82.3 0.04 394.50 caml_call_gc [2]
> 0.00 394.50 93863/93863
> caml_garbage_collection [3]
> -----------------------------------------------
> 0.00 394.50 93863/93863 caml_call_gc [2]
> [3] 82.3 0.00 394.50 93863 caml_garbage_collection
> [3]
> 0.02 394.48 93863/94021
> caml_minor_collection [1]
> 0.00 0.00 93863/97401
> caml_process_pending_signals [352]
> -----------------------------------------------
> 0.02 297.93 94021/94021
> caml_minor_collection [1]
> [4] 62.2 0.02 297.93 94021
> caml_major_collection_slice [4]
> 155.97 29.41 35791/35791 mark_slice [5]
> 95.26 16.33 58230/58230 sweep_slice [6]
> 0.84 0.00 564126/896098 caml_gc_message [43]
> 0.00 0.10 4652/4652 start_cycle [76]
> 0.00 0.01 4651/4651
> caml_compact_heap_maybe [135]
> -----------------------------------------------
> 155.97 29.41 35791/35791
> caml_major_collection_slice [4]
> [5] 38.7 155.97 29.41 35791 mark_slice [5]
> 29.31 0.00 1849494323/1986040761
> caml_page_table_lookup [16]
> 0.11 0.00 71582/896098 caml_gc_message [43]
> 0.00 0.00 1/1 realloc_gray_vals
> [269]
> 0.00 0.00 4652/4652 caml_final_update
> [377]
> 0.00 0.00 4652/4653 caml_fl_init_merge
> [375]
> -----------------------------------------------
> 95.26 16.33 58230/58230
> caml_major_collection_slice [4]
> [6] 23.3 95.26 16.33 58230 sweep_slice [6]
> 16.24 0.00 3873315117/3873315118
> caml_fl_merge_block [18]
> 0.09 0.00 58230/896098 caml_gc_message [43]
> 0.00 0.00 1/1
> caml_finalize_channel [477]
> -----------------------------------------------
> 0.01 97.19 188042/188042
> caml_minor_collection [1]
> [7] 20.3 0.01 97.19 188042 caml_empty_minor_heap [7]
> 31.92 62.08 94021/94021 caml_oldify_mopup [8]
> 2.37 0.00 188042/188042 clear_table [29]
> 0.31 0.07 94021/94021
> caml_oldify_local_roots [58]
> 0.28 0.00 188042/896098 caml_gc_message [43]
> 0.05 0.10 9383144/3799622226 caml_oldify_one
> [14]
> 0.00 0.00 188042/188042
> caml_final_empty_young [344]
> -----------------------------------------------
> 31.92 62.08 94021/94021
> caml_empty_minor_heap [7]
> [8] 19.6 31.92 62.08 94021 caml_oldify_mopup [8]
> 20.71 41.37 3787931806/3799622226
> caml_oldify_one [14]
> -----------------------------------------------
> [...]
> """
>
> Best regards,
> david
>
> --
> Caml-list mailing list. Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>
--
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details: http://www.camlcity.org/contact.html
Company homepage: http://www.gerd-stolpmann.de
------------------------------------------------------------
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: AW: [Caml-list] Behaviour of an OCaml program: any possible GC improvement?
2012-10-24 16:07 ` AW: " Gerd Stolpmann
@ 2012-10-24 17:23 ` Martin Jambon
0 siblings, 0 replies; 20+ messages in thread
From: Martin Jambon @ 2012-10-24 17:23 UTC (permalink / raw)
To: caml-list
On 10/24/2012 09:07 AM, Gerd Stolpmann wrote:
> I don't think you can do much here by just setting parameters. (Btw.,
> there is no need to compile the mli's with -p.)
>
> I've seen high CPU for garbage collection frequently for mainly
> functional programs. It's their nature - you generate lots of
> short-living intermediate results. You can change that only by changing
> the algorithm, e.g. by caching results that would otherwise be
> recomputed again. Some improvement is also possible with simple tricks,
> e.g. if you have something like
>
> Number 0
>
> where Number is from an algebraic type, and you use this term
> frequently, consider to add a constant for it,
>
> let n0 = Number 0
>
> so this isn't reallocated all the time (even: if n=0 then n0 else Number
> n). If this term is used often, this makes a noticeable difference.
Note that the following works too:
if n = 0 then Number 0 (* structured constant *)
else Number n
# type t = Number of int;;
type t = Number of int
# let f () = Number 0;;
val f : unit -> t = <fun>
# f () == f ();;
- : bool = true
Martin
> Am 24.10.2012 17:09:12 schrieb(en) David MENTRE:
>> Hello,
>>
>> 2012/10/24 David MENTRE <dmentre@linux-france.org>:
>> > But, after recompiling everything from scratch and redoing my tests
>> > (taking care of erasing old gmon.out file), I have the same result
>> > (with <spontaneous> calling caml_call_gc). :-(
>>
>> For the sake of completeness, I installed latest OCaml 4.00.1 (for the
>> recall, Linux x86_64 platform), recompiled everything from scratch and
>> re-did my tests. I obtain roughly the same results and the same
>> <spontaneous> calling caml_call_gc. :-(
>>
>> There should be something obvious that I missed.
>>
>> """
>> Flat profile:
>>
>> Each sample counts as 0.01 seconds.
>> % cumulative self self total
>> time seconds seconds calls s/call s/call name
>> 32.54 155.97 155.97 35791 0.00 0.01 mark_slice
>> 19.87 251.24 95.26 58230 0.00 0.00 sweep_slice
>> 12.35 310.42 59.18 88113 0.00 0.00 camlMap__map_1150
>> 6.66 342.34 31.92 94021 0.00 0.00 caml_oldify_mopup
>> 6.57 373.81 31.47 1986040761 0.00 0.00
>> caml_page_table_lookup
>> 4.66 396.17 22.36 3792214394 0.00 0.00 caml_fl_allocate
>> 4.33 416.94 20.77 3799622226 0.00 0.00 caml_oldify_one
>> 3.39 433.18 16.24 3873315118 0.00 0.00
>> caml_fl_merge_block
>> 2.51 445.20 12.03 3792214239 0.00 0.00 caml_alloc_shr
>> 1.38 451.83 6.63 3882908903 0.00 0.00
>> camlData_typing__apply_1255
>> 1.26 457.88 6.05 3792214239 0.00 0.00 allocate_block
>> 1.20 463.62 5.74 1 5.74 5.74
>> caml_realloc_ref_table
>> 0.49 465.99 2.37 188042 0.00 0.00 clear_table
>> 0.44 468.09 2.10 3881730105 0.00 0.00
>> camlData_typing__fun_1445
>> 0.42 470.08 1.99 caml_fl_reset
>> 0.31 471.57 1.50
>> caml_set_allocation_policy
>> 0.28 472.90 1.33 896098 0.00 0.00 caml_gc_message
>> 0.24 474.06 1.16 74 0.02 0.02 camlMap__iter_1144
>> 0.22 475.12 1.06 155 0.01 0.01 caml_add_to_heap
>> 0.11 475.64 0.53
>> camlData_typing__fun_1430
>> 0.07 475.98 0.34
>> camlData_typing__print_vset_1115
>> 0.06 476.29 0.31 94021 0.00 0.00
>> caml_oldify_local_roots
>> 0.04 476.46 0.17 10355866 0.00 0.00
>> camlFormat__doprn_1525
>> 0.03 476.61 0.15 95566109 0.00 0.00 caml_modify
>> 0.03 476.74 0.13 5946696 0.00 0.00
>> camlFormat__kpr_1514
>> 0.03 476.86 0.12 10179867 0.00 0.00
>> camlFormat__advance_loop_1173
>> 0.02 476.97 0.11 16452591 0.00 0.00
>> camlFormat__format_pp_token_1134
>> 0.02 477.05 0.08 15459066 0.00 0.00 caml_putblock
>> 0.02 477.13 0.08 16452612 0.00 0.00
>> camlFormat__add_queue_1087
>> [...]
>> granularity: each sample hit covers 2 byte(s) for 0.00% of 479.32 seconds
>>
>> index % time self children called name
>> 0.00 0.11 25/94021 caml_alloc_small [75]
>> 0.00 0.56 133/94021 caml_alloc_string [51]
>> 0.02 394.48 93863/94021
>> caml_garbage_collection [3]
>> [1] 82.4 0.02 395.15 94021 caml_minor_collection [1]
>> 0.02 297.93 94021/94021
>> caml_major_collection_slice [4]
>> 0.01 97.19 188042/188042 caml_empty_minor_heap
>> [7]
>> 0.00 0.00 94021/94021 caml_final_do_calls
>> [353]
>> -----------------------------------------------
>> <spontaneous>
>> [2] 82.3 0.04 394.50 caml_call_gc [2]
>> 0.00 394.50 93863/93863
>> caml_garbage_collection [3]
>> -----------------------------------------------
>> 0.00 394.50 93863/93863 caml_call_gc [2]
>> [3] 82.3 0.00 394.50 93863 caml_garbage_collection [3]
>> 0.02 394.48 93863/94021 caml_minor_collection
>> [1]
>> 0.00 0.00 93863/97401
>> caml_process_pending_signals [352]
>> -----------------------------------------------
>> 0.02 297.93 94021/94021 caml_minor_collection
>> [1]
>> [4] 62.2 0.02 297.93 94021
>> caml_major_collection_slice [4]
>> 155.97 29.41 35791/35791 mark_slice [5]
>> 95.26 16.33 58230/58230 sweep_slice [6]
>> 0.84 0.00 564126/896098 caml_gc_message [43]
>> 0.00 0.10 4652/4652 start_cycle [76]
>> 0.00 0.01 4651/4651
>> caml_compact_heap_maybe [135]
>> -----------------------------------------------
>> 155.97 29.41 35791/35791
>> caml_major_collection_slice [4]
>> [5] 38.7 155.97 29.41 35791 mark_slice [5]
>> 29.31 0.00 1849494323/1986040761
>> caml_page_table_lookup [16]
>> 0.11 0.00 71582/896098 caml_gc_message [43]
>> 0.00 0.00 1/1 realloc_gray_vals [269]
>> 0.00 0.00 4652/4652 caml_final_update [377]
>> 0.00 0.00 4652/4653 caml_fl_init_merge [375]
>> -----------------------------------------------
>> 95.26 16.33 58230/58230
>> caml_major_collection_slice [4]
>> [6] 23.3 95.26 16.33 58230 sweep_slice [6]
>> 16.24 0.00 3873315117/3873315118
>> caml_fl_merge_block [18]
>> 0.09 0.00 58230/896098 caml_gc_message [43]
>> 0.00 0.00 1/1 caml_finalize_channel
>> [477]
>> -----------------------------------------------
>> 0.01 97.19 188042/188042 caml_minor_collection
>> [1]
>> [7] 20.3 0.01 97.19 188042 caml_empty_minor_heap [7]
>> 31.92 62.08 94021/94021 caml_oldify_mopup [8]
>> 2.37 0.00 188042/188042 clear_table [29]
>> 0.31 0.07 94021/94021
>> caml_oldify_local_roots [58]
>> 0.28 0.00 188042/896098 caml_gc_message [43]
>> 0.05 0.10 9383144/3799622226 caml_oldify_one [14]
>> 0.00 0.00 188042/188042
>> caml_final_empty_young [344]
>> -----------------------------------------------
>> 31.92 62.08 94021/94021 caml_empty_minor_heap
>> [7]
>> [8] 19.6 31.92 62.08 94021 caml_oldify_mopup [8]
>> 20.71 41.37 3787931806/3799622226 caml_oldify_one
>> [14]
>> -----------------------------------------------
>> [...]
>> """
>>
>> Best regards,
>> david
>>
>> --
>> Caml-list mailing list. Subscription management and archives:
>> https://sympa.inria.fr/sympa/arc/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>
>>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Caml-list] Behaviour of an OCaml program: any possible GC improvement?
[not found] ` <1351094817.12207.11@samsung>
@ 2012-10-25 6:48 ` David MENTRE
2012-10-25 7:37 ` David House
0 siblings, 1 reply; 20+ messages in thread
From: David MENTRE @ 2012-10-25 6:48 UTC (permalink / raw)
To: Gerd Stolpmann; +Cc: Oliver Bandel, caml users
Hello Gerd,
2012/10/24 Gerd Stolpmann <gerd@edgespring.com>:
> I've seen high CPU for garbage collection frequently for mainly functional
> programs. It's their nature - you generate lots of short-living intermediate
> results. You can change that only by changing the algorithm, e.g. by caching
> results that would otherwise be recomputed again.
That was my feeling. I just wanted to check easy parts before digging
into more complex algorithm change.
> Some improvement is also
> possible with simple tricks, e.g. if you have something like
>
> Number 0
>
> where Number is from an algebraic type, and you use this term frequently,
> consider to add a constant for it,
>
> let n0 = Number 0
>
> so this isn't reallocated all the time
Thanks for the trick.
Best regards,
david
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Caml-list] Behaviour of an OCaml program: any possible GC improvement?
2012-10-25 6:48 ` David MENTRE
@ 2012-10-25 7:37 ` David House
0 siblings, 0 replies; 20+ messages in thread
From: David House @ 2012-10-25 7:37 UTC (permalink / raw)
To: David MENTRE; +Cc: Gerd Stolpmann, Oliver Bandel, caml users
On Thu, Oct 25, 2012 at 7:48 AM, David MENTRE <dmentre@linux-france.org> wrote:
>> Some improvement is also
>> possible with simple tricks, e.g. if you have something like
>>
>> Number 0
>>
>> where Number is from an algebraic type, and you use this term frequently,
>> consider to add a constant for it,
>>
>> let n0 = Number 0
>>
>> so this isn't reallocated all the time
>
> Thanks for the trick.
As Martin pointed out, this isn't necessary for Number 0. Constant
expressions are statically allocated. If you have two functions
returning Number 0, you'll get two of them, but they'll still be
statically allocated (so calling that function does not allocate for
Number).
This is actually even true of string literals, which are mutable:
# let f () = "foo";;
val f : unit -> string = <fun>
# let x = f ();;
val x : string = "foo"
# let y = f ();;
val y : string = "foo"
# x.[0] <- 'g';;
- : unit = ()
# y;;
- : string = "goo"
But other, similar tricks are worthwhile. For example, in async, it is
very common to write "return ()" for the deferred that is immediately
determined with value (). But doing so does a function call and
allocates a deferred. So we have [Deferred.unit] for this common case.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Caml-list] Behaviour of an OCaml program: any possible GC improvement?
2012-10-24 10:38 ` Török Edwin
@ 2012-10-25 10:06 ` David MENTRE
2012-10-25 10:16 ` Török Edwin
2012-11-07 11:52 ` David MENTRE
0 siblings, 2 replies; 20+ messages in thread
From: David MENTRE @ 2012-10-25 10:06 UTC (permalink / raw)
To: Török Edwin; +Cc: caml-list
Hello Edwin,
2012/10/24 Török Edwin <edwin+ml-ocaml@etorok.net>:
> You can try tuning the Gc parameters:
> http://caml.inria.fr/pub/docs/old-311/libref/Gc.html
>
> Try increasing minor_heap_size, and major_heap_increment and see if there is any improvement.
> Also look at Gc.stat() and see how many major collections and live words you have.
Olivier Andrieu made a similar suggestion and that helps!
2012/10/25 Olivier Andrieu:
> Try running your program with OCAMLRUNPARAM=s=256k !
> (A good value is about the size of the CPU L2 cache I'd say).
Thanks Olivier, your suggestion brings significant improvements!
On a particular example:
* default: 2m14.142s
* s=256k: 1m32.185s
* s=1024k: 0m45.420s
Thanks!
Best regards,
d.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Caml-list] Behaviour of an OCaml program: any possible GC improvement?
2012-10-25 10:06 ` David MENTRE
@ 2012-10-25 10:16 ` Török Edwin
2012-10-25 10:19 ` David MENTRE
2012-11-07 11:52 ` David MENTRE
1 sibling, 1 reply; 20+ messages in thread
From: Török Edwin @ 2012-10-25 10:16 UTC (permalink / raw)
To: caml-list
On 10/25/2012 01:06 PM, David MENTRE wrote:
> Hello Edwin,
>
> 2012/10/24 Török Edwin <edwin+ml-ocaml@etorok.net>:
>> You can try tuning the Gc parameters:
>> http://caml.inria.fr/pub/docs/old-311/libref/Gc.html
>>
>> Try increasing minor_heap_size, and major_heap_increment and see if there is any improvement.
>> Also look at Gc.stat() and see how many major collections and live words you have.
>
> Olivier Andrieu made a similar suggestion and that helps!
>
> 2012/10/25 Olivier Andrieu:
>> Try running your program with OCAMLRUNPARAM=s=256k !
>> (A good value is about the size of the CPU L2 cache I'd say).
>
> Thanks Olivier, your suggestion brings significant improvements!
>
> On a particular example:
> * default: 2m14.142s
> * s=256k: 1m32.185s
> * s=1024k: 0m45.420s
Would using the native code compiler increase the speed further?
--Edwin
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Caml-list] Behaviour of an OCaml program: any possible GC improvement?
2012-10-25 10:16 ` Török Edwin
@ 2012-10-25 10:19 ` David MENTRE
0 siblings, 0 replies; 20+ messages in thread
From: David MENTRE @ 2012-10-25 10:19 UTC (permalink / raw)
To: Török Edwin; +Cc: caml-list
2012/10/25 Török Edwin <edwin+ml-ocaml@etorok.net>:
> Would using the native code compiler increase the speed further?
I'm already using the native code compiler.
Best regards,
d.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Caml-list] Behaviour of an OCaml program: any possible GC improvement?
2012-10-25 10:06 ` David MENTRE
2012-10-25 10:16 ` Török Edwin
@ 2012-11-07 11:52 ` David MENTRE
1 sibling, 0 replies; 20+ messages in thread
From: David MENTRE @ 2012-11-07 11:52 UTC (permalink / raw)
To: Török Edwin; +Cc: caml users
Hello,
2012/10/25 David MENTRE <dmentre@linux-france.org>:
> 2012/10/24 Török Edwin <edwin+ml-ocaml@etorok.net>:
>> You can try tuning the Gc parameters:
>> http://caml.inria.fr/pub/docs/old-311/libref/Gc.html
>>
>> Try increasing minor_heap_size, and major_heap_increment and see if there is any improvement.
>> Also look at Gc.stat() and see how many major collections and live words you have.
>
> Olivier Andrieu made a similar suggestion and that helps!
>
> 2012/10/25 Olivier Andrieu:
>> Try running your program with OCAMLRUNPARAM=s=256k !
>> (A good value is about the size of the CPU L2 cache I'd say).
>
> Thanks Olivier, your suggestion brings significant improvements!
>
> On a particular example:
> * default: 2m14.142s
> * s=256k: 1m32.185s
> * s=1024k: 0m45.420s
For the record, it appears I was generating a Map of more than 100,000
entries (and using several variants of it). With some algorithm
tweaking I improved drastically both the size of this map and the
computation time of my program.
Many thanks to those that have helped me on this issue!
Best regards,
david
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2012-11-07 11:53 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-24 10:08 [Caml-list] Behaviour of an OCaml program: any possible GC improvement? David MENTRE
2012-10-24 10:33 ` John Whitington
2012-10-24 12:30 ` David MENTRE
2012-10-24 12:39 ` John Whitington
2012-10-24 12:45 ` Edgar Friendly
2012-10-24 12:53 ` John Whitington
2012-10-24 13:19 ` David MENTRE
2012-10-24 13:27 ` John Whitington
2012-10-24 13:38 ` Oliver Bandel
2012-10-24 14:30 ` David MENTRE
2012-10-24 15:09 ` David MENTRE
2012-10-24 16:07 ` AW: " Gerd Stolpmann
2012-10-24 17:23 ` Martin Jambon
[not found] ` <1351094817.12207.11@samsung>
2012-10-25 6:48 ` David MENTRE
2012-10-25 7:37 ` David House
2012-10-24 10:38 ` Török Edwin
2012-10-25 10:06 ` David MENTRE
2012-10-25 10:16 ` Török Edwin
2012-10-25 10:19 ` David MENTRE
2012-11-07 11:52 ` David MENTRE
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).