On Mon, Jul 29, 2013 at 12:20 AM, Jonathan S. Shapiro <[email protected]>wrote:
> David, I think it's clear that you feel very strongly opposed to GC in > some circumstances, and that's a perfectly OK choice for you to make. I > don't share your view. I don't think that there will *ever* be a GC > solution that is completely free of tradeoffs, just as there isn't a manual > solution that is completely free of tradeoffs. > I want to explain more about my experiences and bias with respect to GC. However, before I do I have a smaller point that came up while writing the essay below. I think Shap and I substantially agree about GC and the need to end world-stop. Where I think our opinions may differ is in the roles and priorities of unmanaged and regions in surmounting GC's limitations. I've stated here before that I believe managed programming becomes dramatically more viable once it achieves no-user-perceivable-world-stop and <~25% CPU and memory overhead. This is the point where I believe it should replace unmanaged for substantially all systems programming (controlling for other factors). However, when we discuss managed viability for systems programming we have to accept that whether we can achieve 25% CPU and memory overhead with tracing GC is *workload* *dependent*. Systems programming by nature is not program dependent, because it's about building components to build (any) program! Herein lies the crux of GC for systems programming. For some applications, GC is notably faster than manual collection. "faster" is too abstract a term. We need to make claims regarding either CPU-Efficiency or Responsiveness. GC (with world-stop) has notably worse responsiveness than manual-collection. This is because the timing of GC can not be controlled while the timing of manual collection can be precisely controlled. GC (with no world-stop) should have similar or better responsiveness than manual-collection, with an amount of CPU-and-Memory Overhead which is related to tenured heap-churn rate. ---- Why am I opposed to tracing-GC in some circumstances? I'm a capitalist entrepreneur who feels *very* strongly about user-centered design. If a developer can demonstrate a successful application in C that I can't create a user-accepted equivalent for in language-X, then I don't believe language-X is a good long-game replacement for C. I don't get to re-write the rules of what a user will accept, because ultimately he will just ignore me and use the faster/less-pausing version written in C. If a developer ignores this and believes he knows better than the user, his competitor will not make this mistake and (all other things being equal) will beat him in the market. The user does not care about language issues, they care about product function and quality. The user does not care about CPU time, they only care about wall-clock time. In capitalist product design, the user-ends justify the developer-means so long as net-profits are positive (or similar). ----- In new/emerging technology products, the above realities work in favor of high-level-languages, since a small team can often make a product *exist* in a highly productive GC language faster than one could do so in C/C++. It turns out that the latency of a product which exists is infinitely better than one which does not! However, as a product space matures, customer expectations increase, and given sufficient market-size and margin, programer effort put into better meeting user-needs (including responsiveness) tends to pay off. This inspires a very common pattern of low-volume software products written in very-productive very-slow languages, which are eventually refined into high-volume products written in very-fast not-so-productive languages. Often because of the solidification of these later codebases, this engenders a cyclic pattern where dramatic product shifts restart the cycle and achieve the same endpoint. These realities of user-centered design inevitably and pervasively lead to addressing user-percieved latency in the 95th+ percentile, which after some small amount of work quickly become dominated by GC pauses in stop-the-world systems. This is despite the fact that as a systems-whole, including kernels, storage, libraries, and application code... the GC related code and heaps today usually represent a *tiny* fraction of total code and heap data. If the entire stack contained stop-the-world GC, reaching acceptable user-latencies would be impossible IMO. ---- I know (Shap) supports the end of world-stop, but there is a difference in our prioritization which some comments from Bennie recently made more clear to me. Authoring and popularizing runtimes is a social effort. Without the deep pockets of a funding organization, I don't believe that social support will arrive for a systems runtime unless there is current-proof it has no achilles heel. That is no world-stop, and no common practical problems which have unviable CPU and/or memory efficiency. Without this proof, I can't be convinced it can even be used for all application programming problems, let alone systems programming for all application programming problems. It is effectively a research effort to learn from not a practical system to use for systems programming. (though it may be useful for application / embedded system development) Because of this, for me, a practical systems-programming system needs to end the world-stop first and experiment with other ideas second. I believe Shap's priorities are (currently) different than this.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
