I’m a through-and-through erlang devotee, but I’m not sympathetic to the argument that performance doesn’t matter. It matters a lot; there’s a bunch of hard/interesting problems that you’d prefer to fit on one box or within one programming paradigm, and erlang (and ruby, and python, and clojure, and …) frequently makes that impossible. The fact that erlang has a good multi-box story and an acceptable multi-paradigm story doesn’t really help the fact that multi-box and multi-paradigm are both incredibly holistically costly.
Agreed. This antipathy for speed is also a very odd idol in the realm of programming.
But I think there’s a bigger issue at play here, a tunnel vision of sorts. There’s three general problem domains when it comes to performance:
Hard real-time (a process absolutely must finish in time, or else it’s in a failed state)
Soft real-time (a process should finish in time the vast majority of the time. Occasional lapses are not an issue)
Not real-time (“offline” processing, more or less)
These posts are all super focused on the problem domain that Erlang excels at, which is soft real-time, but there are plenty of problems in this world that doesn’t fall into soft real-time problems! Hard real-time applications (like video games) are on one end of the interactive spectrum. It must respond at least 30 frames a second, or else it’s essentially game over for the player. Jank-tastic!
And then on the way other side, are offline processes that cares about over all throughput, but not immediate responsiveness (e.g. protein folding).
On both end of the spectrum, speed matters. There happens to be a niche in the middle where reactive/responsiveness happens to matter a lot more than pure throughput, but let’s not mistake the tree for the forest!
I think videogames fall differently into hard or soft real-time categories depending on genre.
A fighting game like Soul Caliber or Street Fighter is hard real-time, because the entire game is considered worthless and customers will pay no money for it if there’s even a rumour that it might occasionally drop a frame.
A game like Skyrim or Mass Effect is definitely soft real-time. They have to give smooth framerates most of the time because in-game combat is real-time-ish. However, these kinds of games can ship with noticeable intermittent (but not frequent) framerate hitches and people will still pay for them. For example, when new areas and scripts get paged in as the player traverses the world, or when a bunch of complicated in-engine scripting kicks in all in one go for some reason.
A game like XCOM or Civilisation is pretty much best-effort. It can skip frames all over the place without breaking gameplay. It’ll feel irksome if animations are constantly choppy. Players can even opt to disable (some|most) animations in these games, and many will.
…I think FPS games fall into the hard real time category for players who pay close attention to how well they do in competitive matches but the soft real time category for players who don’t. ?
It’s absolutely okay to run an FPS slower than 30 Hz, provided you do so at a constant slow rate (so players can model it in their heads without getting annoyed). Also, note that the game logic is different from the rendering logic–the Quake series ran the actual game logic at between 5 and 20 Hz depending on the game iirc, however fast the rendering itself was happening.
For a single-player (or PvE) FPS, sure. For a multi-player (PvP) FPS, less so. Aiming with 60Hz rendering is qualitatively easier than aiming with 30Hz rendering, even if rock solid.
A game like XCOM or Civilisation is pretty much best-effort. It can skip frames all over the place without breaking gameplay. It’ll feel irksome if animations are constantly choppy. Players can even opt to disable (some|most) animations in these games, and many will.
An interesting middle-ground being RTS. They can run at slow rates, but the interface must stay responsive. I used to play CoH competitively on a box that was always between 10 and 20 frames, with occasional drops and Relic has really handled that well.
Computers were painfully slow (and expensive) for most of their existence. I remember solving matrix equations in EE course on a Z80 based computer. Turing sure wasn’t around for a while then, but the calculations were taking many minutes even for relatively simple circuits.
It’s only recently HW performance began to feel plentiful for most tasks, but I wonder for how long.
I’m a through-and-through erlang devotee, but I’m not sympathetic to the argument that performance doesn’t matter. It matters a lot; there’s a bunch of hard/interesting problems that you’d prefer to fit on one box or within one programming paradigm, and erlang (and ruby, and python, and clojure, and …) frequently makes that impossible. The fact that erlang has a good multi-box story and an acceptable multi-paradigm story doesn’t really help the fact that multi-box and multi-paradigm are both incredibly holistically costly.
Agreed. This antipathy for speed is also a very odd idol in the realm of programming.
But I think there’s a bigger issue at play here, a tunnel vision of sorts. There’s three general problem domains when it comes to performance:
These posts are all super focused on the problem domain that Erlang excels at, which is soft real-time, but there are plenty of problems in this world that doesn’t fall into soft real-time problems! Hard real-time applications (like video games) are on one end of the interactive spectrum. It must respond at least 30 frames a second, or else it’s essentially game over for the player. Jank-tastic!
And then on the way other side, are offline processes that cares about over all throughput, but not immediate responsiveness (e.g. protein folding).
On both end of the spectrum, speed matters. There happens to be a niche in the middle where reactive/responsiveness happens to matter a lot more than pure throughput, but let’s not mistake the tree for the forest!
I think videogames fall differently into hard or soft real-time categories depending on genre.
A fighting game like Soul Caliber or Street Fighter is hard real-time, because the entire game is considered worthless and customers will pay no money for it if there’s even a rumour that it might occasionally drop a frame.
A game like Skyrim or Mass Effect is definitely soft real-time. They have to give smooth framerates most of the time because in-game combat is real-time-ish. However, these kinds of games can ship with noticeable intermittent (but not frequent) framerate hitches and people will still pay for them. For example, when new areas and scripts get paged in as the player traverses the world, or when a bunch of complicated in-engine scripting kicks in all in one go for some reason.
A game like XCOM or Civilisation is pretty much best-effort. It can skip frames all over the place without breaking gameplay. It’ll feel irksome if animations are constantly choppy. Players can even opt to disable (some|most) animations in these games, and many will.
…I think FPS games fall into the hard real time category for players who pay close attention to how well they do in competitive matches but the soft real time category for players who don’t. ?
It’s absolutely okay to run an FPS slower than 30 Hz, provided you do so at a constant slow rate (so players can model it in their heads without getting annoyed). Also, note that the game logic is different from the rendering logic–the Quake series ran the actual game logic at between 5 and 20 Hz depending on the game iirc, however fast the rendering itself was happening.
Isn’t quake actually the poster child for FPS dependent logic because you could jump higher with more FPS due to rounding?
Oh yes. Apparently you jump higher at 125fps than you do at 90fps in Quake 3 (and its predecessors).
For a single-player (or PvE) FPS, sure. For a multi-player (PvP) FPS, less so. Aiming with 60Hz rendering is qualitatively easier than aiming with 30Hz rendering, even if rock solid.
An interesting middle-ground being RTS. They can run at slow rates, but the interface must stay responsive. I used to play CoH competitively on a box that was always between 10 and 20 frames, with occasional drops and Relic has really handled that well.
Well said!
It’s quite astonishing what a single box can do these days - rare indeed is the dataset that can’t fit into RAM.
Computers were painfully slow (and expensive) for most of their existence. I remember solving matrix equations in EE course on a Z80 based computer. Turing sure wasn’t around for a while then, but the calculations were taking many minutes even for relatively simple circuits.
It’s only recently HW performance began to feel plentiful for most tasks, but I wonder for how long.