4 ms·

Would any sort of actor model language have the raw throughput for a AAA game? I get how this model is nice for the web, for example, but I'm wondering why it

by syeaj 9y ago

Would any sort of actor model language have the raw throughput for a AAA game? I get how this model is nice for the web, for example, but I'm wondering why it doesn't get used for high performance computing (that I know of).

macintux 9y ago
The Erlang VM (BEAM) is unusual in that it, like the languages it hosts, is very opinionated. It is designed for robustness, scalability, concurrency, distributed environments. And immutable data. So far as I know, you literally cannot implement a language with mutability on the VM. So, raw performance will never be its thing. In general, I think the actor model could achieve high performance, but perhaps only if messaging is syntactic instead of truly distributed with mailboxes, network transparency, etc.
- mapcars 9y ago
  >So far as I know, you literally cannot implement a language with mutability on the VM. Elixir allows reassignment, of course, in the end, it uses different "Erlang" variables, but the language abstracts it.
  - macintux 9y ago
    Changing an alias isn't the kind of mutability that would allow high performance, though.
  - masklinn 9y ago
    That is not mutability.
    - erikpukinskis 9y ago
      It is though. A mutable state layer written on an immutable backend still has all the pitfalls of a native mutable data structure.
      - syeaj 9y ago
        Take the context into consideration: this whole thread is about performance and the comment on mutability was speaking of mutability in place, because that matters for performance.
      - masklinn 9y ago
        > It is though. No. That can trivially be inferred from SSA being a thing, mutable bindings can trivially and automatically be converted to immutable ones.
- mercer 9y ago
  I'm a beginner, so by all means correct me if I'm wrong, but as I understand BEAM is relatively good when it comes to 'soft realtime', and especially when 'latency' is a concern (in part due to per-process GC?). Am I correct in thinking that this would be pretty okay for most games, AAA or not? Would an FPS be possible (quick updates, small messages)? Or a World Of Warcraft or Sea of Thieves style game with many actors that need sort-of-realtime performance but don't rely on it entirely? I've been looking into creating a game, and I'm also learning Elixir, so I'm curious what would be realistic when combining both.
  - macintux 9y ago
    I'm afraid I don't know enough about game development to be of assistance. I assume in general they're very graphics intensive, which is (based on a 20+-year-old education I never finished) very matrix mathy, the type of calculations you absolutely would not want to shove through the Erlang VM. However, one architecture people have used to varying degrees of success is using Erlang as a control layer (messaging, resilience) and C/something else compute-heavy for data manipulation. Erlang has the ability to drive external binaries via NIFs or ports. Historically that's been a bit risky because the Erlang scheduler requires insight into its processes to do its job properly, but there have been improvements in recent releases. So...maybe? Probably a question better suited to the Erlang users mailing list.
  - jerf 9y ago
    In performance terms, Erlang is broadly speaking a scripting language, in the 10-20x slower than C range. It would be unusable for a AAA game because even using Erlang without any concurrency, it's too slow. It will get even slower if you do what you might be inclined to do for a game and make a separate process for every entity in the game and communicate entirely by message passing. It will be a beautifully clean architecture, but while Erlang may have cheap concurrency, it does not have free concurrency, and if you work realistic math on the sheer number of messages you'd have flying around the system it should become clear that it will not be practical to have literally manifested "messages" in that quantity being continuously created and destroyed. If we tune our sights down from "AAA game", there are two possibilities. One is you can create a less computationally-intensive game that can run Erlang on the desktop. I suspect you'll find you're a bit short of libraries for that use case, but with motivation you can pound through that. I'm not sure if this has ever been done. The other thing you can use Erlang for is being the backend server of a game system, and that is eminently practical, in the sense that it has been done: http://erlang.2086793.n4.nabble.com/Erlang-Who-uses-it-for-games-td2279186.html http://erlang.2086793.n4.nabble.com/Erlang-Who-uses-it-for-g... You'd encounter some bumps if you tried to scale it up, but that's not a very strong criticism since it's constant regardless of what tech you'd end up using.
- dragonwriter 9y ago
  > So far as I know, you literally cannot implement a language with mutability on the VM. You could do so, several different ways, e.g.: (1) use the process dictionary, (2) store data transparently to the new language’s user in ets (or, similarly, dets/mnesia), (3) use separate (again, hidden from the language user) Erlang processes for mutable cells. You can't get hig-performance mutability, but you can definitely implement a language with mutability on BEAM.
kqr 9y ago
As far as I know, Ada code using its types of actors (tasks and protected objects) can be made very fast, and more importantly for AAA games, very predictable. The default scheduling methods are good enough for many cases, but with the right restrictions, scheduling can even be statically determined and, in principle, a cyclic executive could be generated by the compiler with the same semantics as the original actor code. Unsure if this is actually done in practice, though.
chamakits 9y ago
For their AAA games cloud infrastructure it does! In fact, it is a backbone for some of Microsoft's Halo AAA game. Microsoft has this framework called Orleans which uses the Actor pattern. They have used it in various other project's too. Who is using Orleans: https://dotnet.github.io/orleans/Community/Who-Is-Using-Orleans.html https://dotnet.github.io/orleans/Community/Who-Is-Using-Orle... Video presentation on it: https://www.youtube.com/watch?v=7OVU9Mqqzgs https://www.youtube.com/watch?v=7OVU9Mqqzgs Now if you are wondering about raw throughput for graphics and physics stuff in AAA games, that I don't know. I believe that to be a completely different beast, with different requirements, which may or may not benefit from this paradigm.
zzzcpan 9y ago
There are languages, like Pony [1], that use actor model for the sort of high performance you are talking about. Also check out Anna paper, there is a description and argumentation on how and why they use actor model in C++ for high throughput. I would also say that performance wise actor model is usually better, than low level shared memory multithreading, because it enforces locality-friendly contention-free architecture and fundamentally maps better to modern hardware. [1] https://www.ponylang.org/ https://www.ponylang.org/ [2] http://db.cs.berkeley.edu/jmh/papers/anna_ieee18.pdf http://db.cs.berkeley.edu/jmh/papers/anna_ieee18.pdf
- syeaj 9y ago
  Thanks for addressing the latter point. I forgot to draw that distinction. That's a curious point, however, and I'll have to check that out more for myself as you suggest.
  - ddorian43 9y ago
    See seastar framework for c++
mastax 9y ago
NaughtyDog used a job system with fibers to parallelize their engine [1]. I suppose that's not exactly the same as an actor system since the fibers don't necessarily own all their state nor do they necessarily communicate using messages. [1]: https://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine https://www.gdcvault.com/play/1022186/Parallelizing-the-Naug...
jrs95 9y ago
Even in something like Go which has this kind of concurrency in mind, performance critical code is often written with the more traditional "threads & locks" approach with the goal of using the ideal number of goroutines to maximize hardware use but no more than that. Not saying that other concurrency models don't have the throughput for a AAA game, but when your goal is to get the most out of the hardware of one desktop/console you're going to have different priorities than a server environment.
Thaxll 9y ago
Performance would be terrible, Erlang is way too slow to do anything in a game client.
pjmlp 9y ago
Wooga uses Erlang on the server side.

by syeaj 9y ago

macintux 9y ago

The Erlang VM (BEAM) is unusual in that it, like the languages it hosts, is very opinionated. It is designed for robustness, scalability, concurrency, distributed environments. And immutable data. So far as I know, you literally cannot implement a language with mutability on the VM. So, raw performance will never be its thing. In general, I think the actor model could achieve high performance, but perhaps only if messaging is syntactic instead of truly distributed with mailboxes, network transparency, etc.

mapcars 9y ago
>So far as I know, you literally cannot implement a language with mutability on the VM. Elixir allows reassignment, of course, in the end, it uses different "Erlang" variables, but the language abstracts it.
- macintux 9y ago
  Changing an alias isn't the kind of mutability that would allow high performance, though.
- masklinn 9y ago
  That is not mutability.
  - erikpukinskis 9y ago
    It is though. A mutable state layer written on an immutable backend still has all the pitfalls of a native mutable data structure.
    - syeaj 9y ago
      Take the context into consideration: this whole thread is about performance and the comment on mutability was speaking of mutability in place, because that matters for performance.
    - masklinn 9y ago
      > It is though. No. That can trivially be inferred from SSA being a thing, mutable bindings can trivially and automatically be converted to immutable ones.
mercer 9y ago
I'm a beginner, so by all means correct me if I'm wrong, but as I understand BEAM is relatively good when it comes to 'soft realtime', and especially when 'latency' is a concern (in part due to per-process GC?). Am I correct in thinking that this would be pretty okay for most games, AAA or not? Would an FPS be possible (quick updates, small messages)? Or a World Of Warcraft or Sea of Thieves style game with many actors that need sort-of-realtime performance but don't rely on it entirely? I've been looking into creating a game, and I'm also learning Elixir, so I'm curious what would be realistic when combining both.
- macintux 9y ago
  I'm afraid I don't know enough about game development to be of assistance. I assume in general they're very graphics intensive, which is (based on a 20+-year-old education I never finished) very matrix mathy, the type of calculations you absolutely would not want to shove through the Erlang VM. However, one architecture people have used to varying degrees of success is using Erlang as a control layer (messaging, resilience) and C/something else compute-heavy for data manipulation. Erlang has the ability to drive external binaries via NIFs or ports. Historically that's been a bit risky because the Erlang scheduler requires insight into its processes to do its job properly, but there have been improvements in recent releases. So...maybe? Probably a question better suited to the Erlang users mailing list.
- jerf 9y ago
  In performance terms, Erlang is broadly speaking a scripting language, in the 10-20x slower than C range. It would be unusable for a AAA game because even using Erlang without any concurrency, it's too slow. It will get even slower if you do what you might be inclined to do for a game and make a separate process for every entity in the game and communicate entirely by message passing. It will be a beautifully clean architecture, but while Erlang may have cheap concurrency, it does not have free concurrency, and if you work realistic math on the sheer number of messages you'd have flying around the system it should become clear that it will not be practical to have literally manifested "messages" in that quantity being continuously created and destroyed. If we tune our sights down from "AAA game", there are two possibilities. One is you can create a less computationally-intensive game that can run Erlang on the desktop. I suspect you'll find you're a bit short of libraries for that use case, but with motivation you can pound through that. I'm not sure if this has ever been done. The other thing you can use Erlang for is being the backend server of a game system, and that is eminently practical, in the sense that it has been done: http://erlang.2086793.n4.nabble.com/Erlang-Who-uses-it-for-games-td2279186.html http://erlang.2086793.n4.nabble.com/Erlang-Who-uses-it-for-g... You'd encounter some bumps if you tried to scale it up, but that's not a very strong criticism since it's constant regardless of what tech you'd end up using.
dragonwriter 9y ago
> So far as I know, you literally cannot implement a language with mutability on the VM. You could do so, several different ways, e.g.: (1) use the process dictionary, (2) store data transparently to the new language’s user in ets (or, similarly, dets/mnesia), (3) use separate (again, hidden from the language user) Erlang processes for mutable cells. You can't get hig-performance mutability, but you can definitely implement a language with mutability on BEAM.

kqr 9y ago

As far as I know, Ada code using its types of actors (tasks and protected objects) can be made very fast, and more importantly for AAA games, very predictable. The default scheduling methods are good enough for many cases, but with the right restrictions, scheduling can even be statically determined and, in principle, a cyclic executive could be generated by the compiler with the same semantics as the original actor code. Unsure if this is actually done in practice, though.

chamakits 9y ago

For their AAA games cloud infrastructure it does! In fact, it is a backbone for some of Microsoft's Halo AAA game. Microsoft has this framework called Orleans which uses the Actor pattern. They have used it in various other project's too. Who is using Orleans: https://dotnet.github.io/orleans/Community/Who-Is-Using-Orleans.html https://dotnet.github.io/orleans/Community/Who-Is-Using-Orle... Video presentation on it: https://www.youtube.com/watch?v=7OVU9Mqqzgs https://www.youtube.com/watch?v=7OVU9Mqqzgs Now if you are wondering about raw throughput for graphics and physics stuff in AAA games, that I don't know. I believe that to be a completely different beast, with different requirements, which may or may not benefit from this paradigm.

zzzcpan 9y ago

There are languages, like Pony [1], that use actor model for the sort of high performance you are talking about. Also check out Anna paper, there is a description and argumentation on how and why they use actor model in C++ for high throughput. I would also say that performance wise actor model is usually better, than low level shared memory multithreading, because it enforces locality-friendly contention-free architecture and fundamentally maps better to modern hardware. [1] https://www.ponylang.org/ https://www.ponylang.org/ [2] http://db.cs.berkeley.edu/jmh/papers/anna_ieee18.pdf http://db.cs.berkeley.edu/jmh/papers/anna_ieee18.pdf

syeaj 9y ago
Thanks for addressing the latter point. I forgot to draw that distinction. That's a curious point, however, and I'll have to check that out more for myself as you suggest.
- ddorian43 9y ago
  See seastar framework for c++

mastax 9y ago

NaughtyDog used a job system with fibers to parallelize their engine [1]. I suppose that's not exactly the same as an actor system since the fibers don't necessarily own all their state nor do they necessarily communicate using messages. [1]: https://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine https://www.gdcvault.com/play/1022186/Parallelizing-the-Naug...

jrs95 9y ago

Even in something like Go which has this kind of concurrency in mind, performance critical code is often written with the more traditional "threads & locks" approach with the goal of using the ideal number of goroutines to maximize hardware use but no more than that. Not saying that other concurrency models don't have the throughput for a AAA game, but when your goal is to get the most out of the hardware of one desktop/console you're going to have different priorities than a server environment.

Thaxll 9y ago

Performance would be terrible, Erlang is way too slow to do anything in a game client.

pjmlp 9y ago

Wooga uses Erlang on the server side.