7 ms·

The Go collector isn't generational or moving, and the write barrier AIUI is only used for getting it to run concurrently. The barrier records interesting write

The Go collector isn't generational or moving, and the write barrier AIUI is only used for getting it to run concurrently. The barrier records interesting writes when the collector is running, to avoid "losing" objects whose liveness changed while the collector was running. Barriers are pretty cheap; [0] claims a 0.9% time overhead for a card-marking barrier common in generational collection and 1.6% for an object-logging barrier which is also useful for concurrent collection. Apparently they're cheaper nowadays, but the results aren't published yet [1]. That's not to say that the barriers are free, but it seems feasible that collector optimisations could still cover that ground. It can help throughput, still, by running the collector concurrently. I've felt that while working on a new parallel (but not yet concurrent) collector for SBCL; the program parallelises well, but a serial collector hurts worse than it should by stopping the program. [0] "Barriers reconsidered, friendlier still!" https://users.cecs.anu.edu.au/~steveb/pubs/papers/barrier-ismm-2012.pdf https://users.cecs.anu.edu.au/~steveb/pubs/papers/barrier-is... [1] https://twitter.com/stevemblackburn/status/1494240906006110209 https://twitter.com/stevemblackburn/status/14942409060061102...

WalterBright 4y ago
In a pointer heavy language like D, a 1% loss is a big deal. I.e. it would no longer be a systems programming language.
- hayley-patton 4y ago
  I would expect to be able to find another 1% slowdown somewhere in an implementation of another "system programming language" - would that also disqualify it from being such a language?
  - WalterBright 4y ago
    It's a competitive business. If a compiler generates 1% faster code, you need 1% fewer servers in your server farm, which translates to enormous amounts of money. Or if your hedgefund trading software runs 1% faster, you can get your trades in faster than the other guy, eating his lunch. Or would you like to reduce your costs of rented servers in the cloud by 1%?
    - hayley-patton 4y ago
      Right, I don't mean to downplay the significance of 1%, but aren't there many ways to win or lose 1%? More specifically perhaps, are there so few GCed pointers that a faster collector cannot recuperate that 1%? moonchild's suggestion to monomorphise against GC/explicitly managed pointers might reduce that figure lower; evidently you know D programs better than I, but it doesn't seem unreasonable that the 1% can be won by a faster GC.
      - WalterBright 4y ago
        > More specifically perhaps, are there so few GCed pointers that a faster collector cannot recuperate that 1%? Of course, it depends on your coding style, but yes, that is generally true.
      - kohlerm 4y ago
        A 1% slowdown is a ridiculous low number IMHO. I would argue that almost no program is within 1% of the optimal speed (however you define it). Therefore practically it does not matter. If you think it matters then the consequence would be that you write everything in Assembler.
        WalterBright 4y ago
        > Therefore practically it does not matter. You won't notice it on your desktop. But you will notice it in cases I mentioned. Top shelf games also are not going to give up that 1%, or so the game devs tell me.
        pjmlp 4y ago
        And yet even the likes of Sony and Nintendo are working in major titles with Unity. Unity is also the official developer SDK for Microsoft's HoloLens Virtual Reality Toolkit.
        jcelerier 4y ago
- vanderZwan 4y ago
  I'm sure the creator of D knows what he's talking about, but doesn't that depend on how much is gained elsewhere?
  - WalterBright 4y ago
    It does. D offers a mix of manual and gc allocating, and the people who want higher overall performance lean towards more manual. Any penalty that applies to pointer code then gets amortized against less use of the gc. It's a different tradeoff if the languages primary allocation scheme is GC.
    - zozbot234 4y ago
      The obvious approach to that issue is to support garbage-collected objects as a special address space within the program. You could use normal read-only pointers to address these, but write pointers to them would be specialized and incur that memory barrier overhead.
      - WalterBright 4y ago
        There's an API call into the GC that does just that, tell you if it points into the GC pool or not. Unfortunately, it's not fast enough.
        zozbot234 4y ago
        Why does this have to be a runtime check? Perhaps the compiler could optimize pointer writes that can be proven not to affect garbage-collected objects, by dispensing with the memory barrier overhead for those.
- titzer 4y ago
  It's possible to lose 5% from a single bad register allocation decision.
  - zozbot234 4y ago
    Register allocation is an NP-hard problem. It's not feasible to reach a single "good" decision, you'll always have to choose how much compiler time should be assigned to it, and what heuristics to use.
    - hayley-patton 4y ago
      To "lose" 5% I imagine one has to only be "worse" than some other heuristic that they measured the results of.
    - chrisseaton 4y ago
      This isn’t a problem in practice - you don’t need a single best solution, because you can get a good-enough solution very easily - linear scan. Classic example of an over-theorised problem.
- IshKebab 4y ago
  Are you really saying that a 1% performance loss makes something "not a systems programming language"? Of all the weird definitions of "systems language" I've heard this has to be the weirdest. 1% compared to what? Hand-written assembly? C? C++? Clang and GCC differ by way more than 1% in most benchmarks. Does that mean that one of them can't compile system languages or something? I mean, I would agree that there definitely is a performance threshold below which you wouldn't consider a language a "systems language" - i.e. it would be silly to write an OS in the language. But 1% seems at least an order of magnitude off.
  - optymizer 4y ago
    I see D as a non-compromising language (in terms of eating your cake and having it too) and that's why I like it. I think the authors don't want to limit its performance at the design level. For equivalent code, they don't want it to only ever be able to run 99% as fast as C, they want it to be able to run, at least theoretically, as fast as C or better. That's probably where the 'systems language' comparison came from. In practice though, I'm willing to bet DMD,GDC and LDC result in more than 1% difference in performance (but that's just speculation).
  - WalterBright 4y ago
    All those 1%'s add up.
- slashdev 4y ago
  It's not a big deal. People give up more than 1% in suboptimal compiler flags alone. People give up far more than that by using unoptimized or lightly optimized code. People give up more than that by being too lazy to use profile guided optimization. Or by using the system malloc. To say that a 1% loss in performance disqualifies something as a systems language is absurd.
  - mumblemumble 4y ago
    One important difference in all of those is that they are decisions made by the user of the programming language, not the author. Sub-optimal performance decisions made by the user are their own business (and, perhaps, their customers'), and not really the language authors' concern. The converse is not true. Sub-optimal performance decisions made by the language authors end up affecting everybody. I agree that saying a 1% difference would disqualify it as a systems language is hyperbolic. I disagree with the assertion that it's not a big deal. Having a core development team that considers 1% to be a big deal is a very desirable trait in a systems language. Achieving very high performance goals often comes through an accretion of many such 1% (and sub-1%) decisions.
    - eloff 4y ago
      The difference in performance between existing systems languages is greater than 1%. This is just not a big deal. People will not choose their systems language based on a 1% performance difference. It's so far down the list of considerations that it's a total non-issue.
      - WalterBright 4y ago
        Would Linus accept a language for core Linux work that came with a 1% penalty?
        diffxx 4y ago
        This question is impossible to answer in a vacuum. What if the language made developers 90% more productive or 90% less likely to introduce a memory bug or offered 3x faster compiler times? A 1% runtime performance hit would be well worth it if that were the case. Perhaps with the extra time available, developers could find better algorithms/ways of expressing their programs that would ultimately lead to faster runtime performance on average even with the 1% hit in certain microbenchmarks.
- TheGag96 4y ago
  I'd probably go even further and say that if there's any hidden check or restriction on reading or writing from a pointer, then it's not a systems language. I'm glad D does not have anything like that.
  - throwaway894345 4y ago
    That seems like a pretty arbitrary definition of "systems language". Lots of hidden stuff happens in "systems languages"--compilers do unintuitive magic all the time, and the languages themselves have their own runtimes.
bachmeier 4y ago
> Barriers are pretty cheap; [0] claims a 0.9% time overhead for a card-marking barrier common in generational collection and 1.6% for an object-logging barrier which is also useful for concurrent collection. Apparently they're cheaper nowadays, but the results aren't published yet [1]. That's not to say that the barriers are free, but it seems feasible that collector optimisations could still cover that ground. A quick look at the paper indicates that researchers were able to find cases in which the cost was as low as 0.9%. I don't think it's a good idea to operate as if that is the cost.

WalterBright 4y ago

In a pointer heavy language like D, a 1% loss is a big deal. I.e. it would no longer be a systems programming language.

hayley-patton 4y ago
I would expect to be able to find another 1% slowdown somewhere in an implementation of another "system programming language" - would that also disqualify it from being such a language?
- WalterBright 4y ago
  It's a competitive business. If a compiler generates 1% faster code, you need 1% fewer servers in your server farm, which translates to enormous amounts of money. Or if your hedgefund trading software runs 1% faster, you can get your trades in faster than the other guy, eating his lunch. Or would you like to reduce your costs of rented servers in the cloud by 1%?
  - hayley-patton 4y ago
    Right, I don't mean to downplay the significance of 1%, but aren't there many ways to win or lose 1%? More specifically perhaps, are there so few GCed pointers that a faster collector cannot recuperate that 1%? moonchild's suggestion to monomorphise against GC/explicitly managed pointers might reduce that figure lower; evidently you know D programs better than I, but it doesn't seem unreasonable that the 1% can be won by a faster GC.
    - WalterBright 4y ago
      > More specifically perhaps, are there so few GCed pointers that a faster collector cannot recuperate that 1%? Of course, it depends on your coding style, but yes, that is generally true.
    - kohlerm 4y ago
      A 1% slowdown is a ridiculous low number IMHO. I would argue that almost no program is within 1% of the optimal speed (however you define it). Therefore practically it does not matter. If you think it matters then the consequence would be that you write everything in Assembler.
      - WalterBright 4y ago
        > Therefore practically it does not matter. You won't notice it on your desktop. But you will notice it in cases I mentioned. Top shelf games also are not going to give up that 1%, or so the game devs tell me.
        pjmlp 4y ago
        And yet even the likes of Sony and Nintendo are working in major titles with Unity. Unity is also the official developer SDK for Microsoft's HoloLens Virtual Reality Toolkit.
        jcelerier 4y ago
vanderZwan 4y ago
I'm sure the creator of D knows what he's talking about, but doesn't that depend on how much is gained elsewhere?
- WalterBright 4y ago
  It does. D offers a mix of manual and gc allocating, and the people who want higher overall performance lean towards more manual. Any penalty that applies to pointer code then gets amortized against less use of the gc. It's a different tradeoff if the languages primary allocation scheme is GC.
  - zozbot234 4y ago
    The obvious approach to that issue is to support garbage-collected objects as a special address space within the program. You could use normal read-only pointers to address these, but write pointers to them would be specialized and incur that memory barrier overhead.
    - WalterBright 4y ago
      There's an API call into the GC that does just that, tell you if it points into the GC pool or not. Unfortunately, it's not fast enough.
      - zozbot234 4y ago
        Why does this have to be a runtime check? Perhaps the compiler could optimize pointer writes that can be proven not to affect garbage-collected objects, by dispensing with the memory barrier overhead for those.
titzer 4y ago
It's possible to lose 5% from a single bad register allocation decision.
- zozbot234 4y ago
  Register allocation is an NP-hard problem. It's not feasible to reach a single "good" decision, you'll always have to choose how much compiler time should be assigned to it, and what heuristics to use.
  - hayley-patton 4y ago
    To "lose" 5% I imagine one has to only be "worse" than some other heuristic that they measured the results of.
  - chrisseaton 4y ago
    This isn’t a problem in practice - you don’t need a single best solution, because you can get a good-enough solution very easily - linear scan. Classic example of an over-theorised problem.
IshKebab 4y ago
Are you really saying that a 1% performance loss makes something "not a systems programming language"? Of all the weird definitions of "systems language" I've heard this has to be the weirdest. 1% compared to what? Hand-written assembly? C? C++? Clang and GCC differ by way more than 1% in most benchmarks. Does that mean that one of them can't compile system languages or something? I mean, I would agree that there definitely is a performance threshold below which you wouldn't consider a language a "systems language" - i.e. it would be silly to write an OS in the language. But 1% seems at least an order of magnitude off.
- optymizer 4y ago
  I see D as a non-compromising language (in terms of eating your cake and having it too) and that's why I like it. I think the authors don't want to limit its performance at the design level. For equivalent code, they don't want it to only ever be able to run 99% as fast as C, they want it to be able to run, at least theoretically, as fast as C or better. That's probably where the 'systems language' comparison came from. In practice though, I'm willing to bet DMD,GDC and LDC result in more than 1% difference in performance (but that's just speculation).
- WalterBright 4y ago
  All those 1%'s add up.
slashdev 4y ago
It's not a big deal. People give up more than 1% in suboptimal compiler flags alone. People give up far more than that by using unoptimized or lightly optimized code. People give up more than that by being too lazy to use profile guided optimization. Or by using the system malloc. To say that a 1% loss in performance disqualifies something as a systems language is absurd.
- mumblemumble 4y ago
  One important difference in all of those is that they are decisions made by the user of the programming language, not the author. Sub-optimal performance decisions made by the user are their own business (and, perhaps, their customers'), and not really the language authors' concern. The converse is not true. Sub-optimal performance decisions made by the language authors end up affecting everybody. I agree that saying a 1% difference would disqualify it as a systems language is hyperbolic. I disagree with the assertion that it's not a big deal. Having a core development team that considers 1% to be a big deal is a very desirable trait in a systems language. Achieving very high performance goals often comes through an accretion of many such 1% (and sub-1%) decisions.
  - eloff 4y ago
    The difference in performance between existing systems languages is greater than 1%. This is just not a big deal. People will not choose their systems language based on a 1% performance difference. It's so far down the list of considerations that it's a total non-issue.
    - WalterBright 4y ago
      Would Linus accept a language for core Linux work that came with a 1% penalty?
      - diffxx 4y ago
        This question is impossible to answer in a vacuum. What if the language made developers 90% more productive or 90% less likely to introduce a memory bug or offered 3x faster compiler times? A 1% runtime performance hit would be well worth it if that were the case. Perhaps with the extra time available, developers could find better algorithms/ways of expressing their programs that would ultimately lead to faster runtime performance on average even with the 1% hit in certain microbenchmarks.
TheGag96 4y ago
I'd probably go even further and say that if there's any hidden check or restriction on reading or writing from a pointer, then it's not a systems language. I'm glad D does not have anything like that.
- throwaway894345 4y ago
  That seems like a pretty arbitrary definition of "systems language". Lots of hidden stuff happens in "systems languages"--compilers do unintuitive magic all the time, and the languages themselves have their own runtimes.

bachmeier 4y ago

> Barriers are pretty cheap; [0] claims a 0.9% time overhead for a card-marking barrier common in generational collection and 1.6% for an object-logging barrier which is also useful for concurrent collection. Apparently they're cheaper nowadays, but the results aren't published yet [1]. That's not to say that the barriers are free, but it seems feasible that collector optimisations could still cover that ground. A quick look at the paper indicates that researchers were able to find cases in which the cost was as low as 0.9%. I don't think it's a good idea to operate as if that is the cost.