| |||||||||||||
TasteTastePosted Sep 6, 2007 9:36 UTC (Thu) by lysse (guest, #3190)In reply to: Taste by ncm Parent article: LinuxConf.eu: Documentation and user-space API design
That oh-so-tiresome allegiance to garbage collection probably has something to do with forty years' worth of studies finding that GC is both faster and safer than manual memory management (indeed, as you back-handedly acknowledge, if your program quits before a GC cycle is needed GC is even cheaper than stack allocation). Moreover, many concurrent algorithms are known which eliminate long GC pauses in exchange for a memory float (and exhibit far better performance than reference counting), so unless ITA's Lisp is using a 1960-vintage mark'n'sweep collector it's not clear why they would have to care about GC cycles; and given Lisp's customisability, nor is it clear why they haven't replaced the collector with something a bit more modern.
Most people, when they argue against GC, take two tacks - "it's slow" (which has by now been thoroughly discredited; there are well known ways to make GC fast, and incremental and concurrent collectors completely abolish GC pauses, making GC suitable for realtime applications) and "it wastes memory", which has more truth to it, but only because there's a fairly obvious tradeoff between time spent doing GC and memory overhead (if you have enough memory for everything you'll ever allocate, GC is free; work down from there). If your arguments are more substantial, I'd love to hear them; but "if it ain't C it ain't fast enough" is a meme that really needs to be put out of its misery at the earliest opportunity, at least until developer time becomes as cheap as computer time again.
Not least because when it really mattered, C wasn't even fast enough.
(Log in to post comments)
Taste Posted Sep 6, 2007 10:20 UTC (Thu) by IkeTo (subscriber, #2122) [Link] > "it's slow" (which has by now been thoroughly discredited; there are well> known ways to make GC fast, and incremental and concurrent collectors > completely abolish GC pauses, making GC suitable for realtime applications)
I think one problem of many GC systems is that they make everything an object that requires the GC to handle. GC is perhaps faster than manual object creation and destruction, but it is definitely slower than no object to create/destruct at all. You can say a piece of Java code that generates an Int and throw it away 2G times is faster than a piece of C++ code that new an int and delete it 2G times. But that's not the point if the only way to pass a modifiable parameter to a method is to create such an Int (or actually worse, create an object containing a public int field and pass that object around), while a C++ programmer will happily just use an int& as a parameter, making sure that there is no exchange of objects in the trade.
Not that I think performance should always be such a big sell. For me, I like the Python system better: it does GC and thus saves the programmers the hassle to manually deal with them; it uses reference counting most of the time so the GC cost is mostly spread across all accesses, and it uses full GC is those corner cases involving containers so that a cycle won't eat your memory. So it more or less combines the best of the world, except for the GC overhead which I care very little anyway.
Taste Posted Sep 6, 2007 11:20 UTC (Thu) by lysse (guest, #3190) [Link] As far as I can tell, the subjects of "creating objects for everything" and "passing certain parameters by reference" are completely independent of each other. For instance, Oberon and Modula-3 mandate GC, yet also allow integers to be passed by reference without creating new objects to hold them. Java is far from the last word in either GC design or call-by semantics...
Taste Posted Sep 6, 2007 12:51 UTC (Thu) by IkeTo (subscriber, #2122) [Link] You focus too much on the Java side, and missed the point intended: on the C++ side, no object "creation" or "destruction" cost is needed for passing arguments by reference. The integer being passed is simply created on the stack, allocation cost shared with other variables (by just subtracting a larger number on entry of the function) or deallocation cost (it simply restore the value of the base pointer from a fixed location on the stack). What I mean is that in traditional language you can do many actions without allocating/deallocating an object. Yes garbage collection might be "fast", but they cannot beat "no cost". People doing high performance computing should know this, even though most people really should not bother too much with performance.
Taste Posted Sep 6, 2007 15:42 UTC (Thu) by lysse (guest, #3190) [Link] > You focus too much on the Java side
...which is presumably why I didn't reference two other languages that allow precisely what you're complaining about garbage collected languages not allowing - oh, wait...
> and missed the point intended: on the C++ side, no object "creation" or "destruction" cost is needed for passing arguments by reference.
*sigh* What I said went completely over your head, didn't it...?
Again, that's EXACTLY the point I caught and responded to. Allocating objects on the stack and passing parameters by reference are, contrary to your apparent belief, neither innovations in C++, nor rendered impossible in a garbage collected language; again I cite Oberon, which is just fine with both and yet fully GC'd.
And the issue of whether every first-class, dynamically-allocated object a language deals with must be allocated on the heap is a different one again; lots of optimisations, of varying degrees of complexity, are known that reduce the heap burden substantially. (Indeed, the MLkit compiler statically tracks object lifetimes and allocates up to eight different stacks in heapspace, giving compiled ML programs the speed of stack allocation with the correctness of garbage collection.) But even when all objects must be heap-allocated, it's not necessarily the end of the world in performance terms; Appel (1987) shows that garbage collection can still end up faster than stack-based allocation.
Taste Posted Sep 6, 2007 16:00 UTC (Thu) by IkeTo (subscriber, #2122) [Link] > Allocating objects on the stack and passing parameters by reference are,> contrary to your apparent belief, neither innovations in C++, nor rendered > impossible in a garbage collected language; again I cite Oberon, which is > just fine with both and yet fully GC'd.
I never say they are never "rendered impossible" (Even C++ does that!), and the "apparent belief" seems very speculative (e.g., Even assembly does stack based allocation!). Let me remind the beginning of my original post.
> "I think one problem of *many* GC systems is that..."
What I mean is that many "short-comings" that others talk about GC are not intrinsic to the availability of GC, but instead they are due to particular languages which have made certain choices, like which of the allocations they choose to tax the GC system. Again, most people should not care at all.
> Appel (1987) shows that garbage collection can still end up faster than
I'm interested in this work. Is it available on-line, or if not, can you give the name of the journal/conference where it appear in?
Taste Posted Sep 6, 2007 16:16 UTC (Thu) by lysse (guest, #3190) [Link] > What I mean is that many "short-comings" that others talk about GC are not intrinsic to the availability of GC, but instead they are due to particular languages which have made certain choices, like which of the allocations they choose to tax the GC system. Again, most people should not care at all.
In that case, then I thoroughly misunderstood you - I thought you were making exactly this mistake yourself. Sorry.
> I'm interested in this work. Is it available on-line, or if not, can you give the name of the journal/conference where it appear in?
It's available online: http://citeseer.ist.psu.edu/appel87garbage.html
Taste Posted Sep 6, 2007 17:03 UTC (Thu) by IkeTo (subscriber, #2122) [Link] > It's available online: http://citeseer.ist.psu.edu/appel87garbage.html
Thanks. Just read it briefly. I would not agree that GC is faster than stack allocation because of that, though. I echo Stroustrup's joke that if you have that much memory you are supposed to use them to prevent any process from getting into the swap. =)
Taste Posted Sep 7, 2007 23:48 UTC (Fri) by lysse (guest, #3190) [Link] Fair enough, but his opinion was peer-reviewed. :)
Taste Posted Sep 8, 2007 6:41 UTC (Sat) by IkeTo (subscriber, #2122) [Link] > Fair enough, but his opinion was peer-reviewed. :)
Peer review process seldom block correct but practically irrelevant work. :)
Taste Posted Sep 6, 2007 15:51 UTC (Thu) by foom (subscriber, #14868) [Link] Here's some links:
http://www.lisp.org/HyperSpec/Body/dec_dynamic-extent.html
http://www.sbcl.org/manual/Dynamic_002dextent-allocation....
Taste Posted Sep 6, 2007 20:39 UTC (Thu) by mikov (subscriber, #33179) [Link] In practice, with the current GC implementations and languages, GC is both slow and noticeable. There is no point in arguing this at all, because I experience it every day - in the Java applications I develop, as well as the ones I use.
You could say that I should use another vendor's implementation (e.g. - http://domino.research.ibm.com/comm/research_projects.nsf... - which AFAIK isn't free), or use this or that magical runtime option (naturally after doing heavy profiling), or move to a quad core CPU, but that doesn't change the _default_ situation.
Plus, technically speaking, GC is extremely complex and complexity isn't free.
You cannot have fast concurrent GC without affecting and significantly complicating the generated code - you need to track asynchronous changes, synchronize threads, etc - all very complicated and error prone operations that have a definite cost. It is no accident that there are no accurate concurrent open source collectors. AFAIK the Mono developers are working on something - http://www.mono-project.com/Compacting_GC - but it is not ready yet.
Taste Posted Sep 8, 2007 1:48 UTC (Sat) by lysse (guest, #3190) [Link] > You could say that I should use another vendor's implementation (e.g. - http://domino.research.ibm.com/comm/research_projects.nsf... - which AFAIK isn't free)
The last sentence of *that very page* says otherwise. Is the rest of your argument constructed with as much care as this?
Taste Posted Sep 8, 2007 2:03 UTC (Sat) by mikov (subscriber, #33179) [Link] "Metronome Garbage collection is now commercially available under the name WebSphere Real Time. This product is the result of a collaboration between the Metronome team and IBM Software Group. The first implementation of Metronome was in the open-source Jikes Research Virtual Machine (RVM)."
Do I misunderstand the meaning of the words "first implementation was" and "commercially available" ? Besides, if you had bothered to read my post, you'd see that the "freeness" of an implementation is a secondary point. You'd also probably know that extracting a GC from a research project and transplanting it into another JVM is not a mere technical detail.
Judging by the arrogant and dismissive tone of your post, I can only conclude that you have nothing informative to say on this subject. I also dare say that your attitude negates the value of all of your posts on the subject, (which even though I didn't agree with completely I initially found interesting).
Taste Posted Sep 13, 2007 2:39 UTC (Thu) by lysse (guest, #3190) [Link] You are free to conclude exactly what you please, of course, but consider what conclusions I might have formed that made me decide to be "arrogant and dismissive". Ironic, n'est-ce pas?
Taste Posted Sep 13, 2007 3:06 UTC (Thu) by mikov (subscriber, #33179) [Link] If you aren't saying anything on the subject of garbage collection, why do you bother replying ? I don't know who you are or what your credentials are, so my opinion of you doesn't matter. And vice versa.
My point is clear enough - garbage collection, as it is experienced in practice in everyday life - is slow. There exist solutions, but they are proprietary and far from common.
Please, try to restrain your apparent urge to be rude and either say why you think my point isn't valid (or what your proposed solution is), or go away.
Taste Posted Sep 13, 2007 3:26 UTC (Thu) by lysse (guest, #3190) [Link] I didn't get as far as saying that your point wasn't valid. I said that your fact-checking was laughably unthorough, with the implication that your argument was founded primarily on personal prejudice and you weren't about to let a good fact get in the way. Generally, if I find one claim that's directly negated by the evidence presented in support of it, I don't hang around to see how much of the rest of someone's argument turns out to be a big pile of manure.
And your response to being caught in a falsehood (whether you like it or not, Monotone is unequivocally not non-free; "a commercial version is now available" != "it is not free") was to defend the falsehood and attack your challenger. The former undermines your credibility even further, and gives me no reason to change my initial assessment. The latter has no place in civilised debate, and you should be ashamed of yourself for doing it.
However, the fact that having done so, you then have the hypocrisy and presumption to upbraid me for an "apparent urge to be rude", demonstrates pretty clearly that you *have* no shame. You are not worth communicating woth, frankly, let alone debating. You want to know why I didn't see any good reason for wasting my time on you? Reread your own posts. You've given me no reason to think you're worth a damn, and plenty of cause to decide you aren't - and that's even *before* we consider the merits of your arguments.
I was hoping to avoid telling you exactly what I thought of you, but if you're going to accuse me of rudeness when I am showing restraint, I have nothing to lose. So here it is; I hope it justifies your every prejudice about me, and gives you a few you hadn't thought of. You're not the kind of person I *want* thinking well of me.
Taste Posted Sep 13, 2007 3:53 UTC (Thu) by mikov (subscriber, #33179) [Link] Another post without information. I did not expect that. You don't even have the decency to admit that:- WebSphere Real Time is not free - in any case that fact is irrelevant for the point I was making
At least we will both be confident in the knowledge of that.
Go away, troll.
Taste Posted Sep 13, 2007 11:59 UTC (Thu) by lysse (guest, #3190) [Link] You're still expecting *decency* from me? Weird.
And the funny thing is, for all your assertions that I'm a troll, *you* initially replied to *me*. And then threw a tantrum when I declined to respect your authoritah.
And now you won't stop, because you Just Have to have the last word, even though the sane thing to do would have been to stop responding at least two comments ago.
In real life, you'd be that kid on the playground who tries to butt into a conversation I'm having with my friends and then starts calling me names and complaining to the teachers because I gave you the brush-off.
And I haven't responded to an argument because you haven't MADE an argument. "Real-world GC is slow in my experience" is an assertion, and a subjective one at that, with a huge great amorphous blob of a term in the middle of it. (I've already mentioned hypocrisy, haven't I? Just checking.) Either put something objective and quantifiable on the table, or take your invisible ball and fuck off back to the infant playground.
|
|||||||||||||