Live data from Hacker News

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

erlang-factory.com

21–30 of 44 posts

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

#21
post #3

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

I'm not a game programmer, but I've got plenty of experience with parallel programming.

The answer is that either message passing or shared memory can be slower or faster. The architecture of your program probably matters more, though obviously some problems lend themselves more to a shared memory solution and some more to a message passing approach (and many benefit from hybrid solutions).

The main cost factor for message passing approaches is communication overhead. The main cost factors for shared memory are contention and fighting the memory hierarchy (keep in mind that even with shared memory, inter-thread communication will generally have to move data through the expensive parts of the memory hierarchy). Your goal in either case will be to architect your solution to minimize the overhead that you are dealing with.

Also, you're starting to hit physics issues once you want to do shared memory past maybe 16 cores or so. Thermal issues, obviously, but also memory bandwidth and such. And the solutions to these can have an economic impact where choosing a more distributed approach can simply be cheaper. When you're dealing with thousands of concurrent processes (as some Erlang applications do), then a pure shared memory solution is usually right out (though various hybrid approaches can still have advantages over a pure message passing system).

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

#22
post #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)!

How did you get into erlang, like in project wise?

Because I played around with rabbitmq plugins, a nehe opengl examples port and some erlang notepad someone implemented. I also own both o'reilly hard copies.

But other then that I don't really have a project I can see myself use erlang for(one man shop).

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

#23
post #15

Keep in mind that those are online services and can be developed in every languages since it's not hard real time ( aka C++ gameservers ). Most online services for the video game industry are actually made in Java.

Game servers don't do hard real time. That would be overkill, and requires specialized operating systems typically used for niche applications like robotics; e.g. https://en.m.wikipedia.org/wiki/RTLinux

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

#24
post #8

I wonder if they have considered moving to elixir since some of the problems they have highlighted are resolved in elixir. That would be easier for new employees and they could still keep their Erlang code base until they make the full switch.

I'm wondering the same :)...

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

#25
post #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)!

How did you get into erlang, like in project wise? Because I played around with rabbitmq plugins, a nehe opengl examples port and some erlang notepad someone implemented. I also own both o'reilly hard copies. But other then that I don't really have a project I can see myself use erlang for(one man shop).

The Cowboy webserver is fairly easy to get started with and I really recommend checking it out, since a web server feels like a "very Erlang problem" to me.

To answer your question though, I got started by playing with TCP and building a basic chat server. I spawned a new Erlang process for each user, used Erlang's internal messaging to share messages between processes, and then passed those messages along to TCP to the user.

A basic rule of thumb on whether or not it's a good Erlang problem is seeing if you can visualize the problem in terms of a bunch of tiny, self contained things (like cells), and you don't want one of those cells failing to have any risk of breaking anything else.

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

#26
post #25

Earlier quoted context omitted.

How did you get into erlang, like in project wise? Because I played around with rabbitmq plugins, a nehe opengl examples port and some erlang notepad someone implemented. I also own both o'reilly hard copies. But other then that I don't really have a project I can see myself use erlang for(one man shop).

The Cowboy webserver is fairly easy to get started with and I really recommend checking it out, since a web server feels like a "very Erlang problem" to me. To answer your question though, I got started by playing with TCP and building a basic chat server. I spawned a new Erlang process for each user, used Erlang's internal messaging to share messages between processes, and then passed those messages along to TCP to…

If you could share that code it will help a lot of people to see the power of Erlang as perceived by a novice coder in the language.

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

#27
post #25

Earlier quoted context omitted.

How did you get into erlang, like in project wise? Because I played around with rabbitmq plugins, a nehe opengl examples port and some erlang notepad someone implemented. I also own both o'reilly hard copies. But other then that I don't really have a project I can see myself use erlang for(one man shop).

The Cowboy webserver is fairly easy to get started with and I really recommend checking it out, since a web server feels like a "very Erlang problem" to me. To answer your question though, I got started by playing with TCP and building a basic chat server. I spawned a new Erlang process for each user, used Erlang's internal messaging to share messages between processes, and then passed those messages along to TCP to…

And it turns out a lot of problems actually fit that if you try to think about them that way. Sometimes it's worth -trying- to change your visualization; you'll find it works out better.

We had to write task scheduling software where I worked, and someone unfamiliar with Erlang said something to the effect of "Oh, that's easy, priority queue". Well, no; there are all -sorts- of sharp edges to doing that. Instead we just had one Erlang process per task, with timers (slight gotcha in that you shouldn't use the timer module, instead erlang:send_after). So every scheduled task in the next (time period) was a sleeping Erlang process (and was listening for updates, or for the timer message; on the timer message it would go and actually start executing). Super easy to test, reason about, debug, etc (because the correctness of the task execution was largely isolated from the correctness of the task scheduling) and a far better solution than what the non-Erlang mindset would naturally reach for (since in most languages, more concurrency = bad).

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

#28
post #23
post #15

Keep in mind that those are online services and can be developed in every languages since it's not hard real time ( aka C++ gameservers ). Most online services for the video game industry are actually made in Java.

Game servers don't do hard real time. That would be overkill, and requires specialized operating systems typically used for niche applications like robotics; e.g. https://en.m.wikipedia.org/wiki/RTLinux

I've been reading up on VR after trying an Oculus Rift. It sounds as if VR game servers will need something a bit closer to "hard" real time than current servers. I suppose it still wouldn't technically be "hard real time" but much "firmer real time". I guess this leaves me wondering if games will ever progress to needing "hard" real time.

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

#29
post #25

Earlier quoted context omitted.

The Cowboy webserver is fairly easy to get started with and I really recommend checking it out, since a web server feels like a "very Erlang problem" to me. To answer your question though, I got started by playing with TCP and building a basic chat server. I spawned a new Erlang process for each user, used Erlang's internal messaging to share messages between processes, and then passed those messages along to TCP to…

If you could share that code it will help a lot of people to see the power of Erlang as perceived by a novice coder in the language.

I sadly do not have access to that code anymore. I wrote a basic MVC framework using the aforementioned Cowboy server early last year though: https://github.com/Tombert/Frameworkey-Erlang

... Keep in mind I've gotten a lot better since I wrote this!

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

#30
post #23

Earlier quoted context omitted.

Game servers don't do hard real time. That would be overkill, and requires specialized operating systems typically used for niche applications like robotics; e.g. https://en.m.wikipedia.org/wiki/RTLinux

I've been reading up on VR after trying an Oculus Rift. It sounds as if VR game servers will need something a bit closer to "hard" real time than current servers. I suppose it still wouldn't technically be "hard real time" but much "firmer real time". I guess this leaves me wondering if games will ever progress to needing "hard" real time.

That doesn't make much sense, think about lag, playing with somebody who is far enough that the speed of light makes a difference. You want a near real time graphics pipeline for each user to avoid vomiting, but other than that you will still get terrible terrible network problems one way or another which you can't control and will show up as ghosts in the game, stopped players, etc.
Post reply on HN