HackerTubewatch
Surprise me
Frame from Making R run Fast - Jan Vitek Plays via YouTube's privacy-enhanced embed

Making R run Fast - Jan Vitek

John O'Neill
Talks
YouTube
3 HN users recommended this talk3 months2017–2023 score 3
Years with an HN recommendation, 2007–2026

HN points to it as the best explanation of why R is so hard to optimize, often paired with talks on Python and used to explain what makes Julia fast.

Jan Vitek of Northeastern University gives a meetup talk on the challenges of making the R language run fast. He explains what in R's semantics makes it hard to optimize and to build a JIT compiler for.

“Another talk on the difficulty of optimising R is this fantastic one by Jan Vitek” (HN, 2017)

3 recommendations · 1 citations · Talks · advanced

4 Hacker News comments

From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.

@StefanKarpinski Jun 2018 Recommends
on HN thread My favorite things that are coming with Julia 1.0
Perhaps the best way to understand what makes Julia fast is to watch these two videos about Python and R and what makes them so hard to optimize: [link] [this video] Take everything mentioned in these videos that make Python and R really hard to optimize and don't do those things :D
What makes R and Python hard to optimize.
@lottin Oct 2018 Recommends
on HN thread Faster R with FastR
I recommend watching this video - Making R run fast [this video] It's a little disappointing, because the conclusion is that R will probably never "run fast", but very interesting nonetheless.
Why R will probably never run fast.

Citations, criticism and jokes

@ChrisRackauckas Feb 2023 Cites it
on HN thread ML would have advanced faster if another front-end language had been adopted?
Read more
This is disregarding the development of said ecosystems though. The point is that Python has been quite inhibitory to the development of this ecosystem. There are many corpses of automatic differentiation libraries (starting from autograd and tangent and then to things like theano to finally tensorflow and pytorch) and many corpses of JIT compilers and accelerators (Cython, Numba, pypy, and TensorFlow XLA, now PyTorch v2's JIT, etc.). What has been found over the last decade is that a large part of that is due to the design of the languages. Jan Vitek for example has a great talk which describes how difficult it is to write a JIT compiler for R due to certain design choices in the language ( [link] , or the more detailed version [this video] ). There are certain language constructs that void lots of optimizations which have to then be worked around, which is why Python JITs choose subsets of the language to avoid specific parts that are not easy to optimize or not possible to optimize. This is why each take a domain-specific subset, a different subset of the language for numba vs jax vs etc., to choose something that is nice for ML vs for more generic codes. With all of that, it's perfectly reasonable to point out that there have been languages which have been designed to not have the compilation difficulties, which have resulted having a single (JIT) compiler for the language. And by extension, it has made building machine learning and autodiff libraries not something that's a Go
Difficulty of writing a JIT compiler for R.

Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.

Keyboard shortcuts

/
Search
j k
Next / previous video
r
Surprise me
l
Like (video page)
w
Watch later (video page)
?
This help
Esc
Close