[m-dev.] Article about memory fragmentation
Zoltan Somogyi
zoltan.somogyi at runbox.com
Mon Oct 10 11:06:53 AEDT 2016
On Mon, 10 Oct 2016 10:40:13 +1100, Paul Bone <paul at bone.id.au> wrote:
> I received some feedback via twitter regarding the Memory Pool System (MPS),
> another GC for uncooperative environments.
>
> https://twitter.com/glaebhoerl/status/784737682706538496
>
> IIRC we've tried this in the past and found that it didn't perform as well
> as BDWGC. But I wasn't involved with Mercury at the time and things may
> have changed. @glaebhoerl provided this link
> https://gitlab.com/embeddable-common-lisp/ecl/issues/126 suggesting that it
> might be worth a look as ti may perform better. I know very little about
> MPS so there's not much I can say about this. But I said I'd pass the
> information on to the other Mercury devs.
When we last tried MPS, MPS wasn't just slower than BDW. Reasonably often,
in maybe 10-20% of cases, it was *much* slower, as in go-get-a-cup-of-coffee
slower. This was despite the fact that our reason for looking into it then was that
it was said to be faster than BDW at the time.
Even if it has improved in the meantime, I am pretty sure there is no point
in looking into it any further, for two reasons. One, I am skeptical that they
could improve things dramatically enough to catch up to BDW, at least for
usage scenarios like ours. Two, with today's memory sizes, gc is, in most
cases, a relatively small fraction of execution time. Therefore even improvements
in the 10-20% range in gc time would translate to only very minor improvements
in overall execution time. The investment required just isn't worth it.
Zoltan.
More information about the developers
mailing list