[Git][ghc/ghc][wip/andreask/allocationArea] Increase -A default to 4MB.
Andreas Klebinger
gitlab at gitlab.haskell.org
Tue Oct 13 13:54:54 UTC 2020
Andreas Klebinger pushed to branch wip/andreask/allocationArea at Glasgow Haskell Compiler / GHC
Commits:
b3c1e42e by Andreas Klebinger at 2020-10-13T15:54:41+02:00
Increase -A default to 4MB.
This gives a small increase in performance under most circumstances.
For single threaded GC the improvement is on the order of 1-2%.
For multi threaded GC the results are quite noisy but seem to
fall into the same ballpark.
Fixes #16499
- - - - -
3 changed files:
- docs/users_guide/runtime_control.rst
- rts/RtsFlags.c
- testsuite/tests/rts/T9579/Makefile
Changes:
=====================================
docs/users_guide/runtime_control.rst
=====================================
@@ -418,7 +418,7 @@ performance.
.. rts-flag:: -A ⟨size⟩
- :default: 1MB
+ :default: 4MB
.. index::
single: allocation area, size
@@ -427,15 +427,22 @@ performance.
collector. The allocation area (actually generation 0 step 0) is
fixed and is never resized (unless you use :rts-flag:`-H [⟨size⟩]`, below).
- Increasing the allocation area size may or may not give better
- performance (a bigger allocation area means worse cache behaviour
- but fewer garbage collections and less promotion).
+ Optimal settings depend on the actual machine, program, and other RTS options.
+ Increasing the allocation area size means worse cache behaviour
+ but fewer garbage collections and less promotion.
+
+ In general settings >= 4MB can reduce performance in some cases, in particular for single
+ threaded operation. However in a parallel setting increasing the allocation area
+ to ``16MB``, or even ``64MB`` can increase gc throughput significantly.
With only 1 generation (e.g. ``-G1``, see :rts-flag:`-G ⟨generations⟩`) the
``-A`` option specifies the minimum allocation area, since the actual size
of the allocation area will be resized according to the amount of data in
the heap (see :rts-flag:`-F ⟨factor⟩`, below).
+ When heap profiling using a smaller allocation area can increase accuracy as more frequent
+ major garbage collections also results in more frequent heap snapshots
+
.. rts-flag:: -AL ⟨size⟩
:default: :rts-flag:`-A <-A ⟨size⟩>` value
=====================================
rts/RtsFlags.c
=====================================
@@ -153,10 +153,11 @@ void initRtsFlagsDefaults(void)
RtsFlags.GcFlags.stkChunkSize = (32 * 1024) / sizeof(W_);
RtsFlags.GcFlags.stkChunkBufferSize = (1 * 1024) / sizeof(W_);
- RtsFlags.GcFlags.minAllocAreaSize = (1024 * 1024) / BLOCK_SIZE;
+ /* -A default. See #16499 for a discussion about the tradeoffs */
+ RtsFlags.GcFlags.minAllocAreaSize = (4 * 1024 * 1024) / BLOCK_SIZE;
RtsFlags.GcFlags.largeAllocLim = 0; /* defaults to minAllocAreasize */
RtsFlags.GcFlags.nurseryChunkSize = 0;
- RtsFlags.GcFlags.minOldGenSize = (1024 * 1024) / BLOCK_SIZE;
+ RtsFlags.GcFlags.minOldGenSize = (1024 * 1024) / BLOCK_SIZE; /* -O default */
RtsFlags.GcFlags.maxHeapSize = 0; /* off by default */
RtsFlags.GcFlags.heapLimitGrace = (1024 * 1024);
RtsFlags.GcFlags.heapSizeSuggestion = 0; /* none */
=====================================
testsuite/tests/rts/T9579/Makefile
=====================================
@@ -3,43 +3,43 @@ include $(TOP)/mk/boilerplate.mk
include $(TOP)/mk/test.mk
T9579_stackoverflow_rtsnone:
- '$(TEST_HC)' $(TEST_HC_OPTS) -v0 -rtsopts=none -fforce-recomp -with-rtsopts -K1m \
+ '$(TEST_HC)' $(TEST_HC_OPTS) -v0 -rtsopts=none -fforce-recomp -with-rtsopts -A500k -with-rtsopts -K1m \
-outputdir tmp_T9579_stackoverflow_rtsnone \
StackOverflow.hs -o T9579_stackoverflow_rtsnone
T9579_stackoverflow_rtssome:
- '$(TEST_HC)' $(TEST_HC_OPTS) -v0 -rtsopts=some -fforce-recomp -with-rtsopts -K1m \
+ '$(TEST_HC)' $(TEST_HC_OPTS) -v0 -rtsopts=some -fforce-recomp -with-rtsopts -A500k -with-rtsopts -K1m \
-outputdir tmp_T9579_stackoverflow_rtssome \
StackOverflow.hs -o T9579_stackoverflow_rtssome
T9579_stackoverflow_rtsall:
- '$(TEST_HC)' $(TEST_HC_OPTS) -v0 -rtsopts=all -fforce-recomp -with-rtsopts -K1m \
+ '$(TEST_HC)' $(TEST_HC_OPTS) -v0 -rtsopts=all -fforce-recomp -with-rtsopts -A500k -with-rtsopts -K1m \
-outputdir tmp_T9579_stackoverflow_rtsall \
StackOverflow.hs -o T9579_stackoverflow_rtsall
T9579_stackoverflow_rtsall_no_suggestions:
- '$(TEST_HC)' $(TEST_HC_OPTS) -v0 -rtsopts=all -fforce-recomp -with-rtsopts -K1m \
+ '$(TEST_HC)' $(TEST_HC_OPTS) -v0 -rtsopts=all -fforce-recomp -with-rtsopts -A500k -with-rtsopts -K1m \
-no-rtsopts-suggestions \
-outputdir tmp_T9579_stackoverflow_rtsall_no_suggestions \
StackOverflow.hs -o T9579_stackoverflow_rtsall_no_suggestions
T9579_outofheap_rtsnone:
- '$(TEST_HC)' $(TEST_HC_OPTS) -v0 -rtsopts=none -fforce-recomp -with-rtsopts -M1m \
+ '$(TEST_HC)' $(TEST_HC_OPTS) -v0 -rtsopts=none -fforce-recomp -with-rtsopts -A500k -with-rtsopts -M1m \
-outputdir tmp_T9579_outofheap_rtsnone \
OutOfHeap.hs -o T9579_outofheap_rtsnone
T9579_outofheap_rtssome:
- '$(TEST_HC)' $(TEST_HC_OPTS) -v0 -rtsopts=some -fforce-recomp -with-rtsopts -M1m \
+ '$(TEST_HC)' $(TEST_HC_OPTS) -v0 -rtsopts=some -fforce-recomp -with-rtsopts -A500k -with-rtsopts -M1m \
-outputdir tmp_T9579_outofheap_rtssome \
OutOfHeap.hs -o T9579_outofheap_rtssome
T9579_outofheap_rtsall:
- '$(TEST_HC)' $(TEST_HC_OPTS) -v0 -rtsopts=all -fforce-recomp -with-rtsopts -M1m \
+ '$(TEST_HC)' $(TEST_HC_OPTS) -v0 -rtsopts=all -fforce-recomp -with-rtsopts -A500k -with-rtsopts -M1m \
-outputdir tmp_T9579_outofheap_rtsall \
OutOfHeap.hs -o T9579_outofheap_rtsall
T9579_outofheap_rtsall_no_suggestions:
- '$(TEST_HC)' $(TEST_HC_OPTS) -v0 -rtsopts=all -fforce-recomp -with-rtsopts -M1m \
+ '$(TEST_HC)' $(TEST_HC_OPTS) -v0 -rtsopts=all -fforce-recomp -with-rtsopts -A500k -with-rtsopts -M1m \
-no-rtsopts-suggestions \
-outputdir tmp_T9579_outofheap_rtsall_no_suggestions \
OutOfHeap.hs -o T9579_outofheap_rtsall_no_suggestions
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/b3c1e42eb9c4f1ed7771e6e87be46cf5069769f1
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/b3c1e42eb9c4f1ed7771e6e87be46cf5069769f1
You're receiving this email because of your account on gitlab.haskell.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20201013/77c08610/attachment-0001.html>
More information about the ghc-commits
mailing list