 Hello, thank you for watching. My name is Shtipa Shindelash and I work for Racker Labs, where we are developing fast R. This talk is going to be about how fast R can help R package developers. Firstly, what is fast R? Fast R is an alternative implementation of the R programming language. I'm going to distinguish between R as the programming language and the standard reference implementation of this language, which most of you are using on a daily basis, which I'm going to call Gnuar throughout this presentation. Fast R is open source and is licensed under GPL. It is based on the Gravian platform. Gravian is a universal platform based on top of the Java virtual machine, which supports multiple programming languages. All those languages run in the same system, which allows them to reuse parts of the system, for example, the garbage collector, or the optimizing just-in-time compiler. Moreover, it also allows them to interoperate seamlessly and very efficiently inside one system. Fast R aims to be fully compatible with Gnuar, including R extensions and the C and fortune interfaces. Fast R can run packages like GGplot2, for example. Because fast R is built on top of Gravian, it leverages the Gravian optimizing just-in-time compiler, which means that fast R can run your R code very fast. On the right side of this slide, you can see performance comparison of fast R with Gnuar when running a retracing algorithm taken from this blog post by Tyler Morgan-Wall. We benchmarked two versions of the algorithm, the original version, which is partially written in R and in Fortran, and a version which is completely written in R. Note that on fast R, the R version is even faster than the version that combines R and Fortran. The basic tenet of fast R is that people should not resort to other languages just for performance reason. Moreover, being part of the Gravian platform, fast R can seamlessly and efficiently interoperate with other Gravian languages, especially with crawl Python. The two rightmost bars on the performance chart are variants of the same benchmark where the Fortran routine was replaced with an equivalent Python function. Note that the performance is almost as good as with the Fortran function. If you're interested in more details about these topics, I've had a talks at the previous user conferences that covered these. Today, we are going to focus on the last bullet point. Since fast R is based on Gravian, it is supported by all the tools that Gravian provides. The first one we are going to look at is the integration with Visual Studio Code IDE. There is an official Gravian extension at the Visual Studio Code marketplace. It supports several of the Gravian languages, including R. Because the R support is based on an existing R plugin for Visual Studio Code, which you may be familiar with already, you can use all the features of that plugin as well. For the following demonstration, I'm going to use this example of a simple R page. It defines two functions that both take a vector and a closure, and they apply the closure to each element of the vector and create a new vector with those values, which is then returned as the result. This is basically a simple re-implementation of some sort of a supply-like functionality. The difference between those two functions, R map and C map, is that one is written in R and the other in C. Here we can see how to set up the Visual Studio Code so that it starts fast R console with debugging enabled. This setup is also described in the readme file of the Visual Studio, of the Gravian Visual Studio extension. So now if we put a breakpoint somewhere in our code, the execution will pause at that point. We can inspect all the variables, the environment, the call stack, and we can even evaluate arbitrary R expressions in the watch window. If we put a breakpoint in another location and let the program continue its execution, we will hit that breakpoint and we can see how the variables values have changed. What is, I believe, a unique feature is that with some other programming languages, you can restart functions execution. This is sometimes called dropping frame. So if you miss something while stepping through a function, you can restart the execution of the current function. But beware that this throws back just the execution stack and not any side effects that might have been done in the memory already. Another tool we are going to look at is Visual VM. Visual VM is a tool with graphical user interface and it is used for monitoring and profiling of programs running on Gravian, both locally and remotely. This is how you can start Visual VM. The so-called polyglot sampler in Visual VM allows you to profile running scripts and identify performance bottlenecks. It is using a technique known as CPU sampling. If your bottleneck is caused by an algorithmic efficiency, it is almost certainly going to apply to both GNU or FASTAR. So we believe this can be useful, even for packages that are not targeted to FASTAR in the first place. This is a screenshot of how it looks like. You can see all the functions that were executed and how much each function contributed to the total execution time. In this example, we are running the T-apply function with a large vector and we can see that the function that takes most of the time, in this case, 73.8% of the total time, is function called stop if not. And this coincidentally corresponds to an observation made by several people that stop if not, but significantly slower in R3.5. Visual VM also allows you to take and inspect dumps of the memory of our programs. This can be useful when debugging memory leaks. In this example, we've created a vector called foo in the global environment. Its length is going to be 2001. And also a list with a named element. This list is stored in a variable called bar. On the left screenshot, we can see the foo vector in the memory dump. It is listed under the double vectors category. On the right, we are inspecting the global environment object and we can see that it references two elements named foo and bar. And that bar is a name place and we can see its elements and how they are named. Fastar can run the native R extensions in two modes. The default mode is the same as Gnuar, but in the LLVM mode, the code of the extension is executed on top of GraVM LLVM runtime. LLVM itself is a set of compiler and toolchain technologies. You can think about it as an alternative to GCC. The LLVM C compiler called C-Lang produces intermediate representation called LLVM bitcode from which it produces the final executable code. Instead of running the native code directly, GraL LLVM runtime executes this intermediate representation. What is this good for? In the LLVM mode, the R extension is running on the same system as Fastar and is also supported by all those tools that we've seen so far. Take for instance, the Polyglot sampler of Visual VM. When you run Fastar in the LLVM mode, you can see native functions in this tool together with the R functions. Whether your performance bottleneck is in C or in R code, this tool will help you identify it. Another example is debugging in Visual Studio Code. You can see the C functions in the stack view. You can put breakpoints in the C functions and you can step through the C code and even step between the R and C code. The traceback function in Fastar is also taking advantage of this. If an error occurs in the C code or if an error occurs in R code which was called from the C code, it can show you the C function name, the file and the line where it was defined. And this is all for today. If you watched to this point, thank you for your attention. Check us out on GitHub, download GraVM and let us know what do you think.