| |||||||||||||
PausesPausesPosted Jun 17, 2010 23:39 UTC (Thu) by ncm (subscriber, #165)In reply to: Pauses by nix Parent article: The Managed Runtime Initiative
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?
(Log in to post comments)
Pauses 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.
Pauses 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. :)
Pauses 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.
|
|||||||||||||