4 ms·
> The ability to do speculative execution within failure contexts, meaning you can try out actions without committing them. When an expression succeeds, the eff
by vosper 4y ago
> The ability to do speculative execution within failure contexts, meaning you can try out actions without committing them. When an expression succeeds, the effects of the expression are committed, but if the expression fails, the effects of the expression are rolled back as though the expression never happened. This way, you can execute a series of actions that accumulate changes, but those actions will be undone if a failure occurs in the failure context.
That sounds quite neat
- alxmng 4y agoYeah, I’d like to know more about this. Sounds like transactions baked into the language. How does that square with performance? To implement transactions there has to be a copy of whatever state is manipulated by the transaction. That is potentially a huge amount of state that has to be copied.
- swiftcoder 4y agoThat or the compiler has to reorder side effects to occur after the decision point. Not sure how feasible that is in the general case, but should be a practical optimisation in many cases
- tommiegannert 4y agoThe general concept: https://en.wikipedia.org/wiki/Software_transactional_memory https://en.wikipedia.org/wiki/Software_transactional_memory
- alxmng 4y agoSTM suggests keeping at minimum the state of whatever operations are applied within a transaction (the transaction log). Allowing developers to create transactions with an unbounded number of operations sounds like a very bad idea, without knowing the details.
- 4ad 4y agoVerse is immutable by default. You have to opt-in explicitly into mutability.
- mrkeen 4y ago> That is potentially a huge amount of state that has to be copied. The less you mutate, the more you can reuse without copying.
- alxmng 4y agoRight. AFAIK most games are essentially a loop which applies transformations to a huge number of items in a very short amount of time. Games have a lot of state and work with large amounts of data. Any kind of transaction (locking or copying) sounds like it would be bad for games.
- 4ad 4y agoSTM doesn't use locking and copying is cheap in a functional language (which this is) because of structural sharing.
- epolanski 4y ago> sounds like it would be bad for games I really wonder whether people making claims that "something would be slow for games" actually bother benchmarking if that's true and how much. The fact that something might be faster theoretically isn't really relevant if the calculations stay on a very small scale.
- mfost 4y agoECS systems are gaining a lot of popularity for games and those are pretty similar to having some SQL database in your engine when you think about it. So it's actually not that surprising to see efficient snapshot/rollback/transaction features creeping in. I know for example that EnTT, a C++ ECS project has snapshots available to allow you to save the game state in the background without blocking gameplay as an example.
- Tuna-Fish 4y ago... they don't. Most games contain gigabytes of static data, a whole bunch of ephemeral data that is recreated and discarded every frame, and the actual mutable state that persists across frames is rarely more than a few hundred kB, unless you are making a huge open-world game (in which case it's still probably less than tens of megabytes.) This persistent data is what you use transactions on, and there are past experiments of doing things like fully double-buffering this state (Each frame, recreate the full state into a different buffer, with the code doing so only touching the previous frame, never reading from the current one. Great for multi-threading!)