Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

erlang-factory.com

Post reply on HN
Print view View original

11–20 of 44 posts

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

#11

Post by hderms »

bobajeff wrote: post #3

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

Everything I've ever heard on that front is that Erlang should be considered a control layer which has any CPU-bound tasks run in C. Actors/message passing is a good synchronization primitive but there is apparently a whole host of issues with memory leaks regarding it in the "Erlang in Anger" e-book.

I personally lost interest in Erlang because of it only supporting actors as a concurrency mechanism. They're good for some things, and probably exceptionally good at what Erlang was designed for (Telecom systems), but I think they're just one tool in the toolbox. If the recommended solution for CPU-bound tasks is to start writing C, I have to wonder if there's a better way.

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

#13

Post by staticassertion »

hderms wrote: post #11
bobajeff wrote: post #3

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

Everything I've ever heard on that front is that Erlang should be considered a control layer which has any CPU-bound tasks run in C. Actors/message passing is a good synchronization primitive but there is apparently a whole host of issues with memory leaks regarding it in the "Erlang in Anger" e-book. I personally lost interest in Erlang because of it only supporting actors as a concurrency mechanism. They're good fo…

What concurrency patterns have you found yourself unable to express using actors?

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

#14

Post by qaq »

hderms wrote: post #11
bobajeff wrote: post #3

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

Everything I've ever heard on that front is that Erlang should be considered a control layer which has any CPU-bound tasks run in C. Actors/message passing is a good synchronization primitive but there is apparently a whole host of issues with memory leaks regarding it in the "Erlang in Anger" e-book. I personally lost interest in Erlang because of it only supporting actors as a concurrency mechanism. They're good fo…

Well short answer long term it's the only viable model you are not going to use locking and STW gc on 500+ core system with few TBs of RAM.

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

#17

Post by toast0 »

hderms wrote: post #11
bobajeff wrote: post #3

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

Everything I've ever heard on that front is that Erlang should be considered a control layer which has any CPU-bound tasks run in C. Actors/message passing is a good synchronization primitive but there is apparently a whole host of issues with memory leaks regarding it in the "Erlang in Anger" e-book. I personally lost interest in Erlang because of it only supporting actors as a concurrency mechanism. They're good fo…

Memory leak isn't quite the right word for what I think you're referring to: processes that most forward binaries without generating enough garbage on their own heap did not trigger garbage collection, leading to too much memory being used. This behavior is better in recent releases (otp 19), the space used by binaries is added to the per process accounting so that it can trigger garbage collection.

I agree, if you don't fit into the actor pattern, erlang is probably not a great choice, although the bit syntax is pretty nice, too. Sometimes you can leverage erlang for distribution and supervision and drive the c code; but sometimes it's just not a good fit.

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

#20

Post by chuckdries »

deevus wrote: 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.

Eh, I played CoD for a long time in middle and high school The community loved to complain about the whole lack of dedicated hosting thing but I rarely had bad experiences with it. Plus, CoD 4 and CoD WaW both had dedicated servers but are mentioned in this slide deck, so it sounds like they'd be using this middleware regardless.

At CoD scale I'm sure the ability to not rely on first party hosted servers saved enough money to justify the occasional service interruptions, and this system is better for groups of players that might be close to each other but far from an official data center.

Post reply on HN