[m-rev.] diff: improve simplify_info

Zoltan Somogyi zoltan.somogyi at runbox.com
Wed Mar 8 12:25:13 AEDT 2017



On Wed, 8 Mar 2017 10:23:29 +1100, Peter Wang <novalazy at gmail.com> wrote:

> On Wed, 08 Mar 2017 08:14:15 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> >  
> >  :- type simplify_info
> >      --->    simplify_info(
> > -                % The most frequently used fields.
> > -                % XXX Move another field here from simplify_sub_info
> > -                % to make eight. Boehm will use eight words even for
> > -                % seven fields.
> > +                % The most frequently used writeable fields, held at eight
> > +                % fields (adding even just one more field would cause Boehm
> > +                % to allocate a 16 word cell).
> 
> Please delete this comment, and other similar comments in the compiler
> directory.  They are incorrect.
> 
> You can check Boehm GC's size rounding for small objects by printing
> the GC_size_map with GC_mercury_write_size_map().  Here are the results
> on x86-64.  The i'th number in the list gives the allocation size in
> words for a request of i words.  (The zeros are yet to be populated.)
> 
>       2    2    4    4    6    6    8    8
>      10   10   12   12   14   14   16   16
>      18   18   20   20   22   22   24   24
>      26   26   28   28   30   30   32   32
>      34   34   36   36   38   38   40   40
>      42   42   44   44   46   46   48   48

Thanks for that.

I was under the impression that there was much more rounding up
of allocation sizes, though that came from what Fergus told me about
much older versions of Boehm. Any idea *when* that changed? I just looked
on Hans Boehm's gc page, and in "git blame" for the seemingly-relevant
gc header files in the boehm directory, and did not find that information.

At least this explains why making the top level of module_info 11 words
in size could be better than making it either 8 or 16 words in size.

I will fix the comments to say that boehm rounds up not to the next
power of two, but only to the next multiple of two, but I may also do
some experiments to see whether this opens up the possibility of
any new speedups.

Zoltan.



More information about the reviews mailing list