5 ms·

Interesting, but if it decreases performance...why do it? I would have hoped cache locality would have beat out the increase due to copying, but per the article

Interesting, but if it decreases performance...why do it? I would have hoped cache locality would have beat out the increase due to copying, but per the article it doesn't sound like the case.

deleted 3y ago
[deleted]
emeryberger 3y ago
Hi, Mesh co-author here. The point of the work was to save memory by “virtual compaction”; we hoped to be able to do this while not degrading performance too much, since compaction typically is quite costly. Our empirical results found that Mesh saves memory by between 16% to 39%, while imposing very modest slowdowns, e.g. 1% for Firefox (see Section 6 of the paper - https://people.cs.umass.edu/~mcgregor/papers/19-pldi.pdf https://people.cs.umass.edu/~mcgregor/papers/19-pldi.pdf).
- nu11ptr 3y ago
  Thanks for the follow up. 1% slowdown easily worth that level of memory savings IMO. I guess the goal was simply different than I expected.
- nahuel0x 3y ago
  Besides memory saving, there are workloads that can still fragment the memory even using Mesh to a point that you can't compact / allocate no more? I'm thinking about Embedded systems were maybe you can have a max number of dynamic allocations but whose number oscillates a lot over time with different patterns. What are the limits of Mesh?
  - emeryberger 3y ago
    Mesh's fragmentation protection is probabilistic (but highly effective) and as fragmentation grows, the likelihood of it being able to perform compaction also grows. Intuitively, if you have lots of sparsely allocated pages, Mesh is almost certainly going to be able to find many pairs of pages that it can "mesh" together into a single physical page. If the pages are too dense, then Mesh becomes ineffective, but that's exactly the point where there's little opportunity to squeeze out memory savings and the pages aren't really fragmented.

5 ms·

Interesting, but if it decreases performance...why do it? I would have hoped cache locality would have beat out the increase due to copying, but per the article

by nu11ptr 3y ago

Interesting, but if it decreases performance...why do it? I would have hoped cache locality would have beat out the increase due to copying, but per the article it doesn't sound like the case.

deleted 3y ago
[deleted]
emeryberger 3y ago
Hi, Mesh co-author here. The point of the work was to save memory by “virtual compaction”; we hoped to be able to do this while not degrading performance too much, since compaction typically is quite costly. Our empirical results found that Mesh saves memory by between 16% to 39%, while imposing very modest slowdowns, e.g. 1% for Firefox (see Section 6 of the paper - https://people.cs.umass.edu/~mcgregor/papers/19-pldi.pdf https://people.cs.umass.edu/~mcgregor/papers/19-pldi.pdf).
- nu11ptr 3y ago
  Thanks for the follow up. 1% slowdown easily worth that level of memory savings IMO. I guess the goal was simply different than I expected.
- nahuel0x 3y ago
  Besides memory saving, there are workloads that can still fragment the memory even using Mesh to a point that you can't compact / allocate no more? I'm thinking about Embedded systems were maybe you can have a max number of dynamic allocations but whose number oscillates a lot over time with different patterns. What are the limits of Mesh?
  - emeryberger 3y ago
    Mesh's fragmentation protection is probabilistic (but highly effective) and as fragmentation grows, the likelihood of it being able to perform compaction also grows. Intuitively, if you have lots of sparsely allocated pages, Mesh is almost certainly going to be able to find many pairs of pages that it can "mesh" together into a single physical page. If the pages are too dense, then Mesh becomes ineffective, but that's exactly the point where there's little opportunity to squeeze out memory savings and the pages aren't really fragmented.