4 ms·

No matter how fast, Garbage Collection will always cause a performance knock-on effect by kicking useful stuff out of cache.

• pjmlp 5y ago
  No matter how productive, high level languages will always cause a performance knock-on effect by kicking useful stuff out of instruction cache and internal registers. Yet they are useful.
  • sebastianconcpt 5y ago
    Right, the cost of maintaining systems would be exponentially high for a marginally irrelevant gain on an edge case.
    • pjmlp 5y ago
      Developer salary per hour * time developing the feature * time spent bug fixing * number of team members + hardware infrastructure cost
  • titzer 5y ago
    What high-level language feature causes inherently increased register pressure?
    • pjmlp 5y ago
      Assembly allows to use all of them, and there is no need to reserve any for ABI, other than syscalls or specific opcode requirements. On high level languages one needs to hope that the register allocator does a good job.
      • titzer 5y ago
        Ha, well. I just spent a fair bit of time writing an interpreter in assembly and hand-optimized the regalloc to the limit. But I was surprised by my competitors written in C and how well gcc, in particular, could regalloc hairy interpreter loops. Compilers are very good at register allocation at the right granularity; they just generally don't do it across procedures.
        • zozbot234 5y ago
          > they just generally don't do it across procedures. They won't do it for extern (i.e. separately compiled) calls, because the ABI wouldn't really allow for anything of the sort. But calls to static (or inline) procedures that only have visibility within a single source file can occur with arbitrary calling conventions, so the compiler is free to optimize register allocation across procedures.
        • pjmlp 5y ago
          Sure it is a matter of how good the regalloc algorithm is, and how many registers are there to play with. My point was more about how we are willing to trade the optimal performance for something that gets us there most of the time, while offering much more productive tooling.
• jeffbee 5y ago
  That doesn't really make any sense. The CPU is totally unaware of whatever high-level concept the garbage collector is pursuing. If hot garbage becomes available for reuse, then it's the best outcome.
  • alecco 5y ago
    When the GC starts traversing the list of objects it fills the cache kicking out the previously cached things. This is a known performance problem in optimization. It's quite common. It also happens when having 2+ threads doing a lot of memory access. And caches bring a whole cache line. So for every access, no matter how small, the minimum is 64 bytes are kicked out. Also the prefetch heuristics often bring more (e.g. next cache line). There are cache control instructions but they are rarely used. [0] Reducing Garbage Collector Cache Misses (2000) (HP) https://www.hpl.hp.com/techreports/2000/HPL-2000-99.pdf https://www.hpl.hp.com/techreports/2000/HPL-2000-99.pdf > Cache misses are currently a major factor in the cost of garbage collection, and we expect them to dominate in the future. Traditional garbage collection algorithms exhibit relatively little temporal locality; each live object in the heap is likely to be touched exactly once during each garbage collection. We measure two techniques for dealing with this issue: prefetch-ongrey, and lazy sweeping. The first of these is new in this context. Lazy sweeping has been in common use for a decade. It was introduced as a mechanism for reducing paging and pause times; we argue that it is also crucial for eliminating cache misses during the sweep phase.
    • titzer 5y ago
      GC currently causes a lot of memory traffic, that is true. So don't touch the whole heap. Wow, that reference is old. It doesn't even use a generational collector. Hans is a bright guy and is up-to-date on current GCs; I kind of doubt that he'd agree with your use of his old paper to characterize today's GCs.
    • adgjlsfhk1 5y ago
      The counter to this is that with a moving, generational collector, the GC mainly touches memory in the young generation which then gets moved out of the young generation. This means that GC languages can have better locality since manually managed languages since all your new objects get allocated together better.
• titzer 5y ago
  I don't agree with this. In the limit, an AI (if it is ever as smart as a human[1]) will just introduce malloc/free and stack allocation at the right places. [1] at memory management. I think that it is only a matter of time until machine learning, region-based memory management, and inference of ownership (which really is region-based memory management, tbh) are combined in the right way to get superhuman results.
  • moonchild 5y ago
    > introduce malloc/free and stack allocation at the right places Will it? malloc/free are slow; gc can allocate faster and free faster. And problems are often dynamic and can't be statically determined.
• moonchild 5y ago
  No matter how fast, malloc will always cause a performance knock-on effect by wrecking locality.