 Hello. OK. My name is Felipe. I'm from Brazil. And I'm talking about a performance evaluation of our lecture. So I'm a Q&A and a doctoral student of computer science at Brazil, a Federal University of Pernambuco. And my first question is, how many languages do you code and do you know? Raise your hand and who can know more than five languages, OK? More than 10 languages, OK? So by Wikipedia, we have 619 programming languages in the world. There's a lot of languages. There's a lot of languages. And why we have a lot of languages, OK? Why? Each language is a specific problem and have a specific future. But why so much language? OK, 619 is a lot of language. So we have a lot of applications. And the most popular language is Kino for everyone here, OK? You understand? Everybody here knows sometimes maybe three languages. And the three languages is common Kino for everything here, OK? Everybody here. So what's the problem? OK, now we have a problem with massively scalable, OK, high available, concurrence, and falterance, OK? But sometimes I go, it's very common when you try to make a login at Twitter, is do you see this while? OK, it's the past. But why is it common in the past? Because the first version of the Twitter is writing in Ruby Rails, OK? And before the big ban of the Twitter, all back end core is changed by True Scala. And Facebook too, OK, Facebook, and it created a new compiler for C++ and called hip hop and changed the chat to Erlang. It's because we receive a lot, a lot, many, many access. It's very easy to write some application for web and create games for web at the network, OK? Network, social network. But we have a lot of guidelines in the web to describe for us, for help us to write any application for web. But if this specific application receives a lot, 1 million, 1 billion access, what's the problem? Problem, you need to change all back end core for another language. Or another solution is, oh, sorry. Another solution is pay more, pay more to host, OK. But this is a real solution. So allocate more servers for your application as ensure that your application stands up every. No, OK. Because your application works well with distributed environments. And so what's the real problem? The real problem is the most languages we are not designed to withstand massive conclusions, OK? A language based in shared memory model do not support the necessary scalability. And functional languages such as Erlang and Haskell is very hard to use. So if you don't need, don't care, use Erlang or Haskell, what do you do? OK. Alexei has a friendly syntax. It's a good idea to productivity. Add concourse, object, language, distribute, fail to tolerance, OK. Make sure systems stand up despite the failure. Alexei can use Erlang libraries and call Erlang code. It's very compability, OK. So what this is the sample of history, OK. Created by Joseph Valin, thanks Valin. And I started the position 2012 in the Tyobi. And we have good books by David Thomas, Samza Jurek, Simon Davon, and Benjamin Mitten, OK. And now the first, the first Alexei Koff, OK. OK. What Alexei is very used to learn to understand such like a Ruby, OK. Massive passages, not use a share memory, has a partner matching, a metaprogramming via macros, less comprehensions. And what do you need, OK. We need, now, back-end system for B applications where massive conclusion is tolerance failure is a hiccad, OK. And how do we want, OK, clear code and productivity, OK. It's very common. You can see a lot of applications using rails or jungle. We have a lot of applications with Java and PHP. But this language is real, all available research of the machine. Because if you have an application, an application, and you run this application, Amazon or Heroku, OK. And when the big access, do you receive a big access? And what do you do? So you pay most of your hosts, OK. But these languages not use all available research of the machine. And what do you do? You pay most. Most, more, more, more to host, OK. And so how can we do it, OK, using a lecture? But a lecture is a real language that support massive concurrency and terere tarara, yeah. So I will show you the specific benchmark to prove that Alexi used all available research and used all available research and can use to receive massive access, OK. These are specific tasks to prove that. This test, the Intel MPI benchmark is to make sure the massive concurrency, OK, massive access, OK, just created by Intel, OK. And the main goal is to make sure the efficiency and the latency and tolerance, OK. And all this I will show you with a beautiful code. OK, let's start. This specific benchmark have three categories, three different categories, OK, single transfer, only exchange one message between two processes, OK. We have two processes for the single transfer. Parallel transfer, one message exchange of process, but several parts communicate in parallel. And collective transfer, OK. Measure and pre-collective operations. And we can see three, pink-pink, the red, pink-pong, and send and receive. We built a specific three tests to prove that, OK. I'm not to use any collective because we can see that many languages not support all the tests for those three tests and not need to use another test, OK. Pink-pink, this benchmark make sure the efficiency and the treatment of blocking, OK. What we can see that we have one process and create two process and the one process send to another process the message. We have X bytes, OK. Pink-pong is very similar to pink-pink, but the message is obstructive, but in common message. You can see the picture here, OK. The pink-pink test is asynchronous, OK. Message is passing between two process and pink-pong is synchronized message, passing between two process. So, and pink-pink, we create a two process and the first process send a message with X bytes size to the second process. And the first process waiting, OK. Because the second process responds with the same message and the pink-pong is a synchronized message, OK. The first process send a message with X bytes to second process and the second process send another message to process one, OK. And send receive, the try the ring send receive is the simple test to parallel transfer, OK. Many process is created and each one sends to ring and receive to the left-hand neighbor in the chain, OK. A two process will report the big direction of the system as obtained by optimization function, OK. We can see this picture to a loss, OK. Massive creation of process, many, many process and the process one send to the ring process and receive to the left, OK. So, but to make sure the performance we need compare Alexi with another language and I will show you that we have 619 languages and more, OK. And keep ground, keep increasing the number of the language. And we use most popular language, OK, by GitHub, Tyobi and Stack Overflow questions and Spectrum. The list of the languages used for the test is Erlang, Alexi, Java, Scala, Python, Ruby, and Erlang. I think that this is our only language that anybody here maybe don't know, OK, or Erlang. But I will talk a little bit, the sun. This environment, environment configuration, OK. We use the three computers to run all the tests without any ghee to interface, OK. This is a version about the many language that we use. OK, Erlang is extension, OK, is extension for object oriented. It's a very, very good to understand the code and the syntax is close to Java, OK, making it easier to adopt object oriented programmers. We can see more info in this home page and the GitHub. And all this code that I will use in this test, you can see in this repository at GitHub. OK, that's the code. This is us, the first test, Ping Ping, OK, we pass in the message size and the repetition. We created a process, two process, and send the first message to another process. And receive, and before we finalize the two process. OK, we collect that, we store all the time for creating the process and passing the message, OK, is the code to Ping Ping, they receive and finalize. So this part is to couple the bandwidth and generate the code in the time second, microsecond. And this part we use in all the tests, to Ping Ping, Ping Pong, and send receive. OK, the experiments, the experiment, we need run a lot of repetitions, OK, 500, 5,000, 10,000, 100,000, and 1 million, OK, and change the message size for 5 kilobytes, 10 kilobytes, 500, no, 5,000 kilobytes, 10,000, 5,100,000, and 100,000. OK, this is the result. We can see in the top, the results of the ruby in the top of 500,000 repetitions, OK, and the passing the 5,000 kilobytes, OK, Python, and the purple is a pink is color, the blue is Java. In the same line, one result, and the same line, under we can see Erlang, Orlang, and a lecture, OK, is the same line, OK, a message with 10,000 kilobytes, rub not support, OK, because ruby, Python, and the Java, and the Scala, too, all those languages use a thread, OK, and just these languages with this size of the message, ping, ping, with the message 15,000 kilobytes, and this line is a repetition, 5,000, 10,000, 15,000, 100,000, 500,000, and 1 million, OK, this is a repetition, OK. We keep increasing the size of the message, and OK, this is a less of ping-pong. This is a code for ping-pong, but the only difference between the ping-pong and ping-pong is the process one send to process, a message to process two, the process two send another message to process one, OK, it's not the same, it's a synchronous test, and we just need to finalize the one process, OK. The first test, ruby, in the top, Python is a yellow, pink, a proposed Scala, Java is a blue, and the same line, you want one under the unorder, is our lang, our lang and alexi, OK, for all repetitions, ping-pong with the message 10,000 kilobytes, rub not support, ping-pong with the message 15,000, the size, our repetitions, we can see the curve of Python is a better, that's Scala, but not Java, OK. We calculate the mean and variance and the standard deviation to plot this graph, OK, ping-pong with the message 10,000, 100,000, sorry. So this is a little difference between our lang and alexi, but it's the mean, OK. Basically, it's the same line, rub not support, OK. The send receive is different because we have a past the message size, we have a past repetition and the number of the process, because we created a lot process, OK, many, many process, to pass in the message. We generate the data, start the time, create the process, and we measure this time to create all the process and send the message. The second part, the ringer node is the chime between the message passing. This specific benchmark is to measure the performance to use the library MPI, OK, the message pass interface. So the last part of the code, and let's the we're passing the one argument or more, there's a process number, iterations, and message size. So the first test, the first result, Python and a rub not support this test, OK, and Java stopped your work after 10,000s, OK, 10,000 repetition. But Scala keep a work, and then the same line, Erlang, Alexchi, and Orlang. And we increase the message size and the number of the process, OK. So receive 100 process and the message size, 15 kilobytes. So receive, so receive, OK. We test and repeat all the tests, all the suite, the tests, we repeat 10 times, OK, the same line, Erlang and Scala, and Erlang, and Alexchi, and Orlang, the little difference, the performance, and keeping crazy, keeping crazy, OK, keeping crazy. So Scala not support this test anymore, Java, and Python, and Ruby, OK. Just Erlang, Orlang, and Alexchi. So, and the most communicative language goes to Erlang, Alexchi, and Orlang. It's a clear superiority of the Erlang over other languages. And Alexchi and Orlang inherits the Erlang performance, OK. So this is a good point to see that it's very similar to the results of Erlang and Alexchi. How much close is Erlang for Alexchi? So these three languages is limited only to the host machine, and they use all available resources of the machine, OK. This is good for us. The results, Scala, Java, and Python, and Ruby unable to run the test to completion, OK. And stop work after 10,000 process for Java. And do not use all available resources of the machine. But these specific tasks is only to make sure the communicative, OK, and massive communication between the process and the threads, OK. But not measure the granularity of the language. And a good idea, we test to the granularity. But this probe keep for the future tests, OK. And this home site, we can see more about the computer language benchmark game. And we have a lot of other tests, OK. And we can see in this page all the code for any many language, but not Alexchi, not yet. And then we are working in this repository now, OK. And all contributors for this work is here. File, Yosemite, Miliano, Francisco, Benjamin for the Alexchi code review, and Joseph Alim, too, OK. Is this? Thank you.