Hello. I wrote, 2021-01-13 22:24: > Hi. > > megane wrote, 2021-01-13 12:10: >> >> Sven Hartrumpf <hartru...@gmx.net> writes: >> >>> Hi Mario. >>> >> [snip] >>> Run options are: >>> >>> -:hi256m -:H -:hs0 -:o -:s4096k >> The combination of -:hi256m and -:hs0 pretty much guarantees these >> patches won't help you. > > I feared so, when I was asked to post my options :-) > I probably added -:hs0 some years ago to avoid heap size yo-yo-ing in a dumb > way ...; > I will not use it for the next experiments. > I need some -:hi option (only for the new GC!), otherwise it crashes as > follows: > > # nallch.x32 -:a0 -:o -:s4096k 0 > [panic] out of memory - cannot allocate next heap segment - execution > terminated
I have experimented some more (with x32 binaries). I am now running my binary with: -:a0 -:hiNNNm -:hm3900m -:o -:s4096k Then, I tried several values NNN for -:hiNNNm. crashes: 2 6 7 8 16 ok: 3 4 5 I added (set-gc-report! #t) and attach a complete log from a crashing run with NNN=6. Ciao Sven > Even -:hm3900m is not helping (although only 715 MB are reported below), > I must give some -:hi option (any value worked so far, smallest test so far > -:hi4m): > > # nallch.x32 -:a0 -:hi128m -:o -:s4096k 0 > > Output from chicken's (time <my-top-level>): > > 733.251s CPU time, 100.732s GC time (major), 1033919871/121748867 mutations > (total/tracked), 183/1968864 GCs (major/minor), maximum live heap: 714.99 MiB > >> - The first patch would bump the heap size up if your program constantly >> needed, say 255.99MB of memory (so it'd generate 10k of garbage, run major >> gc, generate 10k of garbage, run major gc, ...). So, if you've chosen >> 256m conservatively, taking your input data into account, the patches >> don't help. >> - The second patch is a simple hysteresis control that mitigates rapid >> heap size yo-yo-ing. Using -:hs0 prevents that completely. >> >> Also, there won't be that much speed-up if the major-gc-time to >> total-run-time ratio is low to begin with. > > The ratio was at 35 % on older hardware (esp. slower RAM is causing this high > ratio, I guess) and is now down (on a i9-9900K CPU) to 13.7 % > as calculated from the above output from (time <my-top-level>). > > Ciao > Sven >
ch-crash.log.zst
Description: Binary data