3 ms·

> >3.2 malloc Overhead - When using allocators implemented in C... That's not even about malloc overhead, it's about the overhead of just calling C malloc. So

> >3.2 malloc Overhead - When using allocators implemented in C... That's not even about malloc overhead, it's about the overhead of just calling C malloc. So actual malloc overhead is on top of that. Malloc and free have pretty unpredictable runtime over time, once a lot of allocations and deallocations have been performed. That's why you don't use either in latency sensitive code, like with realtime requirements. > In other words, even if malloc/free is not instantaneous and not cost-free, it can still be faster than GC. Whoah, faster than GC in what regard? GC will probably win the throughput race, or average latency. Manual allocation will likely win the jitter race, lower latency standard deviation. (I write low level code in C/C++, including kernel drivers and bare metal firmware with hard realtime requirements. Hopefully in the future in Rust or some other memory and concurrency safe language.)

jasode 8y ago
>Malloc and free have pretty unpredictable runtime over time, Yes, that's another true statement about malloc but it also doesn't matter to the particular point I'm making. To continue your correct & true statements of malloc, we can add: - malloc has to search the freelist; GC can be just a bump allocation which is faster - malloc leads to fragmented memory; GC can reorganize and reconsolidate - malloc doesn't have extra intelligence to assign pointers to shared memory structures (e.g. Java string pool stores identical strings only once based on hashes) - ... a dozen other true statements about malloc All those true statements (which most can agree on) isn't the misunderstanding. The issue is misusing those true statements as some type of convincing evidence to explain the papers' flaws. For example: >Whoah, faster than GC in what regard? Well, we can just use the total runtime of the the 2 papers benchmarks where there were lots of memory operations. (In other words, we can acknowledge that performance has multiple dimensions/axis but we can also look at the simple measurement of total wall clock time of benchmark code that doesn't do database access or floating point calculations.) The C/C++ programs ran faster and took up less memory. Ok, were there flaws in the benchmarks? Then lets explain the specific flaws. Yes, I can say "malloc runtime is unpredictable" but that true statement doesn't actually explain anything about GC running slower than malloc/free in the papers. We can also say that "malloc is not cost free" as another true statement -- but that also doesn't actually explain the GC's longer elapsed time. See the problem with those attempted explanations? They're all non-sequiturs.
- vardump 8y ago
  > Well, we can just use the total runtime of the the 2 papers benchmarks where there were lots of memory operations. (In other words, we can acknowledge that performance has multiple dimensions/axis but we can also look at the simple measurement of total wall clock time of benchmark code that doesn't do database access or floating point calculations.) ... > See the problem with those attempted explanations? They're all non-sequiturs. I'm comparing GC vs manual memory management. You (or the papers) are comparing different implementations of programs in different languages. That might be great for practical considerations for choosing implementation language, but is pointless when comparing those two different memory management strategies. Apples and oranges. EDIT: I feel "Quantifying the Performance of Garbage Collection vs. Explicit Memory Management" paper is a bit dishonest. From the paper: > The culprit here is garbage collection activity, which visits far more pages than the application itself [61]. As allocation intensity increases, the number of major garbage collections also increases. Since each garbage collection is likely to visit pages that have been evicted, the performance gap between the garbage collectors and explicit memory managers grows as the number of major collections increases. Pages got evicted – so their heap ran out of physical RAM and started swapping to disk. Wow. Yeah, GC uses much more RAM, that's a well known downside. Setting the benchmark up in such a way that causes the system to start swapping is not a fair way to compare GC and manual allocation throughput.
  - jasode 8y ago
    >You (or the papers) are comparing different implementations of programs in different languages. Fyi... the 2nd paper is using the same language of Java. It just compares different allocation strategies: explicit vs GC. (I think that paper is written in a confusing way.) My original point back to op (rwmj) was that the computer scientists were quite aware that malloc had a non-zero cost. And pointing that out really doesn't challenge the paper's findings.
    - vardump 8y ago
      Yeah, and the second paper said their GC scenario system was swapping to disk. Please read my edit to the previous comment.

jasode 8y ago

>Malloc and free have pretty unpredictable runtime over time, Yes, that's another true statement about malloc but it also doesn't matter to the particular point I'm making. To continue your correct & true statements of malloc, we can add: - malloc has to search the freelist; GC can be just a bump allocation which is faster - malloc leads to fragmented memory; GC can reorganize and reconsolidate - malloc doesn't have extra intelligence to assign pointers to shared memory structures (e.g. Java string pool stores identical strings only once based on hashes) - ... a dozen other true statements about malloc All those true statements (which most can agree on) isn't the misunderstanding. The issue is misusing those true statements as some type of convincing evidence to explain the papers' flaws. For example: >Whoah, faster than GC in what regard? Well, we can just use the total runtime of the the 2 papers benchmarks where there were lots of memory operations. (In other words, we can acknowledge that performance has multiple dimensions/axis but we can also look at the simple measurement of total wall clock time of benchmark code that doesn't do database access or floating point calculations.) The C/C++ programs ran faster and took up less memory. Ok, were there flaws in the benchmarks? Then lets explain the specific flaws. Yes, I can say "malloc runtime is unpredictable" but that true statement doesn't actually explain anything about GC running slower than malloc/free in the papers. We can also say that "malloc is not cost free" as another true statement -- but that also doesn't actually explain the GC's longer elapsed time. See the problem with those attempted explanations? They're all non-sequiturs.

vardump 8y ago
> Well, we can just use the total runtime of the the 2 papers benchmarks where there were lots of memory operations. (In other words, we can acknowledge that performance has multiple dimensions/axis but we can also look at the simple measurement of total wall clock time of benchmark code that doesn't do database access or floating point calculations.) ... > See the problem with those attempted explanations? They're all non-sequiturs. I'm comparing GC vs manual memory management. You (or the papers) are comparing different implementations of programs in different languages. That might be great for practical considerations for choosing implementation language, but is pointless when comparing those two different memory management strategies. Apples and oranges. EDIT: I feel "Quantifying the Performance of Garbage Collection vs. Explicit Memory Management" paper is a bit dishonest. From the paper: > The culprit here is garbage collection activity, which visits far more pages than the application itself [61]. As allocation intensity increases, the number of major garbage collections also increases. Since each garbage collection is likely to visit pages that have been evicted, the performance gap between the garbage collectors and explicit memory managers grows as the number of major collections increases. Pages got evicted – so their heap ran out of physical RAM and started swapping to disk. Wow. Yeah, GC uses much more RAM, that's a well known downside. Setting the benchmark up in such a way that causes the system to start swapping is not a fair way to compare GC and manual allocation throughput.
- jasode 8y ago
  >You (or the papers) are comparing different implementations of programs in different languages. Fyi... the 2nd paper is using the same language of Java. It just compares different allocation strategies: explicit vs GC. (I think that paper is written in a confusing way.) My original point back to op (rwmj) was that the computer scientists were quite aware that malloc had a non-zero cost. And pointing that out really doesn't challenge the paper's findings.
  - vardump 8y ago
    Yeah, and the second paper said their GC scenario system was swapping to disk. Please read my edit to the previous comment.