 I've been working a lot on Pulse 6 past years and I'm going to talk about making Pulse 6 or Camelia flying faster. We've been talking about how slow things are and well I'm going to talk about how slow things were and how much faster they are now. So actually we're talking about Rakudo Pulse 6 or Morviem. This is of course the most advanced Pulse 6 implementation that we have. And since Christmas we have had over 8,800 commits, which is basically about 1,000 for Morviem, about 1,300 for NQP, about 3,300 for Rakudo and for the documentation and also about 3,200. So that's about 22 every day, single day since Christmas. I think that's quite a lot of work. So it's almost one every hour. We're working for the hour but so get more people in Pulse 6 involved and write documentation if you find a problem with documentation. It's a good way to start. So Rakudo Pulse 6 basically depends on a number of building blocks. And the biggest one actually or the one at the bottom at the moment is basically Morviem. It's short for metamodel on a runtime or as it originally was called also as the mother of all run times. It's a dedicated virtual machine for running Pulse 6. So although the original virtual machine for Pulse 6 was more intended to be a generic virtual machine, Morviem is dedicated to Pulse 6. Having said that, Pulse 6 is just a language implemented using Morviem and NQP. So if you feel like doing your own language on that level, please go ahead. If possible we will help you but you're mostly on your own but there you go, you might want to do that. It has a monthly release cycle and if you want to see about what it all does and all the releases, that's where you need to go. The next building block is somewhat opaque. It's called NQP. It's not quite Perl. And it's basically you could say the assembly language of Recruiter Pulse 6. It is written in NQP itself hosting which is I think quite a feat in itself. But the nice thing about it is that Morviem is like one backend for NQP. So the only thing that you actually if you want to have another backend for Recruiter Pulse 6 is most of the work that you need to do is actually make it work with NQP. So we have the JVM as a backend also at the moment and there's very extensive work done to make JavaScript a backend for Recruiter Pulse 6. And we actually can already say hello world in that. It's a start but all of the other materials like parsing grammars and everything, that all works. So you can write your programming language in this. We've done this with Perl 6. It also has a monthly release cycle. It actually does not have a website of its own. It's just something that lives in a repo. But yeah, there you go. And it's basically the same for all backends. So basically you need to target NQP if you want to write your own backend. Some people are saying I want to have an LLVM backend. Well please go ahead and target NQP. There you go. Mercudo is actually written in NQP and Perl 6. And a tiny bit of C but you don't really want to know about that. It's for very hot code pass that we actually done that. And it's basically I think about 20 lines of C code. So it's not a lot. The bootstrap is written in NQP. So, Perl 6 has all these high level types like bool and attribute and parameter and subroutine and all that shit. These need to be created. And actually they need to be bootstrapped before you can actually write a grammar that actually parses your Perl 6 code. So that part is written in NQP. It's not nice because nothing really exists. It is really a bootstrap. But it works. And on top of that we have the core settings which is basically giving you all of the even higher level stuff like sets and bags and all sorts of handy subroutines like map and grab and stuff like that. They're all implemented in Perl 6 and actually part of the settings. And this also has a monthly release cycle. And of course this is all the same for all backends. Almost. Sometimes the JVM does things slightly differently. So we have some conditional Perl 6 code somewhere in the core settings. So this is for the JVM and this is for everything else or vice versa. But there used to be a lot more of that. And it used to be way worse when we also had parent as a backend. So most of that is gone now. So we don't have to worry about that so much anymore. So what did we do in 2016? Well we really worked on making 6.C which is the version of Perl 6 that was released at Christmas. Hence the C. Make it faster. And basically make it faster without any incompatible changes to the languages to the language. And also make them more reliable and more stable. But mostly make things faster. Yes. So how are we going to make things faster? I'll get back to that later. What are we going to do in 2017? We're actually going to work towards 6D. And this is like, I forget what a D stands for. Dvalu. Something. It's some kind of Indian fest or something. Dvalu. Okay. Dvalu. Okay. There you go. But we're still going to be talking mostly about making things faster. They're actually going to add new features that you actually have to opt in by saying use V6D. And before we have a V6D we actually have a V6D preview. But you actually can mix pre-compiled files from 6C and 6D without any problems because each compilation unit has its own level. And you can actually call codes from different levels. So the version of the language is basically depending on the compilation unit. And a pre-comp doesn't depend on that. So what are the strategies that we have for making things faster? We actually have seven strategies, not six. We have static optimizations. We have pre-compilation. We have specialization. This is not a spelling error. We have jitting. We have doing less for the same result. We have better algorithms. And we have manual optimizations. Try to make sense of a lot of the stuff that goes on. But keeping track of all of the developments in all of the systems and all of the repos is pretty hard. Especially if this is like very about jitting and stuff like that. It's in the, I've been asked category. This is above my pay rate. I sort of like how I understand cars. I know there's either an electrical or an internal combustion engine in it. And it does stuff and okay. So all errors and misinformation are completely my fault. But if you really have questions in that area, you should basically go on the IOC channel on Freenote, the six channel or the more VM channel if you're really into the more VM stuff and ask a question there. And that'll be people that can answer you. So and if you're one of those people here and you see I'm doing something wrong, please tell me. So I can actually fix the slides for the next time I give this presentation. So static optimizations. What it basically does is after your program has been parsed and it has created an internal representation called an abstract syntax tree. It actually goes over the abstract syntax tree and basically finds stuff that it can do. And this abstract syntax tree is a result of both the grammar and the actions. Somebody gave a talk about it this morning about grammars and actions. Anyway, I must have not paid attention too much. Sorry. But this is basically the oldest type of optimization that we've done in Rikudo. This is basically from the way in the beginning making things faster by looking at the ASDs. Of course, this is very hard work because it's ASDs. It's not something you recognize immediately anymore. So it's basically a lot of stuff. And if you talk about right only optimizations, this is one of those areas. There's only very few people now that actually know what's going on there and if something breaks there, we have a problem. So we actually try to take things out of the static optimization and basically take it into the newer stuff. So it's actually not really inactive development anymore. But to give you an example of this, this is an example of doing something a thousand times in Pro 6. What it does is basically removes the range object. It actually binds the dollar underscore to a native int with the value of minus one. And then it turns the four into a while loop while pre-incrementing dollar underscore until it hits a thousand. So we have no iterator overhead. We have no unnecessary objects. This is basically really fast. And this actually, this also jits very well into machine code. And the empty loop example of this is actually faster than Pro 5. It's not very useful, but there you go. Another example of static optimizations and that is still very useful. In Pro 6, we have something called multis. So we have a subroutine called foo. We have a prototype for it, proto, which is actually a dispatcher. Now normally you don't have to do actually specify that. I'm just specifying it here so you can actually see that there is such a thing.