Concurrency vs. Parallelism 2.0 - RubyDay 2013

Version of this talk for the Ruby audience at RubyDay 2013.

Transcript

1. Concurrency vs Parallelism The purpose of this talk is to give you a good overview of what concurrency and parallelism are, and what tools you should use to achieve both in ruby.
2. Task #1 Task #2 Day 1 Day 2 Let’s say you work as a programmer for a company. On Monday, you’re given two different tasks and they must be completed in two days. You can finish the first task on the first day and you can finish the second task on the second day.
3. Task #1 Task #2 Task #2 Task #1 Day 1 Day 2 Or you can break the tasks in halves and alternate between them. Both of them will be finished at the end of the two days
4. Task #1 Task #2 Task #2 Task #1 Day 1 - You Day 1 - Her Or your boss hires another programmer, and you can alternate between the two tasks when she is doing the same. You will get both tasks done by the end of the first day.
5. Task #1 Task #2 Day 1 Day 2 Sequential The first way of working is sequential. You work on the first task and when it’s done you work on the second one.
6. Task #1 Task #2 Task #2 Task #1 Day 1 Day 2 Concurrent The second way of doing things is concurrent. You’ve split the tasks in halves and alternate between the two, anyway you want it. This way, there isn’t much gain when talking about time, but this brings us to the third way....
7. Task #1 Task #2 Task #2 Task #1 Day 1 - You Day 1 - Her Parallel The third way of doing is the real deal. Because you’ve split a bigger task in indipendent pieces, bringing another programmer in will actually make things faster, getting the two tasks done by the end of day 1. This is a classic example and also an oversemplification of the problem, but it’s just for the sake of explaining it.
8. Concurrency is the composition of indipendently running things So concurrency is actually the composition of indipendent pieces of work to be done, or in the programming domain, it is the composition of indipendently running things
9. Parallelism is doing multiple things at once
10. Concurrency is not Parallelism
11. Concurrency enables Parallelism Once you structure your work with concurrency in mind, parallelism enters easily into the picture.
12. Parallelism is a feature It may be present or it may not. It depends on the environment and you just cannot control it, you cannot account for it when making decisions.
13. The basis of concurrency: Threads Now, we obviously need some tools, or primitives, to enable concurrency in our code. The oldest and more common primitives are threads. A thread wraps a unit of concurrent code.
14. Thread.new do # ... end As simple as this. As soon as you create a thread, it starts running. You can wait for it by joining it, or if you don’t your main thread
15. Say goodbye to determinism You’re not in control of the way the system composes your threads, you cannot know the order in which they are executed. In addition, your thread can get interrupted at any time to let other threads grab a share of the CPU. If you previously had one path of execution, now you have a freaking lot.
16. Thread-safety issues Threads share all the memory of a running program. This leads to a large family of problems. Multiple threads may want to access and change shared memory. This is bad. Your program will not crash, but your data will be wrong. You have to handle synchronization between threads so this stuff will not happen.
17. @mutex = Mutex.new data = [] Thread.new do @mutex.synchronize do data.push(something) end end
18. Looks hard? It freaking is. I’m not sure about you, but to me this feels freaking hard. Not only do I have to think about getting the Task done, I even have to handle all the coordination between threads and their synchronization, otherwise the whole thing will explode right in my face. This is exactly why so many people give up threads. They not only give up, they even build enormous runtimes where everything is run a single thread, so they don’t even have to think about it.
19. A better abstraction for concurrency: Actors Of course, this stuff has been dealt with a long time ago, nothing new was invented yesterday. Let me show you how actors work.
20. Kevin Spacey Msg #1 Msg #2 ... This is an actor. Every actor is an indipendent piece of execution. Everyone has a mailbox, in which incoming messages are stored.
21. Kevin Spacey Msg #1 Msg #2 ... Kate Mara Msg #1 Msg #2 ... Yes because actors talk to other actors using messages. In each actor there is a loop which consumes these messages and do the work. Messages are either synchronous or asynchronous, meaning that when sending synch messages the actor will be blocked until it receives an answer, asynch messages instead are like fire and forget, the actor sends them and goes on with its work.
22. Immutable copies of data
23. Welcome to the Real World
25. MRI Matz’s Ruby Implementation
26. The infamous GIL
27. The GIL does not prevent concurrency
28. The GIL prevents parallel code execution
29. The GIL does not prevent parallel I/O
30. The GIL does not guarantee thread-safety
31. How to achieve parallelism with Ruby?
32. MRI Code + I/O
33. JRuby & Rubinius Code + I/O
34. Recap!
35. You can’t have parallelism without concurrency
36. Threads are a poor abstraction
37. You can get fantastic results when building upon the right abstractions
38. Epilogue I really love Ruby, it is a fantastic tool with a fantastic community around it, maybe the best community. It would pain me if in 5 to 10 years I'd be forced to move away because it could not keep up. Fortunately people before me realized the exact same thing. So they've put and are putting a tremendous effort in building alternative runtimes with parallelism in mind from the first day of development. JRuby is very mature at the moment, but as it has been built on the JVM, its support for native gems (gems written in C or C++) is non existent. On the other hand Rubinius is still a work in progress. It is ready and is being used in production, but does not work 100% with Rails. The effort and contributions toward these two project are an investment in the future of Ruby so that in 5, 10, maybe even 20 years we could still be using our favourite language for getting the Task done.
39. Q&A!!!
40. @razielgn fred@ravas.io THANK YOU!