EvanED wrote:korona wrote:EvanED wrote:Edit again First, the 70% measurement is for double the heap size of the explicitly-managed program; the intro doesn't say that, but the other two places do and that can be read off table 4.
Is for the double average heap size (the second column) but for roughly the same maximum heap size (the first column) i.e. the amount of memory required for GenMS. Since GenMS uses mark and sweep in the mature space I suspect that this is roughly the same amount required for manual allocation. The paper does not talk about the relation of minimal memory required by GenMS to the minimal memory required by manual allocation.
That's not my reading of table 4.
The caption says "The heap sizes are multiples of the minimum amount required to run with GenMS." That means that the first row is the minimum heap size for GenMS. I read the next column as showing the overhead in heap size relative to the manual memory manager -- 210%. That means that GenMS won't even run until you double the heap size relative to the manual allocator. This is consistent with figure 3 as well, which shows table 4 graphically: "Points in the graph represent the heap footprint (the x-axis) and runtime (y-axis) for the garbage collection algorithm relative to the explicit memory manager", and the first data point for GenMS is about x=2. It's also consistent with version of the sentence I quoted before that's in the abstract and conclusion: "with only twice as much memory, garbage collection degrades performance by nearly 70%" -- this matches table 4, where the heap size 1.00 (relative to the minimum that GenMS requires) corresponds to an overhead of 2x vs manual management and a runtime of 169%.
Your interpretation is indeed consistent with the sentence from the abstract. But that would mean GenMS requires twice as much memory as LEA which does not really make sense because GenMS is basically manual allocation for the large mature generation. The caption of table 4 also says "Geometric mean of memory footprints and runtimes for GenMS versus Lea", so I think they are comparing average footprint and not minimal heap size required for GenMS vs. Lea in column 2. EDIT: I think you're right and geometric mean means geometric mean over all benchmarks in this case. It is still surprising that GenMS needs so much memory. Does that imply that the young generation is as least as big as the mature one in their configuration?
sourmìlk wrote:Well, yeah. My point is just that, when a garbage collected language runs ten times slower, it's not appropriate to use that language. I really fail to see that controversy in that statement. I don't think there is one, I think people are miscommunicating.
I think the point of contention is just of whether a 10x slowdown is likely to happen in practice. I say that such situations are very rare, and it's usually more useful to worry about other things.
Yes that is exactly the controversy. My point is that the 10 times slowdown will never happen as it only happens if you're using more than 100% of all physical memory, which you would never do. My point is that you would decrease the maximal heap size of your collector and never extend it beyond the size of your physical memory. That way the slowdown will only be 70%.