11 ms·
I am mostly doing programming in languages with GC, which in this case is fine because it's OK for it to go, you know, kind of slow.
by bhiggins 16y ago
I am mostly doing programming in languages with GC, which in this case is fine because it's OK for it to go, you know, kind of slow.
- chibea 16y agoOften, manual allocation is even slower. http://lambda-the-ultimate.org/node/2552 http://lambda-the-ultimate.org/node/2552
- jrockway 16y agoNo no, he's an expert programmer that can do repetitive tasks better than a computer.
- anon_d 16y agoWith only three times as much memory, it runs on average 17% slower than explicit memory management. However, with only twice as much memory, garbage collection degrades performance by nearly 70%. When physical memory is scarce, paging causes garbage collection to run an order of magnitude slower than explicit memory management. I don't see how this article is helping your point; that's a pretty massive hit. Even worse, this is a GC-style program modified to use explicit malloc/free. Programming with manual memory management encourages a very different style of programming where you try to use malloc/free as little as possible, and you try keep memory for various things in contiguous chunks of memory. EDIT: This comment is interesting: http://lambda-the-ultimate.org/node/2552#comment-38915 http://lambda-the-ultimate.org/node/2552#comment-38915
- chc 16y agoI think it's the discussion that we're meant to read, not just the OP. Most of the comments are pointing out questionable assumptions in the study (e.g. even though they admit that actually changing the program to use manual memory management would be nearly intractable, they assume that essentially running an AOT garbage collector is equivalent).
- silentbicycle 16y agoThey may have had Appel's "Garbage Collection Can Be Faster Than Stack Allocation" (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.39.8219 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.39.8...) in mind. Also, the technique described in that comment (forking processes with finite lifetimes, allocating but not freeing, terminating and letting the OS clean up all at once) is also what Erlang does, and it seems to work pretty well in practice. Each process has its own arena, for allocation purposes.