@TimSweeneyEpic Read your old slides. Thinking about 100-core problem. Your thoughts on Rust for UE in ~5-20 years? http://www.iiswc.org/iiswc2008/sildes/keynote_1.pdf …
-
-
Replying to @nathanstocks
I'll need to dig into Rust and think about this.
1 reply 0 retweets 0 likes -
Replying to @TimSweeneyEpic
Maybe solves the hardest parts. Safe, lock-free shared memory via compile-time data ownership checks. Watching with interest
1 reply 0 retweets 0 likes -
Replying to @nathanstocks
Ok, I think message passing concurrency is too limited and manual for complex code, e.g. updating actors in a game engine.
2 replies 0 retweets 0 likes -
Replying to @TimSweeneyEpic
What if the message were the actor itself - no copying. Lock-free passing ownership of shared memory - powerful and fast
1 reply 0 retweets 0 likes -
Replying to @nathanstocks
The worst case is: a bunch of threads updating random sets of objects whose interdependencies aren't known a priori.
2 replies 0 retweets 0 likes -
Replying to @TimSweeneyEpic
Classic deadlock. I see the root of your desire for transactional memory.
1 reply 0 retweets 0 likes -
Replying to @nathanstocks
Cool. Most people judge it infeasibly costly, but I think that's an artifact of C++'s "everything is mutable by default".
1 reply 0 retweets 0 likes -
Replying to @TimSweeneyEpic @nathanstocks
Because of the overhead transactional memory adds, you really need a language design that's amenable to mostly const data.
2 replies 0 retweets 1 like
"Purely functional data structures" with copy-on-update are the future IMO due to concurrency concerns.
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.