From: Matthew F. <no...@gi...> - 2019-06-19 19:53:27
|
Branch: refs/heads/master Home: https://github.com/MLton/mlton Commit: 83da3e8e2ec5bc32b475ca01a406be8cb3dfdb03 https://github.com/MLton/mlton/commit/83da3e8e2ec5bc32b475ca01a406be8cb3dfdb03 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-17 (Mon, 17 Jun 2019) Changed paths: M mlton/backend/backend.fun Log Message: ----------- Rename and generalize `callReturnStackOffsets` to `paramOffsets` Commit: 4e3b615284e6b60f2181746e9e34583b3385b0fb https://github.com/MLton/mlton/commit/4e3b615284e6b60f2181746e9e34583b3385b0fb Author: Matthew Fluet <mat...@gm...> Date: 2019-06-17 (Mon, 17 Jun 2019) Changed paths: M mlton/backend/allocate-registers.fun M mlton/backend/allocate-registers.sig M mlton/backend/backend.fun Log Message: ----------- Rename and generalize `formalsStackOffsets` to `paramOffsets` Commit: d2af0f8809e0b9d37b75b2aa8befd7fa6e30a514 https://github.com/MLton/mlton/commit/d2af0f8809e0b9d37b75b2aa8befd7fa6e30a514 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/allocate-registers.fun M mlton/backend/backend.fun Log Message: ----------- Do not force function args to stack Although function arguments are passed via the stack, they could be allocated as registers. In practice, because of the stack limit check at the beginning of every function, all function args will be stack allocated, but that may be relaxed in the future. Commit: 0d072dd8fdc9c54158e311e74b7d71a45b69212f https://github.com/MLton/mlton/commit/0d072dd8fdc9c54158e311e74b7d71a45b69212f Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/backend.fun Log Message: ----------- Update comments in `backend.fun` for Handler and ExnStack statements Commit: 6f9331cbc1fbfa31a3cf861aa4f0935fd7f7c163 https://github.com/MLton/mlton/commit/6f9331cbc1fbfa31a3cf861aa4f0935fd7f7c163 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/backend.fun Log Message: ----------- Clarify `{return,raise}{Lives,Operands}` in `backend.fun` Commit: ec043833af576b4967277f516ffc2ebc2329c110 https://github.com/MLton/mlton/commit/ec043833af576b4967277f516ffc2ebc2329c110 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/machine.fun Log Message: ----------- Add comments on `Machine.Statement.object` Commit: 3709a423e63e4c2b10676fdeb77c4c7f7637edb1 https://github.com/MLton/mlton/commit/3709a423e63e4c2b10676fdeb77c4c7f7637edb1 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/machine.fun Log Message: ----------- Code formatting Commit: 2ca3a27e6374f5a04eddb9e0cdeb068a0594ffbf https://github.com/MLton/mlton/commit/2ca3a27e6374f5a04eddb9e0cdeb068a0594ffbf Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/backend.fun M mlton/backend/machine.fun M mlton/backend/machine.sig Log Message: ----------- Rename `handles` field of `Machine.Kind.Handler` to `args` Commit: d3dc82729357d63dc3b4863130d7c5b853e194e8 https://github.com/MLton/mlton/commit/d3dc82729357d63dc3b4863130d7c5b853e194e8 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/control/control-flags.sig M mlton/control/control-flags.sml M mlton/main/main.fun Log Message: ----------- Add `-raise-style {globals}` expert compile-time option Commit: ad4017eff38e49d74fa0884cbb491470d7344e31 https://github.com/MLton/mlton/commit/ad4017eff38e49d74fa0884cbb491470d7344e31 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/allocate-registers.fun M mlton/backend/machine.fun M mlton/control/bits.sml Log Message: ----------- Check that frame sizes are sufficiently aligned Commit: 108ed7128ccb4328a43c81c7fc63c1ab65e74979 https://github.com/MLton/mlton/commit/108ed7128ccb4328a43c81c7fc63c1ab65e74979 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/allocate-registers.fun Log Message: ----------- Reorganize code in `functor AllocateRegisters` Commit: fb8cd3b8bdf5cf17fc40f1cbc39113f82400836b https://github.com/MLton/mlton/commit/fb8cd3b8bdf5cf17fc40f1cbc39113f82400836b Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/allocate-registers.fun Log Message: ----------- Ensure that handlerOffset is sufficiently aligned Commit: d445edfe4a95876c21ed776c1641d64fbd4041b5 https://github.com/MLton/mlton/commit/d445edfe4a95876c21ed776c1641d64fbd4041b5 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/allocate-registers.fun M mlton/backend/allocate-registers.sig M mlton/backend/backend.fun Log Message: ----------- Rename `handlerLinkOffset` to `handlersInfo` in `functor AllocateRegisters` Commit: af87f0cb2c4a75f5550e9dac03b6a19205143100 https://github.com/MLton/mlton/commit/af87f0cb2c4a75f5550e9dac03b6a19205143100 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/control/control-flags.sig M mlton/control/control-flags.sml M mlton/main/main.fun Log Message: ----------- Add `stack` to `-raise-style` compile-time option Commit: 6e42660ce80432cc4c6056ae6f9811334b6a5ab6 https://github.com/MLton/mlton/commit/6e42660ce80432cc4c6056ae6f9811334b6a5ab6 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/allocate-registers.fun Log Message: ----------- Reserve stack slots for handler arguments when `RaiseStyle.ViaStack` Commit: 0b1d353cde2c45069b6556c751abb47bc199a925 https://github.com/MLton/mlton/commit/0b1d353cde2c45069b6556c751abb47bc199a925 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/machine.fun M mlton/backend/rep-type.fun Log Message: ----------- Allow `Offset` operand of `CPointer` base in Machine IL Commit: a47db84927690f9576af7b3136fd2d811a165506 https://github.com/MLton/mlton/commit/a47db84927690f9576af7b3136fd2d811a165506 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/machine.fun Log Message: ----------- Fix `Machine.Statement.layout` (extra space before `=`) Commit: 6f502952f895383bdabad668caa6691323993818 https://github.com/MLton/mlton/commit/6f502952f895383bdabad668caa6691323993818 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/machine.fun Log Message: ----------- Add `Machine.Block.layoutHeader` Commit: 9fe15b3f5b64ab2f90a3145a075f8d95238b3e57 https://github.com/MLton/mlton/commit/9fe15b3f5b64ab2f90a3145a075f8d95238b3e57 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/machine.fun Log Message: ----------- Trace `Machine.Program.typeCheck.{liveIsOk,goto}` Commit: 7a8978ed31cd1a864918836145c0c975fe708f01 https://github.com/MLton/mlton/commit/7a8978ed31cd1a864918836145c0c975fe708f01 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/machine.fun Log Message: ----------- Add tracing of `raises` and `returns` in `Machine.Program.typeCheck.transferOk` Commit: ee84308e495240e804cf50e82cc90f99879a1bbb https://github.com/MLton/mlton/commit/ee84308e495240e804cf50e82cc90f99879a1bbb Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/machine.fun Log Message: ----------- Add `args` to allocation at beginning of `Handler` blocks Commit: de894f65845e8912ff10b5b182dd897797f96f3b https://github.com/MLton/mlton/commit/de894f65845e8912ff10b5b182dd897797f96f3b Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/machine.fun Log Message: ----------- Code formatting Commit: fc84c928b02030a7bf2ed926b89eb0c79bc7ce2f https://github.com/MLton/mlton/commit/fc84c928b02030a7bf2ed926b89eb0c79bc7ce2f Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/machine.fun Log Message: ----------- Rename `live` to `handlerLive` for checking is subset of `contLive` Commit: d7811ed31577968a29c535260bd5d0999b58b53c https://github.com/MLton/mlton/commit/d7811ed31577968a29c535260bd5d0999b58b53c Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/machine.fun Log Message: ----------- Check that `Handler` block's frame size is less than `Cont` block's Commit: 48f6ede27b7e6477fa369bb0a72a237ca91e60f8 https://github.com/MLton/mlton/commit/48f6ede27b7e6477fa369bb0a72a237ca91e60f8 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/codegen/amd64-codegen/amd64-translate.fun M mlton/codegen/x86-codegen/x86-translate.fun Log Message: ----------- Initialize `live` field of `Entry.Handler` in x86 & amd64 codegens Commit: 57390358b99580b326ad5d9fa5a4ff89b06db021 https://github.com/MLton/mlton/commit/57390358b99580b326ad5d9fa5a4ff89b06db021 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/backend.fun Log Message: ----------- Rename variable Commit: 69eec2d4d840db9a76e92e91d6d81dc0efb3e5a4 https://github.com/MLton/mlton/commit/69eec2d4d840db9a76e92e91d6d81dc0efb3e5a4 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/backend/backend.fun M mlton/backend/machine.fun Log Message: ----------- Raise values via stack with `-raise-style stack` With `-raise-style globals`, raised arguments are communicated from the raiser to the handler via (non-root) globals. This leads to the confusing `globalObjptrNonRoot`. Moreover, it has been a source of bugs in the CMU MultiMLton project, where parallel threads that raise at the same time can interfere through the race on the handler globals. With the new `-raise-style stack`, raised arguments are communicated from the raiser to the handler via the ML stack. Sufficient space for raised values are reserved in the handler frame immediately above the handler label. At a raise, the raiser stores the raised values at offsets of `stackBottom + exnStack` and the handler copies the values from the adjusted offsets to its argument locations. (Thus, a `Handler` block executes in the same manner as a `Cont` block.) The downside of this strategy is that every stack frame with an installed handler requires an additional 8 bytes (on a 64-bit platform) for the raised value, which is above the 16 bytes for the handler label and the exception stack link. (In theory, more space could be required if earlier optimizations flattened the `raises` of an SSA/SSA2/RSSA function, which could happen with the `SplitTypes` optimization that separates distinct "uses" of exceptions. However, in practice, the only "raise" convention has been a single `objptr`.) A different strategy would be for the raiser to store the raised values in its frame and then communicate the address of the raiser's frame to the handler. However, this would require an additional global to communicate the address of the raiser's frame. Commit: ea71ba30a21b5dad241c282824601d591f101dd9 https://github.com/MLton/mlton/commit/ea71ba30a21b5dad241c282824601d591f101dd9 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-18 (Tue, 18 Jun 2019) Changed paths: M mlton/control/control-flags.sml M mlton/main/main.fun Log Message: ----------- Make `stack` default for `-raise-style` Commit: 481e3dba8d6683ee3f70576f671c380b11da8668 https://github.com/MLton/mlton/commit/481e3dba8d6683ee3f70576f671c380b11da8668 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-19 (Wed, 19 Jun 2019) Changed paths: M mlton/backend/backend.fun Log Message: ----------- Omit calculating `StackBottom + ExnStack` when no values are raised Commit: 2b7c59ba195e75fc9fd6a52eb0c76da83300753f https://github.com/MLton/mlton/commit/2b7c59ba195e75fc9fd6a52eb0c76da83300753f Author: Matthew Fluet <mat...@gm...> Date: 2019-06-19 (Wed, 19 Jun 2019) Changed paths: M mlton/backend/allocate-registers.fun Log Message: ----------- Update comments in `AllocateRegisters` Commit: f42dfefa8a5e3c0248c19192f562526d1e6040fc https://github.com/MLton/mlton/commit/f42dfefa8a5e3c0248c19192f562526d1e6040fc Author: Matthew Fluet <mat...@gm...> Date: 2019-06-19 (Wed, 19 Jun 2019) Changed paths: M mlton/backend/allocate-registers.fun M mlton/backend/backend.fun M mlton/backend/machine.fun M mlton/control/control-flags.sig M mlton/control/control-flags.sml M mlton/main/main.fun Log Message: ----------- Remove `-raise-style {globals}` expert compile-time option Commit: 03f52105d5ef56284c5bc8298ad39a95db866f57 https://github.com/MLton/mlton/commit/03f52105d5ef56284c5bc8298ad39a95db866f57 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-19 (Wed, 19 Jun 2019) Changed paths: M mlton/backend/backend.fun M mlton/backend/machine.fun Log Message: ----------- Remove unused variables Commit: c4e7964ca425c0e2ff3d733113308632f8f6c2d6 https://github.com/MLton/mlton/commit/c4e7964ca425c0e2ff3d733113308632f8f6c2d6 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-19 (Wed, 19 Jun 2019) Changed paths: M mlton/backend/backend.fun Log Message: ----------- Share code to generate prelude for Cont and Handler blocks Commit: 477b61de5b44ff5ea0debc634ce6a7e776279539 https://github.com/MLton/mlton/commit/477b61de5b44ff5ea0debc634ce6a7e776279539 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-19 (Wed, 19 Jun 2019) Changed paths: M include/c-chunk.h M mlton/backend/backend.fun M mlton/backend/machine.fun M mlton/backend/machine.sig M mlton/codegen/amd64-codegen/amd64-mlton-basic.fun M mlton/codegen/amd64-codegen/amd64-mlton-basic.sig M mlton/codegen/amd64-codegen/amd64-translate.fun M mlton/codegen/c-codegen/c-codegen.fun M mlton/codegen/llvm-codegen/llvm-codegen.fun M mlton/codegen/x86-codegen/x86-mlton-basic.fun M mlton/codegen/x86-codegen/x86-mlton-basic.sig M mlton/codegen/x86-codegen/x86-translate.fun Log Message: ----------- Eliminate non-root globals Commit: 0b02293c231ce9869d6c5e7bc6e8d7c07342c7c2 https://github.com/MLton/mlton/commit/0b02293c231ce9869d6c5e7bc6e8d7c07342c7c2 Author: Matthew Fluet <mat...@gm...> Date: 2019-06-19 (Wed, 19 Jun 2019) Changed paths: M mlton/control/control-flags.sig M mlton/control/control-flags.sml M mlton/main/main.fun Log Message: ----------- Remove `-raise-style {stack}` expert compile-time option Commit: 65f2aa4409c1520b6222b671dd9ca43a461e3b79 https://github.com/MLton/mlton/commit/65f2aa4409c1520b6222b671dd9ca43a461e3b79 Author: Matthew Fluet <Mat...@gm...> Date: 2019-06-19 (Wed, 19 Jun 2019) Changed paths: M include/c-chunk.h M mlton/backend/allocate-registers.fun M mlton/backend/allocate-registers.sig M mlton/backend/backend.fun M mlton/backend/machine.fun M mlton/backend/machine.sig M mlton/backend/rep-type.fun M mlton/codegen/amd64-codegen/amd64-mlton-basic.fun M mlton/codegen/amd64-codegen/amd64-mlton-basic.sig M mlton/codegen/amd64-codegen/amd64-translate.fun M mlton/codegen/c-codegen/c-codegen.fun M mlton/codegen/llvm-codegen/llvm-codegen.fun M mlton/codegen/x86-codegen/x86-mlton-basic.fun M mlton/codegen/x86-codegen/x86-mlton-basic.sig M mlton/codegen/x86-codegen/x86-translate.fun M mlton/control/bits.sml Log Message: ----------- Merge pull request #321 from MatthewFluet/raise-via-stack Raise values via stack Previously, raised values are communicated from the raiser to the handler via (non-root) globals. This leads to the confusing `globalObjptrNonRoot`. Moreover, it has been a source of bugs in the CMU MultiMLton project, where parallel threads that raise at the same time can interfere through the race on the handler globals. With this PR, raised values can be communicated from the raiser to the handler via the ML stack. Sufficient space for raised values are reserved in the handler frame immediately above the handler label. At a raise, the raiser stores the raised values at offsets of `stackBottom + exnStack`, the stack is truncated to `stackBottom + exnStack` and control is transfered to the handler, and the handler copies the values to its argument locations. (Thus, a `Handler` block executes in the same manner as a `Cont` block.) The downside of this strategy is that every stack frame with an installed handler requires an additional 8 bytes (on a 64-bit platform) for the raised value, which is above the 16 bytes for the handler label and the exception stack link. (In theory, more space could be required if earlier optimizations flattened the `raises` of an SSA/SSA2/RSSA function, which could happen with the `SplitTypes` optimization that separates distinct "uses" of exceptions. However, in practice, the only observed "raising" convention has been a single `objptr`.) A different strategy would be for the raiser to store the raised values in its frame and then communicate the address of the raiser's frame to the handler. However, this would require an additional global to communicate the address of the raiser's frame. ## Benchmark results (sulfur) Specs: * 2 x Intel(R) Xeon(R) CPU E5-2637 v3 @ 3.50GHz (8 physical cores; 16 logical cores) * Ubuntu 16.04.6 LTS * gcc: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.11) ``` text config command C00 /home/mtf/devel/mlton/builds/ga02ac1f5e/bin/mlton @MLton -- C01 /home/mtf/devel/mlton/builds/g69eec2d4d/bin/mlton @MLton -- C02 /home/mtf/devel/mlton/builds/gea71ba30a/bin/mlton @MLton -- C03 /home/mtf/devel/mlton/builds/ga02ac1f5e/bin/mlton @MLton -- -codegen c C04 /home/mtf/devel/mlton/builds/g69eec2d4d/bin/mlton @MLton -- -codegen c C05 /home/mtf/devel/mlton/builds/gea71ba30a/bin/mlton @MLton -- -codegen c ``` ### Run-Time Ratio ``` text program `C01/C00` `C02/C00` `C04/C03` `C05/C03` barnes-hut 1.021 1.032 0.9883 1.031 boyer 0.9616 0.9992 0.9804 1.005 checksum 0.9962 0.9922 0.9908 0.9939 count-graphs 1.007 1.020 1.009 1.023 DLXSimulator 1.011 1.004 0.9962 0.9976 even-odd 1.003 1.002 0.9948 0.9940 fft 1.010 1.019 1.001 0.9851 fib 1.001 0.9039 0.9917 1.005 flat-array 1.030 1.050 0.9571 0.9940 hamlet 1.010 1.066 0.9999 1.057 imp-for 1.002 0.9951 0.9250 0.9260 knuth-bendix 1.011 1.016 1.029 1.067 lexgen 0.9917 1.001 0.9459 0.9801 life 1.017 1.024 1.004 0.9926 logic 1.029 1.026 1.003 0.9835 mandelbrot 0.9986 0.9981 0.9734 0.9693 matrix-multiply 1.024 1.026 0.9997 1.014 md5 0.9990 1.018 1.000 1.001 merge 1.004 0.9875 0.9845 0.9644 mlyacc 1.037 0.9868 1.012 0.9841 model-elimination 1.015 1.011 0.9899 1.020 mpuz 0.9901 0.9817 1.008 1.011 nucleic 1.011 1.034 0.9914 0.9967 output1 1.008 0.9974 1.009 1.002 peek 0.9957 0.9984 0.9996 1.012 pidigits 1.010 1.017 1.016 0.9939 psdes-random 1.016 1.019 1.007 1.004 ratio-regions 0.9900 0.9783 1.041 1.017 ray 0.9756 0.9999 1.012 0.9621 raytrace 0.9857 0.9847 1.039 1.018 simple 0.9879 1.050 1.007 1.031 smith-normal-form 1.017 0.9531 1.030 0.9971 string-concat 1.016 1.005 0.9950 0.9993 tailfib 1.008 1.000 0.9874 0.9918 tailmerge 1.005 0.9837 1.025 0.9892 tak 0.9929 1.061 1.016 1.013 tensor 1.001 0.9975 0.9964 0.9933 tsp 1.004 0.9858 1.069 1.026 tyan 0.9888 1.007 1.008 1.013 vector32-concat 0.9841 0.9867 0.9764 0.9810 vector64-concat 1.026 1.051 1.048 0.9761 vector-rev 1.013 1.019 1.023 1.020 vliw 1.011 0.9732 0.9941 1.018 wc-input1 0.9887 0.9828 1.007 0.9930 wc-scanStream 0.9907 1.070 0.9290 0.9823 zebra 0.9993 1.003 1.005 0.9955 zern 0.9815 1.007 0.9989 1.020 MIN 0.9616 0.9039 0.9250 0.9260 GMEAN 1.004 1.006 1.0000 1.001 MAX 1.037 1.070 1.069 1.067 ``` Notes: * The expectation is that `C01/C00` and `C04/C03` should both be `1.0`, since those configurations correspond to infrastructure changes, but does not switch the raising convention. The minor changes include swapping the positions of the handler label and the exception stack link on the handler frame and ensuring proper alignment of the handler label (although the latter should have no effect on amd64, which defaults to `-align 8` and uses 64-bit (with 8 byte alignment) code labels). * On (geometric) average, there is no significant slowdown due to the alternate raising convention, although there are some negative outliers. * Also, note that there is little correlation between `Run-Time Ratio` and `Max Stack Size Ratio` (see below). This suggests that performance changes are likely due to low-level effects such as cache, not due to the increased total stack size. ### Max Stack Size Ratio (run-time) ``` text program `C01/C00` `C02/C00` `C04/C03` `C05/C03` barnes-hut 1 1.035 1 1.038 boyer 1 1.048 1 1.048 checksum 1 1.065 1 1.065 count-graphs 1 1.045 1 1.045 DLXSimulator 1 1.032 1 1.032 even-odd 1 1.067 1 1.067 fft 1 1.043 1 1.043 fib 1 1.067 1 1.067 flat-array 1 1.065 1 1.065 hamlet 1 1.016 1 1.016 imp-for 1 1.067 1 1.067 knuth-bendix 1 1.042 1 1.042 lexgen 1 1.02 1 1.02 life 1 1.062 1 1.062 logic 1 1 1 1 mandelbrot 1 1.067 1 1.067 matrix-multiply 1 1.065 1 1.065 md5 1 1.047 1 1.047 merge 1 1.065 1 1.065 mlyacc 1 1.007 1 1.007 model-elimination 1 1.021 1 1.021 mpuz 1 1.062 1 1.062 nucleic 1 1 1 1 output1 1 1.05 1 1.05 peek 1 1.067 1 1.067 pidigits 1 1.048 1 1.048 psdes-random 1 1.067 1 1.067 ratio-regions 1 1.027 1 1.027 ray 1 0.9886 1 0.9886 raytrace 1 1.018 1 1.018 simple 1 0.9430 1 0.9430 smith-normal-form 1 1.039 1 1.039 string-concat 1 1.061 1 1.061 tailfib 1 1.067 1 1.067 tailmerge 1 1.065 1 1.065 tak 1 1.067 1 1.067 tensor 1 1.027 1 1.027 tsp 1 1.045 1 1.045 tyan 1 1.017 1 1.017 vector32-concat 1 1.065 1 1.065 vector64-concat 1 1.065 1 1.065 vector-rev 1 1.065 1 1.065 vliw 1 1 1 1 wc-input1 1 1.044 1 1.044 wc-scanStream 1 1.041 1 1.041 zebra 1 2.071 1 2.071 zern 1 1.039 1 1.039 MIN 1 0.9430 1 0.9430 GMEAN 1 1.057 1 1.057 MAX 1 2.071 1 2.071 ``` Notes: * As expected, there is a slight increase in the maximum stack size due to the space reserved for raised values. However, note that the maximum stack size corresponds to the largest stack space reserved by the runtime system, not the largest stack space used by the mutator. The default stack sizing policy is to double the stack space reserved each time the stack is grown, which explains the maximum ratio of `2.071`. Similarly, this stack sizing policy explains how the ratio can be less than `1.0`, when early stack growth with larger frames suffices for the maximum used stack, while early stack growth with smaller frames requires additional later growth for the maximum used stack. Moreover, `zebra` has a very small stack: `C00`&`C01`&`C03`&`C04` are 3584 and `C02`&`C05` are 7424. ### Max Stack Size Ratio (compile-time) ``` text program `C01/C00` `C02/C00` `C04/C03` `C05/C03` barnes-hut 1.001 1.003 1.001 1.003 boyer 1.001 2.005 1.001 2.005 checksum 1.001 1.003 1.001 1.003 count-graphs 1.001 1.003 1.001 1.003 DLXSimulator 1.001 1.003 1.001 1.003 even-odd 1.001 1.003 1.001 1.003 fft 1.001 1.003 1.001 1.003 fib 1.001 1.003 1.001 1.003 flat-array 1.001 1.003 1.001 1.003 hamlet 1.001 1.003 1.001 1.003 imp-for 1.001 1.003 1.001 1.003 knuth-bendix 1.001 1.003 1.001 1.003 lexgen 1.001 1.003 1.001 1.003 life 1.001 1.003 1.001 1.003 logic 1.001 1.003 1.001 1.003 mandelbrot 1.001 1.003 1.001 1.003 matrix-multiply 1.001 1.003 1.001 1.003 md5 1.001 1.003 1.001 1.003 merge 1.001 1.003 1.001 1.003 mlyacc 0.9644 0.9839 0.9644 0.9839 model-elimination 0.9820 0.9679 0.9828 0.9679 mpuz 1.001 1.003 1.001 1.003 nucleic 1.001 1.003 1.001 1.003 output1 1.001 1.003 1.001 1.003 peek 1.001 1.003 1.001 1.003 pidigits 1.001 1.003 1.001 1.003 psdes-random 1.001 1.003 1.001 1.003 ratio-regions 1.001 1.003 1.001 1.003 ray 1.001 1.003 1.001 1.003 raytrace 1.001 1.055 1.001 1.055 simple 1.001 1.003 1.001 1.003 smith-normal-form 1.001 1.003 1.001 1.003 string-concat 1.001 1.003 1.001 1.003 tailfib 1.001 1.003 1.001 1.003 tailmerge 1.001 1.003 1.001 1.003 tak 1.001 1.003 1.001 1.003 tensor 1.001 1.003 1.001 1.003 tsp 1.001 1.003 1.001 1.003 tyan 1.001 1.003 1.001 1.003 vector32-concat 1.001 1.003 1.001 1.003 vector64-concat 1.001 1.003 1.001 1.003 vector-rev 1.001 1.003 1.001 1.003 vliw 1.001 1.003 1.001 1.003 wc-input1 1.001 1.003 1.001 1.003 wc-scanStream 1.001 1.003 1.001 1.003 zebra 1.001 1.003 1.001 1.003 zern 1.001 1.003 1.001 1.003 MIN 0.9644 0.9679 0.9644 0.9679 GMEAN 1.000 1.018 1.000 1.018 MAX 1.001 2.005 1.001 2.005 ``` Note: * The effect of the larger frames is less pronounced in the compiler proper, although the `2.005` outlier does appear. ## Self-compile results (sulfur) Specs: * 2 x Intel(R) Xeon(R) CPU E5-2637 v3 @ 3.50GHz (8 physical cores; 16 logical cores) * Ubuntu 16.04.6 LTS * gcc: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.11) ``` text MLton 20190618.195743-g69eec2d4d finished in 202.23 + 26.50 (12% GC) GC type time ms number bytes bytes/sec ------------- ------- ------- --------------- --------------- copying 24,960 32 16,223,789,408 649,991,548 mark-compact 0 0 0 - minor 0 68 56,768 - total time: 222,664 ms total GC time: 26,504 ms (11.9%) max pause time: 2,732 ms total bytes allocated: 173,669,514,440 bytes max bytes live: 1,568,690,392 bytes max heap size: 12,549,611,520 bytes max stack size: 24,412,160 bytes num cards marked: 198 bytes scanned: 4,550,744 bytes bytes hash consed: 0 bytes MLton 20190618.221106-gea71ba30a finished in 193.37 + 27.39 (12% GC) GC type time ms number bytes bytes/sec ------------- ------- ------- --------------- --------------- copying 24,972 33 17,227,509,912 689,873,048 mark-compact 0 0 0 - minor 0 67 61,616 - total time: 215,532 ms total GC time: 27,396 ms (12.7%) max pause time: 3,320 ms total bytes allocated: 174,112,963,256 bytes max bytes live: 1,520,008,000 bytes max heap size: 12,160,098,304 bytes max stack size: 24,444,928 bytes num cards marked: 195 bytes scanned: 6,078,928 bytes bytes hash consed: 0 bytes ``` Notes: * On (fully-bootstraped) self-compile, the max stack size ratio is only `1.001`. Compare: https://github.com/MLton/mlton/compare/a02ac1f5e878...65f2aa4409c1 |