This is up and running as a C++ library. Currently transactional variable reads and writes are ~50x slower than ordinary variables. 40% the overhead is transaction bookkeeping, 40% is concurrent garbage collection bookkeeping, 20% is platform atomics. Many optimizations to go.https://twitter.com/TimSweeneyEpic/status/1210260682605764611 …
-
-
I wanted to investigate a model where every entity could potentially be a separate thread, but you could only read the immutable previous frame’s data for other entities. Some challenges with complex interaction resolution.
-
If you do that, track reads and writes to each entity in the new frame updates, and rerun any updates that relied on state that was changed by a prior new-frame entity update, you have transactions via copy-on-write!
- 2 more replies
New conversation -
-
-
Wouldn't this lead to problems where order of operations is important? ie +health from pickup and -health from damage. Would the concurrent operations library ensure consistency, or just leave it indeterminate?
-
Transaction ensure that each gameplay object update is atomic, consistent, durable, and isolated. Transactions are just a way to have a lot of threads collaboratively contribute to outcomes that are indistinguishable from a single thread running each updates sequentially.
- 3 more replies
New conversation -
-
-
So in other words we need a special programming language just for games ;) perhaps a better ispc/CUDA without vendor lock-in that plays nice with a broader range of heterogeneous computing hardware
-
I believe
@Jonathan_Blow is doing exactly this with his JAI. Maybe Tim should speak to him? Just to avoid mistakes he might already have made?
End of conversation
New conversation -
-
-
We're in the middle of implementing a similar architecture for our in-prod sim game! The paradigm shift in coding style had a steep learning curve but the "free" multithreading by default is pretty god damn cool I must say.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Data-oriented vs object-oriented... I keep thinking "Why not both?" Think like a database. Have columns be packed arrays of component data. Each row is an entity. Most systems just ISPC down component data (ex: gravity). But allow *some* rows to be typed with tick() etc.
-
So you'd get data-oriented design, but the flexibility of selectively treating a handful of semi-unique rows as objects.
End of conversation
New conversation -
-
-
Wow. That’s a hell of an optimization pass. I mean, it should be algorithmic, assuming enough passes on usage case - but it would only take a few wrong use cases to drive performance to its knees in a multithreaded environment? Then again, DTOs can do the same in the wrong hands.
-
Today unintended atomics are way too expensive, therefore requiring significant sw mitigation to minimize. Known highly contended atomics=serialize code; known uncontended=parallelize. Big software cost/complexity trade off to try and deal with all the rest. We can fix this...
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.