Re: [PATCH 1/2] Prevent excessive major gcs by having decent amount of unused heap

[Sven Hartrumpf]

Hi Mario.

Mario wrote, 2021-01-12 19:17:
> Hi Sven,
>
> On Tue, 12 Jan 2021 13:44:04 +0100 (CET) Sven Hartrumpf <hartrumpf@gmx.net> 
> wrote:
>
>> Mario wrote, 2021-01-12 12:39:
>>>
>>> On Tue, 12 Jan 2021 11:42:31 +0100 (CET) Sven Hartrumpf <hartrumpf@gmx.net> 
>>> wrote:
>>>
>>>> Mario, 2021-01-10 10:03:
>>>>>
>>>>> On Sat, 09 Jan 2021 15:14:31 +0100 (CET) Sven Hartrumpf 
>>>>> <hartrumpf@gmx.net> wrote:
>>>>>
>>>>>> Thanks for the patches and the tests!
>>>>>>
>>>>>>> I ran a relatively extensive set of benchmark configurations comparing
>>>>>>> CHICKEN from master against CHICKEN from master plus the patches.
>>>>>>
>>>>>> I would like to run some real-world benchmarks.
>>>>>> They are dynamically linked.
>>>>>> Would it be enough to run them with the different libchicken.so.11 
>>>>>> versions
>>>>>> (before and after GC patch) or should I recompile my programs?
>>>>>
>>>>> If your binaries are dynamically linked and use a version of CHICKEN
>>>>> which is ABI-compatible with the code in master (ABI version 11),
>>>>> switching libchicken.so (e.g., via LD_LIBRARY_PATH) without recompiling
>>>>> your code should do the trick.
>>>>>
>>>>> If you can, please let us know about your benchmark results.
>>>>
>>>> The results for x86-64 show improvements (- 2 % run time);
>>>> for i586 and x32, the results show slowdowns (+ 1-2 % run time):
>>>>
>>>> GC     arch.   avg. runtime in ms
>>>>
>>>> old gc x86-64  615
>>>> new gc x86-64  601
>>>>
>>>> old gc x32     505
>>>> new gc x32     509
>>>>
>>>> old gc i586    728
>>>> new gc i586    739
>>>>
>>>> (My benchmark is a semantic natural language parser, which is GC-intensive.
>>>> C compiler is gcc 9.3.0 from Ubuntu 20.10.)
>>>>
>>>> Maybe the changes are somewhat biased for x86-64 and
>>>> could be adjusted for i586 and x32?
>>>
>>> Thanks for sharing your results.
>>>
>>> To be honest, the differences in your results are so small I'd flag them
>>> as "noise".
>>> Are you sure the right CHICKEN libraries were being used?
>>
>> Yes. I checked it several times and ran all benchmarks at least 3
>> times.
>
> Ok.  Thanks for confirming that.
>
>> For the longer run times, I also guess that this might be a random effect
>> of other GC settings etc.
>
> Could be.  Do you compile/run your program with some non-default options?

Compile options are:

 -d0 -O5

Run options are:

-:hi256m -:H -:hs0 -:o -:s4096k

To be fair, I should probably half -:hi (and -:s ?)
for i586 and x32?

>> If "x86-86" in http://parenteses.org/mario/misc/benchmarks-megane/ means
>> "x86-64",
>
> Indeed.  It was a typo.  Thanks for spotting and reporting it.  I've
> fixed it.
>
>> then you have already checked for two of the three discussed
>> architectures that the GC changes are improving runtime on average.
>> (If you have some time, maybe a comparison with x32 would be interesting.)
>
> I can try that.  Would you recommend any Linux distribution that
> provides an installer with x32 support?  Or any convenient method to get
> a x32 system running?

Ubuntu has a very stable multiarch setup. If you install a 64bit Ubuntu, you 
can add
x32 support as follows (please adjust to the gcc versions you need):

  apt install libc6-dev-x32 libc6-x32 libx32atomic1 libx32gcc1 libx32gcc-7-dev 
libx32gcc-8-dev libx32gcc-9-dev libx32gcc-10-dev libx32stdc++6 libx32z1 
libx32z1-dev pkg-config-x86-64-linux-gnux32

> I'm also gonna run the benchmarks on Ubuntu 20.10 with the same
> toolchain you used to see if the toolchain could be responsible for
> flattening the results.
>
> Some combinations benefit much more than others.  For example,
> http://parenteses.org/mario/misc/benchmarks-megane/x86/stock-vs-megane-gcc.html
> is amazing, but
> http://parenteses.org/mario/misc/benchmarks-megane/x86-64/stock-vs-megane-extra-clang-speed.html
> not so much.
>
> It might also be the case that your application simply doesn't benefit
> from the patches...
>
> Since you asked whether recompilation of programs was necessary, I
> suppose it is not easy for you to call your application with the `time'
> macro wrapping a strategic entrypoint, right (it'd require recompiling
> it)?

No problem, I will do this now.
(I just wanted to avoid the recompilation hours to speed up experiments :-) )

> With that we could have a better idea on how the patches influence
> the runtime aspects of your program (e.g., number of GCs, their duration
> etc.).

Ciao
Sven

> All the best.
> Mario
> --
> http://parenteses.org/mario
>