On Tue, Jul 30, 2013 at 11:44 AM, Jonathan S. Shapiro <[email protected]>wrote:
> What I *have* said is that the introduction of unmanaged code is > categorically unacceptable. > Even in understanding this, I don't fully understand the boundaries of it. Perhaps it would be useful to be explicit. Where the unsafe code is allowed and who is allowed to write it? The runtime itself must do unsafe things, so certainly that code is unsafe. Assuming a traditional kernel (for now), the syscall interface is unsafe, so the stdlib wrappers around those calls must be unsafe. Is that the only unsafe code allowed? As in, no JNI/PInvoke/FFI, no leverage of legacy code, no restricted unsafe keywords.. ? ...you persistently neglect consideration of the overheads of malloc/free > in your discussions. GC may still lose the performance debate, but if we're > going to argue it on those grounds, let us do so honestly. > This is an interesting point. I don't think I do at all. If I do, I would certainly like to know why and fix it! Please let me know what part of the position below you think is unfairly considering malloc/free costs! (1) I've stated repeatedly that my first issue is Responsiveness, since I run into this in my trivial user-facing GCed programs today. As a user I am *very* intolerant of UI pauses and stuttering, so this problem very much bothers me. As far as I can see, the cost of malloc and free are not forced bounds on responsiveness. Both because practically they don't world-stop proportional to heap-size, and at the limit I can avoid them entirely during a user-interaction thread if I choose (assuming some amount of memory overhead which we both agree is affordable). GC-with-heap-proportional-world-stop is a forced bound on responsiveness, proportional to heap-size. I don't think we disagree on this, if anything I think we disagree on the pervasiveness of this in programs. Every user-facing GC program I've ever written pauses too much for me. My currrent Appstore iOS (2) If we step aside responsiveness (assuming C4 or some sufficiently smart no-world-stop solution), then we're talking about CPU efficiency. I think there are some programs where GC is more efficient (generally smaller heaps) and some programs where GC is less efficient (generally bigger heaps). Since the smaller heaps tend to be smaller problems, I'm more personally frustrated by the latter. AFAIK, malloc/free generally have a tradeoff between memory efficiency (packing overhead), fragmentation, and cpu-cost. In the general case this can be a problem, but it presents no bound on specific program behavior in the limit case, since I'm free to implement whatever system I want on top of malloc/free, including my own (unsafe) region system, buffer recycling, etc. GC reclamation has num_pointers/free_pointers ish costs. When num_pointers becomes very large (aka a large percentage of total ram), tracing GC CPU efficiency is worse than manual allocation. AFAIK, there is no debate about this, the debate is how often this happens in programs. The challenge with using only tracing-GC is you're stuck with this cost. There is no way out of it. I 110% support efforts to hybridize managed systems to get out of this "stuck with GC costs" problem. First class regions would be a great tool. For me they don't solve the hard problems that break GC efficiency, but I can certainly think of ways to use them. ARC feels like another tool in the bag, I seem more willing to give the programmer responsibility for using ARC only when they know there are no cycles. Where in all that am I treating malloc/free costs unfairly relative to other options? I'd like to know! > 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. >> > > Very well. For many applications, the total CPU overhead of GC is > dramatically *less* than that of memory storage, while running within > acceptable real-memory bounds and impeding responsiveness no more than > other sources of preemptive system activity. > ... true. And for many applications it is not. My subjective opinion is that there are more applications stuck in unsafe land because of GC responsiveness problems than CPU or memory overhead. Since you assert $100 more in memory (or CPU) should be irrelevant costs to us, do you agree Responsiveness is the main problem in today's GC implementations? > 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. >> > > Because it is inadequately qualified, this statement is false. > ...yes! let me fix it.. "for many applications, especially those that are directly interacting with end-users, via GUI systems, running on the client, driving the pixels, and pixel motion, and rendering.".. Lots of qualification. I think that's still a pretty good number apps. I agree that for many -other- applications GC has come of age and take over. HTTP servers in Java, Python, Ruby, node.js, etc, etc. This is possible because these are not directly connected to end-users. The unsafe, C++, non-pausing web-browser is providing an insulating layer for non-pausing real-time user interaction. 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. >> > > This is an *excellent* summary of where we disagree. > My statement above is not my preference or belief. It is a statement of darwinian scientific reality. Systems are not selected for criteria which are decided by intelligent design but by factors which dictate their true survival at the most core level. I would *prefer* never to program in unsafe environments again! That's why I'm here, and why I think we're all here. I just accept the darwinian reality above and would rather build products users like which are annoyingly archaic than stand alone trying to convince users their selection factors are wrong. In fact, right now I'm digging into a big old legacy open source C program which I would *love* to write a managed alternative to, if I can just figure out how to get it not to pause! > I'm much less interested in the performance and user perception of > individual applications, and much more interested in systemic effects. If > asked "will you use this slower program rather than that faster program", > the answer is obviously no. If asked "will you accept a requirement for > $100 more memory in order to dramatically improve your system security and > stop worrying about many classes of attacks" the answer really should be > yes. > We agree 100% here. The practical trouble I'm having is that there is no amount of memory or CPU I can reasonably get users to buy to stop end-user apps from pausing while written in managed code. I recently wrote a *trivial* iOS game in Xamarin/Mono which has perceptible GC pauses. Fortunately, I'm able to hide them because the main UI and animation loop is run in separate Objective-C threads which are not affected by the world stop. If they were managed too it would be horrible. Java Swing apps pause horribly, for example. However, I feel like I'm harping on the need for no-world-stop, despite the fact that I know you agree about this need. WIth no sarcasm intended, if you really believe I am pursuing the wrong > path, you can and should start a project to address the things that you > believe are important. Of course you are pursuing a great path, or I wouldn't be here! I'm personally more motivated by end-user product creation than runtime creation. Through those efforts I've used GC to great effect and also been pained by it. I'm here largely out of frustration about the GUI apps I can't write today in managed-languages because of GC pauses. Perhaps I should throw a stake in the sand, pick a daunting app, and force myself to write it managed even if it ultimately means patching the runtime to remove the pauses. (probably Mono)
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
