Taste
Taste
Posted Sep 6, 2007 10:20 UTC (Thu) by IkeTo (subscriber, #2122)In reply to: Taste by lysse
Parent article: LinuxConf.eu: Documentation and user-space API design
> "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.
Posted Sep 6, 2007 11:20 UTC (Thu)
by lysse (guest, #3190)
[Link] (8 responses)
Posted Sep 6, 2007 12:51 UTC (Thu)
by IkeTo (subscriber, #2122)
[Link] (7 responses)
Posted Sep 6, 2007 15:42 UTC (Thu)
by lysse (guest, #3190)
[Link] (5 responses)
...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.
Posted Sep 6, 2007 16:00 UTC (Thu)
by IkeTo (subscriber, #2122)
[Link] (4 responses)
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?
Posted Sep 6, 2007 16:16 UTC (Thu)
by lysse (guest, #3190)
[Link] (3 responses)
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
Posted Sep 6, 2007 17:03 UTC (Thu)
by IkeTo (subscriber, #2122)
[Link] (2 responses)
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. =)
Posted Sep 7, 2007 23:48 UTC (Fri)
by lysse (guest, #3190)
[Link] (1 responses)
Posted Sep 8, 2007 6:41 UTC (Sat)
by IkeTo (subscriber, #2122)
[Link]
Peer review process seldom block correct but practically irrelevant work. :)
Posted Sep 6, 2007 15:51 UTC (Thu)
by foom (subscriber, #14868)
[Link]
http://www.lisp.org/HyperSpec/Body/dec_dynamic-extent.html
http://www.sbcl.org/manual/Dynamic_002dextent-allocation....
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
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
> You focus too much on the Java sideTaste
> Allocating objects on the stack and passing parameters by reference are,Taste
> 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.
(emphasis added here)
> stack-based allocation.
> 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.Taste
> It's available online: http://citeseer.ist.psu.edu/appel87garbage.htmlTaste
Fair enough, but his opinion was peer-reviewed. :)Taste
> Fair enough, but his opinion was peer-reviewed. :)Taste
Here's some links:Taste