Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs with the SpiderMonkey garbage collector

lists.gnu.org

Post reply on HN
Print view View original

41–46 of 46 posts

Re: Emacs with the SpiderMonkey garbage collector

#41

Post by taeric »

krylon wrote: post #38
taeric wrote: post #6

Earlier quoted context omitted.

This is asked in the thread, though I'm not sure I saw a good answer, yet. Basic answer is if there are complaints with the garbage collector causing stalls or other hiccups, then moving to a faster one could help. Now, this implies that a new one would, ipso facto, be faster. That is not guaranteed. But, garbage collectors have gotten quite effective in modern times. Extra memory helps, of course.

> Basic answer is if there are complaints with the garbage collector causing stalls or other hiccups, then moving to a faster one could help. Is that an actual problem, though? Maybe I just don't push Emacs that far, but I have never felt GC performance to be much of a problem on even remotely capable hardware (say, anything at least as fast as a Raspberry Pi model 2). Plus, Emacs allows the user to configure the fre…

I personally doubt it is much of a problem. However, that doesn't mean I personally think nobody should try it. Will be interesting to see if any results follow.

To your point, though, I suspect better async processing would be of much greater benefit.

Re: Emacs with the SpiderMonkey garbage collector

#42

Post by avogadro »

bitwize wrote: post #39
rurban wrote: post #30

Earlier quoted context omitted.

Not 5x as much ram. Exactly 2x more ram. You copy between two half spaces, back and forth. That's why it's usually also called semispace collector. What you are talking in the 2nd paragraph is total nonsense in a lisp world. Lisp solved this problem decades ago, with copying collectors. Stack values are 20%, plus refcounts do not work with rplac* able trees and are super slow.

Yes -- five times as much RAM: http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf As it turns out, compared to the analysis and tree traversal inherent in even a fast GC algorithm, the overhead of malloc() and free() is really quite small. So yes, it takes twice as much memory to use a copying GC, right out of the starting gate -- but in order to match the performance of the equivalent explicitly managed program,…

> Yes -- five times as much RAM: http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf

That article was presented at OOPSLA '05 which ran from October 16–20, 2005. I don't know when it was written, nor when the data for it was worked out. That said, it seems safe to say that it's more than twelve years out of date.

Re: Emacs with the SpiderMonkey garbage collector

#43

Post by arcticbull »

mrighele wrote: post #37
arcticbull wrote: post #33

Earlier quoted context omitted.

It's not that it's impossible in C++ just that it's impractical to write large-scale solutions with a complex threading model with the "don't screw up" model C++ uses. The Rust compiler provides what amount to built-in unit tests with every build pass that allow you to fearlessly write code without data races. This in turn allows the new architecture you're referencing.

I don't think you need a complex threading model. The browser showed that you can get good interaction with single-threaded environment as long as you 1) can offload computation to other processes (web services, in the case of the browser, or more recently, workers) through message-passing and 2) such interaction can be performed asynchronously (i.e. while you wait for the result you can continue with the rest). I th…

I think the Stylo developments show that it's not entirely true. Yes, you can get good performance from single-threaded models, and you can get better performance with threading. I'm also a huge advocate of not rewriting things, which is why Rust's C interop allows for incremental re-development of legacy codebases in a reasonable way.

Re: Emacs with the SpiderMonkey garbage collector

#44

Post by rurban »

bitwize wrote: post #39
rurban wrote: post #30

Earlier quoted context omitted.

Not 5x as much ram. Exactly 2x more ram. You copy between two half spaces, back and forth. That's why it's usually also called semispace collector. What you are talking in the 2nd paragraph is total nonsense in a lisp world. Lisp solved this problem decades ago, with copying collectors. Stack values are 20%, plus refcounts do not work with rplac* able trees and are super slow.

Yes -- five times as much RAM: http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf As it turns out, compared to the analysis and tree traversal inherent in even a fast GC algorithm, the overhead of malloc() and free() is really quite small. So yes, it takes twice as much memory to use a copying GC, right out of the starting gate -- but in order to match the performance of the equivalent explicitly managed program,…

I think you misread the 5x, 3x and 2x sentences there. These are the workloads benchmarked there. The more memory used the faster was a slow GC compared to malloc, equally fast with 5x more memory used, and with 2x memory 70% slower.

Any GC uses much less memory than a refcount or malloc application. That's common sense. Just copying uses more vmem during the copying, compaction step, but even this size is usually less than the refcount and malloc overhead. The copying one even uses no stack-space, due to Cheney.

A GC is always superior to refcounts and manual malloc, because it's much too hard to do that by yourself. With real-time you use incremental collections. Just store the state where to continue.

Agreed, the conventional m&s, stop the world collectors as eg. used in most major fancy languages are all terrible. You only need that for an FFI. But a good GC is far superior. And most importantly faster and safe. You don't update refcounts with a GC. You don't pollute your cache and concurrent updates with that.

Look at Java or .NET if you don't like lisp. Same tech, a solved problem.

Re: Emacs with the SpiderMonkey garbage collector

#45

Post by rstuart4133 »

rurban wrote: post #44
bitwize wrote: post #39

Earlier quoted context omitted.

Yes -- five times as much RAM: http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf As it turns out, compared to the analysis and tree traversal inherent in even a fast GC algorithm, the overhead of malloc() and free() is really quite small. So yes, it takes twice as much memory to use a copying GC, right out of the starting gate -- but in order to match the performance of the equivalent explicitly managed program,…

I think you misread the 5x, 3x and 2x sentences there. These are the workloads benchmarked there. The more memory used the faster was a slow GC compared to malloc, equally fast with 5x more memory used, and with 2x memory 70% slower. Any GC uses much less memory than a refcount or malloc application. That's common sense. Just copying uses more vmem during the copying, compaction step, but even this size is usually le…

> Any GC uses much less memory than a refcount or malloc application.

That's plain wrong.

> because it's much too hard to do that by yourself.

Too hard to do yourself? There are some of us who have been doing it for decades. In places where performance, predictable runtime and memory usage is of paramount importance (like the linux kernel) it is still done manually. I'll grant you Moore's law has made those places increasing rare nowadays.

Yes it harder to do it manually, but only in the sense that it's harder to do anything manually than have it automated. But being hard and error prone doesn't mean the result is slower, or uses more memory. A moments thought should have told you that. GC delays freeing memory until there is sufficient memory pressure. The mental load imposed by tracking malloc's means a programmer does it immediately so he can forget about it. Thus the memory is available for re-use immediately.

In my experience a long running program manually managing it's heap has a heap about twice the size of actual space in use. In theory some degenerate cases caused by fragmentation can make it far worse - but I've never been bitten by it. Long running GC languages (they tend to be written in Java) it's around 5 times. Again, if you done any sort of server administration, you would know this. All of us who do have watched Java VM's grow over with amazement and dismay. Ironically, the cure is a form of manual memory management - kill them and restart.

Re: Emacs with the SpiderMonkey garbage collector

#46

Post by cies »

arcticbull wrote: post #43
mrighele wrote: post #37

Earlier quoted context omitted.

I don't think you need a complex threading model. The browser showed that you can get good interaction with single-threaded environment as long as you 1) can offload computation to other processes (web services, in the case of the browser, or more recently, workers) through message-passing and 2) such interaction can be performed asynchronously (i.e. while you wait for the result you can continue with the rest). I th…

I think the Stylo developments show that it's not entirely true. Yes, you can get good performance from single-threaded models, and you can get better performance with threading. I'm also a huge advocate of not rewriting things, which is why Rust's C interop allows for incremental re-development of legacy codebases in a reasonable way.

> you can get better performance with threading

Indeed. I think mrighele is talking about server side web app performance, which is a much higher level game and because a lot is stateless allows scale-out + loadbalancing to achieve resource utilization maximization.

When writing hi-perf systems (like a browser), this is a very different game. In this game threading is a tool you need to make sure all cores utilized.

Post reply on HN