throwawaymylife

I agree. With embedded "scripting" languages, you have to differentiate between two kinds of users that don't always (or even usually) overlap: the people writing the scripts (who may or may not even consider themselves to be programmers), and the engine programmers embedding the language in their game engine or other application. IMHO, the current homepage isn't really doing a great job of appealing to either group, and it'd be much more effective if it directly explained the advantages of its implementation to the engine dev crowd; that might alienate the script programmers a bit, but thinking about AAA game development, they're almost never the ones that get to pick the language anyway.

Squirrel is roughly similar (in the grand scheme of things) to Lua and JavaScript, with more of a (C++-style) OO flavor. Its main selling point is that it uses reference counting instead of a tracing garbage collector for automatic memory management. With a reference counted language, you pay a small but predictable cost every time something goes out of scope, whereas tracing garbage collectors coalesce all of these small costs into one big collection cycle run every few milliseconds. The tradeoff is that while garbage collected languages provide better throughput (due to cache effects, heap fragmentation, etc) for batch processing jobs, reference counted ones are much more suitable for realtime and soft realtime applications that would much rather take a constant factor hit to throughput if it eliminates the danger of a multi-millisecond GC scan causing the application to miss a deadline.

As such, Squirrel enjoys some popularity as (and was indeed created to serve as, by an engineer that had grown frustrated with the experience of embedding Lua in FarCry) a scripting language for video games, being most notably used in some of Valve's newer games, like Left 4 Dead 2, Portal 2, and CS:GO. The rest of the engine code usually dwarves the performance impact of "scripts" in most games, but GC scans can still cause games embedding other scripting languages to miss a frame presentation deadline, resulting in either a nasty tear or a completely missed frame. There are ways that tracing garbage collected languages can attempt to combat this (like incremental GCs), but some engine programmers have decided to accept the throughput cost for the peace of mind that reference counting provides.

EDIT: I had more but HN is silently ignoring some of my edits for some reason. Is there a post length restriction for new users, or have I tripped some kind of bizarre content filter?

Seems to be this (Quake 2, not 3, and still in development): https://www.youtube.com/watch?v=hDXSMgW-r5M&index=1&list=PLN...

I do think your logic holds for many combinations of users and infrequently-used applications. If your "brain loop" works like: press a button, then wait to see the result and completely mentally parse the screen before pressing anything else, then yes, there will be a few dozen frames after any action in which the program can safely run a garbage collector. This is the way we all operate when we first start using a new program. But then, for many users, once they've become familiar enough with that program, they no longer need to think about most of the screens, and can rely entirely on muscle memory to navigate.[1] At this point, any additional latency is certainly noticed. The best example would be typing; at least on HN, the vast majority of us can touch type, and any pauses between typing and characters appearing on screen (such as the incessant pauses I experience with Firefox and iOS Safari) are incredibly annoying. And since typing is an important part of almost any application, that basically necessitates a never-ending "continuous interaction," I don't think you can discount the importance of a highly interactive feedback loop for everyday programs.

I don't really see how you were discussing incremental GC in your original post, but yes, incremental GCs designed to scan their heaps in small bursts do exist and are common in embedded languages.

I wish that modern OSes and programming paradigms had better support for signals/"software interrupts", so that, even if I don't think garbage collecting everything is the right strategy for interactive applications, at least you could say "let me run my GC/other background task up until exactly the moment that the next frame starts," instead of having to manually parcel out work into tiny units while poling a timer.

[1] This is a big part of why I prefer "tacky" 90s Windows and UNIX UIs to modern animation-heavy ones. Once I've "learned" the program, I'm not even consciously looking at the UI, so the superfluous animations just force me to add delays of my own to my muscle memory, instead of letting me work as quickly as my muscles can move. Programmers tend to get this right for keyboard-driven interfaces, but they tend to underestimate our ability to use muscle memory for mouse and touch-driven interfaces.

"Neo 80s" has been a popular aesthetic for the past few years, so I wouldn't fault Microsoft too much for using bright neon colors.

Yes, this would be much better than the status quo, and hopefully technologies like "gsync" will bring something like it to us soon. But this approach will still result in microstutter from frames being displayed at somewhat random times, that may or may not be perceptible (I've never used such a display). Obviously a bit of microstutter is preferable to tearing or missing frames entirely under heavy loads, but really, a synchronous refresh rate would be ideal, if only our process schedulers were designed to give strict priority, more reliable vblank timing, and some degree of safety from preemption to the foreground UI process.

Three comments:

This approach can still cause perceptible latency if the user tries to input something while the GC you were trying to hide is ongoing.

For really intense graphical applications, like games, there is never a resting period where you can afford to spend a frame or more of time collecting garbage.

And for simpler graphical applications where you could perhaps get away with this, it's kind of pathetic that programmers today (or rather, their programming languages) even have trouble hitting 60 FPS on modern machines, when you look back at what people were able to accomplish in the past on hardware several orders of magnitude less powerful.