Live data from Hacker News

Erlang and First-Person Shooters (2011) [pdf]

erlang-factory.com

1–10 of 44 posts

Re: Erlang and First-Person Shooters (2011) [pdf]

#2
I saw this deck mid-2014, and it single-handedly made me want to learn Erlang. I felt that any system that can handle COD's load is, at the very least, worth checking out.

About a year later, I got a job doing Erlang full-time, and OTP is about as good as that slideshow indicated...So, if anyone at Demonware is reading this...Thank you! You introduced me to my second great love (after my wife)!

Re: Erlang and First-Person Shooters (2011) [pdf]

#5
post #3

Question for those of you who are game programmers. Is the message passing of erlang slower than shared memory threads in c++?

Not a game programmer, but do a lot of multithreaded work. There's about 100000 ways to pass messages in c++, for some c++ is faster (purely bounded by cache communication), some erlang is faster, and for some it's hard to compare (send latency, receive latency, throughput, can all vary greatly).

That only applies for two processes running on a single machine, Erlang can automatically distribute workers (I believe) and in that case it's probably more about networking hardware than language.

Re: Erlang and First-Person Shooters (2011) [pdf]

#6
post #3

Question for those of you who are game programmers. Is the message passing of erlang slower than shared memory threads in c++?

Message passing in Erlang will be a fair amount more expensive - Erlang and C++ have far, far more differences in terms of performance than just message passing vs shared memory.

You're better off comparing C++ and Pony. At that point, a message enqueue is 3 atomic instructions, not too bad. The benefit is trivial concurrency.

Re: Erlang and First-Person Shooters (2011) [pdf]

#7
post #3

Question for those of you who are game programmers. Is the message passing of erlang slower than shared memory threads in c++?

Depends. Erlang's scheduler is clever: if the receiver is asleep waiting on its inbox, sending to it will switch the running process to the receiver and back, all without hitting the scheduler logic. This is a great benefit for "thread" (in Erlang it's a process) pools, which are very very widely used in Erlang programs. It's really the best of both worlds: no Erlang context switch and it's completely transparent to one's codebase.

This isn't possible if the receiving process's inbox is non-empty or it's running. Then the cost should be around the same, assuming your C++ implementation is at the same level of quality as the Erlang VM.

Re: Erlang and First-Person Shooters (2011) [pdf]

#9
From a gamers perspective, the peer-to-peer lobby system used in the CoD series is one of the worst things about it.

I can remember constantly having to migrate hosts, getting owned by the host because everyone else has a ping much higher than zero, and horrible lag when the host it chose had a bad connection.

Cool technology, but at the cost of fun.

Re: Erlang and First-Person Shooters (2011) [pdf]

#10
post #9

From a gamers perspective, the peer-to-peer lobby system used in the CoD series is one of the worst things about it. I can remember constantly having to migrate hosts, getting owned by the host because everyone else has a ping much higher than zero, and horrible lag when the host it chose had a bad connection. Cool technology, but at the cost of fun.

yeah, I remember hearing that. I wouldn't necessarily consider that a sleight against Demonware though, considering that it's just a really hard problem to solve. Also I'm sure Activision pushed hard for it as it meant much reduced server costs.
Post reply on HN