User: Password:
Subscribe / Log in / New account



Posted Jun 17, 2010 13:54 UTC (Thu) by nix (subscriber, #2304)
In reply to: Pauses by ncm
Parent article: The Managed Runtime Initiative

The correct solution is to avoid programs that depend heavily on garbage collection.
Like GCC! And Emacs! And Eclipse! hm, not sure what I'll write my code in now. vi, Notepad and TECO are still in the running.

(Your point is more valid for interactive programs, but as Emacs indicates, a sufficiently compelling program can cause people to put up with amazing delays, When I was running Emacs and X on a 6Mb 486 I regularly had to put up with 45s GC delays. I did so without -- much -- complaint.)

(Log in to post comments)


Posted Jun 17, 2010 17:54 UTC (Thu) by dambacher (subscriber, #1710) [Link]

oh, emacs had this feature named "typing pause" nowerdays for some years now.-)


Posted Jun 20, 2010 20:19 UTC (Sun) by nix (subscriber, #2304) [Link]

typebreak.el is your friend :)


Posted Jun 17, 2010 23:39 UTC (Thu) by ncm (subscriber, #165) [Link]

You demonstrate the reach of ideology. What a normal person would treat as a crippling bug, you take without complaint because the editor is written in what you think is a cool language. But an awful lot of us do code in Vi, and have never suffered 45-second, or 2-second, pauses. Does the GC explain why Gcc has got so slow?


Posted Jun 19, 2010 21:33 UTC (Sat) by marcH (subscriber, #57642) [Link]

> ... because the editor is written in what you think is a cool language.

Please be serious: how emacs is made internally has nothing to do with why most people choose to use it. Most emacs users do not even know what LISP is (or even worse; they hate it as configuration file syntax), and they could not care less about a 2 seconds delay per week.


Posted Jun 20, 2010 21:05 UTC (Sun) by nix (subscriber, #2304) [Link]

Actually I *did* start using Emacs because of the runtime configurability and extensibility (and learnt Lisp as a result and fell in love with it), but I know I'm weird.

Its implementation language, of course, is partly ugly old Lisp and partly really rather nasty C (GCPRO, anyone?). The less that's in C and the more that's in Lisp, the better, as far as I'm concerned, but not because of the language -- more because, if it's in C, I can hack at it interactively, whenever I need to. :)


Posted Jun 20, 2010 20:23 UTC (Sun) by nix (subscriber, #2304) [Link]

Does the GC explain why Gcc has got so slow?
Very possibly it does. When Apple was still contributing (back in the 4.0 days) someone (I think it was Mike Stump) ran shark over it, and saw a horrifying rate of L2 cache misses, something like one every twenty instructions if I recall. It appears that the GC's largest cost is not when it runs at all, but what it does to the program's locality of reference: scatters it all over the place, leading to absolutely pessimal cache behaviour.

GCC has been carefully migrating selected speed-critical things back into obstacks ever since: they may be really annoying (freeing must be in reverse order of allocation), but they are contiguous, and that's sometimes a major benefit.

(And, y'know, I did think that the 45-second pauses were a crippling bug, but then most other things on my system also had huge pauses at the time: 6Mb RAM in 1998 was not pleasant. The real problem was that my system was hugely under-RAMmed.)

With the smallest machine I regularly work on now having 12Gb RAM, it's amazing how little I can force myself to care about swap-induced problems and OOM. At least, for the next couple of years, until KDE4.9 or GNOME 3.5 bloats up and uses it all up again.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds