 So, I'm going to present, to give you basically what is five landing talks end-to-end, because I'm going to present you what is new in PyPy, what's new mostly from last year, and a lot of small things are new, small in quotes. So what is PyPy first? PyPy is an other implementation of Python, I guess you kind of know that if you are here in my talk, it's mostly a dropping replacement, which means, well, you have this project that you see Python, you start with Python, you can start with PyPy, and it should work the same way. So so far, PyPy supports Python, the language version 2.7, now, like, in these few months, it's about to support Python 3.5, the language, and, well, the advantage, why would you use PyPy instead of PyPy, the most common reason is just performance, there are a lot of programs that are just much faster on PyPy. Okay, so first, let's talk about PyPy 3.5. So it's Python 3.5 support, which is released in, well, Beta was the name I wanted to say, I was told that maybe I should use another name, so I'm using Gama instead. So why is Beta not a good name? Because it works, because it's very stable, it's very fast and everything, but it could be wrong in a few details everywhere, which means it's probably missing some functions in the socket module, this new socket method there is not implemented, or this new extra keyword argument of that function over here is not implemented, it's this kind of thing that is not done yet, but it is there, and it works, and it's fast. So the current status is please try it and report issues if you're actually finding this kind of missing functionalities, because it's not, like, just by running the cbath test suite, we find most of the missing functions, but not all of them. So a special thank you goes to Mozilla, because Mozilla has actually been giving us a big grant, like, four people one year to do this work of Python 3.5, and this is just a set of benchmarks, running on Python 3.5, this is just benchmarks for the new keywords async and await on 3.5, which basically shows that it's fast, so the red lines are speed in requests per second on PyPy, and the blue lines are on Python, it's async, sorry, A, E, O, HTTP, G, event, turn on the web, curio, and H11, and on the red twisted incline. So it's fast, cool. I should mention for completeness that this doesn't, I mean, if you are writing an async HTTP, and you are writing it for performance on cbath, then you would probably not use any of these, but instead use things like libuv, which is pretty fast on cbath, but which is not included here, because it's all c, basically. These plots are more about performance of pure Python code. Okay, so the status, it's roughly complete, so complete 3.5 support plus the f strings, which is a new feature in 3.6, which we also added into 3.5, because why not, and because people tend to like this feature. Okay, it has good performance. It is tested mostly on Linux only so far, which means that some windows or OSX specific interface are probably missing. The first final version, I mean, the first version that will not be code beta or Ghana or whatever will be released, like, soon. And, well, once we get there, the confidence that will continue and progress to Python 3.6 and probably 3.7 next year, et cetera. Okay, so this was my first lightning talk. The second one is about scientific stack. So if you are using the scientific stack, you are using, well, first NumPy. So the news from last year, well, first, it's that, well, there are two different kind of modules that you can use inside PyPy. One is NumPy, that's the standard version of NumPy that you download with the installed NumPy. And there is another one called NumPyPy, which is a built-in module of on PyPy, which is not complete. So what we did is basically this. NumPyPy is deprecated, don't use this anymore, instead just use the standard NumPy. So what we did is to support enough of the C layer, the C-Py layer in order to be able to run NumPy. So the end result is that NumPy really works. I mean, it's here, it puts 99.9% because there are two failing tests out of the thousands and thousands and there are bad luck strings or something. So another interesting bit is that it works on PyPy, the standard PyPy that implements Python 2, but also on top of the PyPy that implements Python 3, 3.5 in this case. Okay, and well, from these points, you can actually build on top of it and things mostly work, as in you can run a Jupyter, Markiplier, pandas, et cetera, and all this package mostly works in PyPy. So here is an example that is not at all impressive, but so it's a standard Jupyter notebook and I can run this and I get a Markplotlib to print me, oops, sorry, I got Markplotlib to print me this nice graph. So, well, the only thing here is that it happens to be running inside PyPy 2.7. It would work just as well inside PyPy 3.5, so it works. Okay, so what I said about the C path and C extension is more generally if you, all siphon modules work or more generally any C path and C extension module mostly works nowadays out of the box on PyPy. So this is all thanks to CpyX which is our own C path and C API re-implementation or emulation. So, well, yes, it's an emulation which means that it is bit slow. So it means it is slower to run all this NumPy and the complete scientific stack. If you run this and compare the performance with the performance that you would get on top of C path, you will find that PyPy is slower. So, less so than up to last year, but still slower. Well, there are work rounds. So, I mean, what is slow is really the boundary between PyPy and C. So, for instance, if you are doing a lot, if in your program you happen to be doing quite a lot of re-indexing, it's slow because everything that re-indexing is going to cross this boundary. On the other hand, if what you are using NumPy 4 is computing the eigenvectors of one huge matrix, then it's a complex lengthy process which is just as fast because you cross the path and C boundary exactly once. So far, there is this speed hack here that, well, don't use it basically, but it's very good right now. You take your NDRA, you consider it as a buffer, you get a CFFI pointer to this address in memory, you cast it to a double star which means an array of doubles, and you get P which is a pointer to the first and all items in the array. So, once you have this P, you can do P bracket 0, P bracket 1, etc. Index it. Just by doing that, you are replacing this where every single time you write this, you get a very slow process that needs to go through layers and layers. If you replace it with P bracket index, then it is jittered into one machine instruction. So it's great for speed. So, well, obviously what we are going to do in the future, in the near future probably, is actually add a few special cases so that this NDRA index becomes as fast as that hack. Okay, so we have planned to improve. Some funding would be welcome. And yes, for now, just try it out on your own code and see if it helps. Basically, if you have anything that just use NumPy and does nothing else, then no, it's not going to be faster on PyPy. It's probably going to be slower, yes. But if you have some bigger programs that really has part that are really doing logic in Python as well, then the complete speed of your complete program might get faster by running Python and PyPy. Okay. So now, a completely unrelated topic, software transactional memory. This is a topic that I kind of talked about the past few years. PyPy STM, software transactional memory. It would be a way to get rid of the global inter-petalog. And I've been asked about ten times during this week, what is the status? So, here is the answer. Sorry, it does not seem to work. Why doesn't it not seem to work? Well, the basic idea that you would take, I mean, the idea that a thought might work is that you take your program, a big and complicated program that does tons of things. At one point, it has a loop. A loop that does something on every element of some collection. But every single thing it does is mostly independent. So, by adding, like, you would add a hint or something. And then the process would turn the execution of this mostly independent part to be really running parallel. And then you have a conflict detection system to figure out which of these things are running parallel actually gave the correct answer. The correct answer, meaning gave the same answer as they would have given if they were not running parallel. So, it's a very nice idea. However, in practice, you get conflicts between the threads and the conflicts are hard to find. So, it means that you are going to spend two hours using some tools that I don't even know what they are and they need to be invented. Only to find one conflict. And then, yes, it's obvious it's this thing that conflicts with that thing. So, you fix that, try again, poof, exactly the same bad performance as before. So, repeat the process. So, you need to repeat the process several times. You have no clue how many times. And then, at the end, suddenly, you get good performance. Yes, cool. It works. Well, and then the main problem is that it is your program, like the program is not chosen, right? The next time you change anything in your program, poof, you're going to reintroduce some conflict and you're back to square one. And yes. So, so, so, I think this is enough of an issue to kind of kill the idea. It's like you cannot test for the results unless you do some kind of complex test that the execution runs in less than 30 seconds. And then you hope that when you're running the test, your machine is not actually doing anything else, for example. I don't know. So, yes. So, the idea does not work. I mean, it's put on hold for now. And, well, the kind of thing we are thinking about is, yes, okay, let's do a standard JIL-free pi-pi. It would not be an STM pi-pi. It would be basically the same thing as Larry Hustin is doing for C-Viven. It's a lot of work for us. Well, see that in talk later. Okay. Reverse debugger. What reverse debugger is something that gave a learning talk last year here? So, a reverse debugger is an essential tool that everybody needs like once a year or once every two years, something like that. Myself have needed it twice since the last year. But it's essential. It's a debugger with the ability to go forward and backward. So, you run your program and up to a point where you get nonsense. And then, well, like in 95% of the case, you can think ten minutes and figure out why it's nonsense and you fix the bug. But in the five remaining percent of the case, you really have no clue why you are getting this nonsense. And in order to figure this out, well, use revdb, basically. Revdb lets you follow the values where they come from in reverse. Really. So, you put a watch point on a value, for example, and you can run your program backwards. So, the program will run until the point where that value changed. It's just very useful. So, here is a URL. It's implemented by a different version of PyPy. But it is a version of PyPy with almost no restriction like it's a version of PyPy which can run C5 and C extension modules, for instance. It's fine. You cannot of course go inside the C5 and C extension and go backwards step by step. But you can go backward over a complete call to a C extension module, for example. That works. Okay. So, last, a few random changes that occurred in PyPy last year. We improved to git, mostly by some reduction in warm-up time, which means that, like, if your program really, if your program really took a lot of time to start, then now it takes a bit less time, probably still a lot, but less. We reduce the memory usage, memory consumption, mostly the memory consumption that occurred during the start-up. So, this is just general git improvement. We have VM prof nowadays. So, VM prof is a high-performance profiler for Python codes. So, think about hotspot, for example, which is a very old profiler for C Python. So, it's something similar. But, well, the advantage of this is that it works the same way on Python, C Python and PyPy. And also, if you use the PyPy version, you can actually follow and see this function here was executed by turning the function, this loop inside the function was, like, this loop inside the function was turned into machine code, and you can actually see the machine code. So, you can see when things don't go right for some definition of right, CFFI. CFFI is a way to call C from Python. And it works identically on C Python and PyPy. So, it is a reason why I think CFFI is great. But, well, from what I've heard, from what I regularly now, from what I regularly hear inside conferences, CFFI is actually used by a lot of projects and that includes a lot of projects that don't have anything to do with PyPy. So, the biggest improvement since last year is embedding, which means basically calling Python from C. So, if you have a program written in C or whatever, actually C, C++. So, if you have this big program, you can write, well, you can write a bit of Python and then compile this, well, you write a bit of Python, then you execute the CFFI compiler on this and the output is a standard C library. A standard C library that has the interface that you specify. So, it means really you can write any C library with any interface. So, you write it purely in Python. And people are actually using it on IM, too. So, it works. Cool. Okay. So, next year, what is going on, what is going to happen inside PyPy during the next year is probably something like that. We will continue to polish PyPy 3.5, probably go and start 3.6. NumPy and the scientific stack, yes, we will continue working on it. And, I mean, by now, it's mostly like fixing the major performance issues. And we have actually ideas about how to fix them. So, it's just work, just quote, quote. We will play with PyPy without a gill. And do things like reverse debugger. We need to port it to PyPy 3.5, which means basically writing an extra module, which means to be adapted from PyPy 2.7 to 3.5. Well, this is the kind of thing that we are looking forward. So, thank you. Here is the website. Thank you. Thank you, Armin. Great talk. We have six minutes for questions. So, okay, just one question there. Do you hear me? Because some people have trouble hearing speakers, exactly. I understand. Thanks for the very interesting talk. There was another talk that mentioned the new frame evaluation API from 5.2.3 or something, which is used by PyCharm. I saw it in a PyCharm debugging talk. It's also apparently intended for jitting CPyton. Can you shed some lights on how this relates to PyPy and whether, I don't know, yeah, you know more about this? Yes. So, yes, it is indeed probably a good thing for CPython. But it's completely related to PyPy. I mean, at the end of the story, I would say, what we're going to do about it in PyPy is just, well, add support for this indirection for the CPython extension module, and that's it. So, you said that you now support Scython really well. Do you support Scython specifically? Do you add support for Scython or is it just that the improvements in CPyhacks to make it possible to run the extension modules that Scython generates? And if that's the case, did you do special things to make sure, in particular, Scython worked well or did it just fall out of all the work you did on CPyhacks? Right. So, no, it is all standard CPyhacks work. But, well, we really had the problem of running this big Scython module like pandas or something on heads to tweak CPyhacks until it supports enough of the CAPI, like enough of the details of the CAPI to be able to run because because Scython is doing a bit of crazy things like making up some PyFrame objects or something like that. I got a question about the STM. Would it be possible or useful just to have a limited subset of PyPy supporting STM like a list dictionary on a set implemented that rock is STM? Would it be possible? And does it fit in the philosophy you follow with PyPy? Yes, I don't know. I don't know. I mean, yes, maybe it is indeed a good idea to have an independent module in which you send code but not generic Python code but specialized code and then have it run using STM, maybe. You said that CPyhacks, calling across CPyhacks is slow. What kind of order of magnitude of slow are we talking? Order of magnitude are we talking nanoseconds, milliseconds? So, what order of magnitude I'm not sure, maybe five times something like that, I think. I mean, it's a number that can be improved by adding more special case. I mean, CPyhack often has tons of special case for calling a C implementation of a built-in, for example, and we don't have them just because. So, it's a matter of adding that but, yeah, they will always be maybe two or three times slower order of magnitude. Yes, too bad. Hello. As you know, we have the end of life of Python 2 coming up fairly soon in 2020. Is the end of life for Python 2? Is there plans to keep, I guess, progressing with the PyPy 2 after that or will that be seen as building a dead horse? Yeah, that's a very loaded question. I don't exactly know how to answer it. I mean, how, well, I would say I imagine that we'll just continue supporting Python 2 forever basically just because PyPy itself is written as a pile of Python 2 code. But yes, that's about all I can say. So, sorry, we are running out of time. Well, let's thank Armin again. Great talk. Great project.