RPython with Maciej Fijalkowski

Hello, and welcome to podcast.init,

the podcast about Python and the people who make it great. You can subscribe to our show on iTunes, Stitcher, TuneIn Radio, or add our RSS feed to your podcatcher of choice.

You can also follow us on Twitter or Google plus and please give us feedback.

You can leave a review on iTunes to help other people find the show, send us a tweet or an email, leave us a message on Google plus or in the comments in our show notes, and we've also started a new discourse forum at discourse.pythonpodcast.com

where you can join the community to discuss the show.

I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable.

For details on how to support the show, you can visit our site at pythonpodcast.com.

Linode is sponsoring us this week. You can check them out at linode.com/podcastinit

and get a $20 credit to try out their fast and reliable Linux virtual servers for your next project.

I would also like to thank Hired, a job marketplace for developers and designers, for sponsoring this episode of podcast.init.

Use the link hired.com/podcast

init to double your signing bonus to $4, 000.

Your hosts as usual are Tobias Macy and Chris Patti. Today, we are interviewing Maciek

Filkovski

on RPython.

Maciek, could you introduce yourself, please?

Hi. I'm Maciek Fialkovski, and I,

live in Cape Town, South Africa,

though originally being from Holland. And for

the last

10 or so years, I don't actually remember. I think I served in 2006.

I've been a

a core developer of the PyPI project, which also includes the RPython toolchain.

So,

Maciej, how did you get introduced to Python initially?

How did I get introduced to Python?

I I have very hazy memories of that. It was sometime during studies, I think.

I was, at the time, working in Perl. Not sure if anybody here remembers Perl as a language or it used to be a

thing.

And

Perl,

while a wonderful tool, has serious problems with scaling

to

larger projects. Like, the projects become clunky. The object orientation is never very good.

So I was looking at other languages to see what can be higher level than c because I never felt like dealing with strings in c is a fun exercise,

and not plural. And I that's how I ended with Python.

What is RPython, and how does it differ from CPython?

So RPython is a very strange language, which generally should not be recommended to people to use, but it has been used for a very specific purpose. Notably, it's

a language

for writing interpreters,

and

the this is essentially like this is where the the difference starts. Our Python is a static subset of Python.

That's the language.

And as a static subset, it's amenable to

compilation into c or LLVM or assemble the the lower level languages.

It's it's an ugly language. You should not generally use it, but

generally speaking, Python

is not great for system programming. Like, you wouldn't want to write,

operating system

virtual machine or language platform in Python because, well,

it's too high level. So that's how our Python got introduced. It's a strange mix of low level features,

static analysis, and a good bit of magic to

make sure it all works.

And you said that it's a static subset. So is it implemented in c? And is the syntax at all similar to how you would write Python? Or is it

Python program.

But the way you use it is very different from normal Python. Like, you can't use most libraries. You can't use dynamic features.

Most of double underscore methods don't work

except and

Dell and a bunch of others, but, generally, they don't.

You can't mix different types. They have to be static. You don't write the the types yourself, but they have to be

static

enough

in order for our Python to figure things out and compile it to efficiency.

So

that

compiler itself is written in Python,

but it it compiles

our Python to c, so it's detached from the Python runtime once it's compiled.

So introducing this step is also a major difference between Python and RPython.

And can you share some of the history of RPython in terms of the major improvements and design choices that have been made?

So RPython started as a very strange project. Like, not sure if you remember the project called Psycho.

I've I've heard of it briefly, but it's been a while. Psycho was a just in time compiler for CPython precisely,

and it was replacing the inner loop with,

with small

special code that would optimize into assembly.

And cycle had

a lot of problems, and 1 of those problems was that it was trying to encode

in

in the just in time Python language. Python,

contrary to popular belief, is actually quite rich

and extensive language. I always have a slide that says that

you can fit on 1 slide the exact rules of addition, how how it actually happens. Like, which method? Is it under under art or under under error? That's depend on

the types, classes,

descriptors, everything. It just doesn't fit on 1 slide. So there's a lot of semantics we sat down and just say, okay. We want a simpler language, and we want to

that's not exactly how history happened. It was more accidental, but it might as well.

We want the simpler language, and we want the statically compiled language that can that the just in time compiler can be written for without too much trouble. And then we're gonna use the language to implement

implement Python

interpreter.

It is Python,

and then

we would use that to generate just in time compiler for

for the interpreter written in our Python. So

1 of the problems is that if you write this stuff in c, c is not a very good target for static analysis.

Like,

say, if you look into CPython source, you have

encrypt

sprinkled all over the show. Like, every single file has 1, 000 and thousands of manual

reference counting, and it's really hard to do.

So what we did is said, like, no. We don't want that. We want a language that that we can automatically

analyze and look at the graphs and then say,

okay.

Those flow graphs have those properties. We can insert this garbage collector or that garbage collector depending on the details,

and we don't want to encode, like, encrypt and decrypt all over the place.

This is how our Python got created

as

needing a slightly higher level

language than c but lower level than Python. And at the time, there was nothing really comparable. I

remember it's it's over 10 years old. So it's before

things like Go and Rust will even were even introduced.

And in the documentation, it says that our Python is able to generate a just in time compiler for dynamic languages. Can you explain why that is significant and some of the ways that it does that?

So it's done as as as I described previously.

It's,

because you can write an analysis step or our Python flow graphs, you you might as well write 1 that generates a compiler. And this is

so you write your interpreter in our Python,

interpreter of any language, ideally dynamic language because this is what the interpreters are good for. And our Python

tool chain through the

looking through the graph and and thinking about it really hard would generate the just in time compiler for that. So you have 1 input that will

create an interpreter that is compiled to c and runs like a normal

standalone executable,

but it will also be able to dynamically emit assembler code

specialized

for your language. So that's something that

has

seen quite a bit of uptake, and there is a project,

that does the same for JVM called Truffle.

It's for growl JVM. And that's exactly that, except instead of using our Python, use Java.

Yeah. I can recall

I listened to an interview

with some of the PyPI developers a while ago. And 1 of the questions that was asked is how many, you know,

JIT compilers there are in PyPy? And the answer was that we don't know because they get generated dynamically. So I thought that was kind of

a curious statement. So I don't know if you can dig into that a little bit more about how those get generated on the fly.

Well, for example, if you think about Python,

you would think that there is only 1 bytecode really there, but there there are more. Like, there's bytecode for regular expressions,

and that gets

another

generated. There's another bytecode somewhere else that does something slightly different.

And and since we have all the infrastructure, we might as well generate the the Jits for that too. So, like, for example,

under regular expressions are much faster than under c Python

because we we have a JIT that got automatically generated.

We we didn't even need to write it.

And with a JIT,

is it possible to reuse the compiled

code if you stop and restart a service, or is it rebuilt

dynamically every time a program runs?

It's definitely rebuilt dynamically, and

we were discussing, like,

can we do something about it? Can we

store and save save and restore the the state? And it's generally quite difficult

partly because

Python is such a

strange language where it's very difficult to say,

is this module that I imported the same 1 as before or not? Like, you can't just compare code because it has constants, and the constant can be get from anywhere because import statement can do can execute very arbitrary Python. Like, there there are no limits.

So unlike, say, PHP, where there is a very well defined boundary between

compilation step and the runtime, and Python is all intermingled together. So if we can solve that question somehow, we could potentially think about storing and restoring the

the data. But right now, no. Right now, you need to warm up it again each time you run a process.

And so the most well known use of our Python is the Py Py interpreter. Can you share some of the other languages that have been ported to the RPython runtime and how their performance has been improved or altered in the process?

So there has been a lot of experiments.

I don't

think any of those has seen much actual adoption,

but there has been HIPPM, which is a virtual machine for PHP.

There is, TOPAS, which is a virtual machine for Ruby,

and there has been numerous scheme interpreters

and tons of other things that

they generally show that that improvements are possible, and you get them for

relatively cheaply. There there's definitely 1 about Rocket. It's called Pykit.

Pocket. Pykit. I don't know. And that 1 is is undertaking some serious development.

And you can see how like, what the other thing you can see from that is how difficult it is for a new interpreter to make its way into the community.

You need to run most of the packages. Like,

you need to be able to run extensive libraries. You need to be able to

somehow compete with the deployment story,

etcetera, etcetera.

So it's

it's not that easy to

introduce a new interpreter and just hope everybody picks it up.

Yeah. There's the, the adoption curve can be tricky 1 to overcome for, as you mentioned, an interpreter, but also for even just new packages or entirely new languages because there's always the initial trepidation

of, oh, is this stable? Is this actually going to stick around? And you sort of have to just keep plugging away and make sure that it stays visible long enough for people to finally get over that hesitation

and concerns and and actually start using it and feel feel confident that they're going to be able to continue using it far into the future.

We've seen complaints about Py Beta. PyPy is not shipped with

some random arbitrary version of Red Hat, and this is

something that's

impossible to fix without the time machine, essentially.

Like, no. It won't accidentally get shipped with a version of record that would be released in 2, 006.

Like, it's just not gonna happen.

So those sort of problems are things that we

you need to overcome, and sometimes it just means waiting.

Yeah. Patience is definitely an important attribute in software despite the rapid rate of change and how quickly somebody can, reimplement an idea, you know, it's definitely important to remember that patience is valuable as well. So are there any languages that have been designed entirely for use with RPython rather than translating an existing language to run on it?

I'll finish the last question with with with the fact that most language platforms

move much, much slower than your average software package. Like, all the languages that we use, not all of them, obviously, but most of them are at least 10 or 20 years old. Like, c is really old. Python is really old. Even Python, which is the new kid on the block, has been around for 11 years. Even V 8, that's, like, this brand new JavaScript engine, has been around for, like, 5, 6 years, something like that. So it really takes a long time for for it to pick up. To answer your question about the languages that have been designed entirely for you, Sudar Python,

I think Pixie is the biggest example. It's this sort of list, I think.

PixieLang.

I haven't

looked at it, but I've seen

people talking about it. I have absolutely no idea what it does, to be honest. But there there definitely has been thing.

I just don't hear every single use of our Python.

Yeah. It's, definitely a common theme that we've heard a number of times in our interviews as well as, you know, just in general conversation is that for any open source package, it's difficult to keep tabs on the usage and

sort of how well represented are people's experiences with it unless they're negative and they come back with a bug report.

So do you know of any cases where an application has been written to run directly on RPython rather than,

via 1 of the interpreters that are based on our Python?

No. And I hope I'll never see what our Python is really not that great language. Okay.

So it's theoretically possible, but highly discouraged.

Yes. Yes. Yes. It's definitely highly discouraged. RPython is a bit like c plus plus You can write books and books about tips and tricks on how to do things, and there will be people, like, very different ideas what's really RPython, what's

not that cool our Python, etcetera. Yeah. Not necessarily.

And what are the computer architecture and operating system platforms that our Python supports? And I'm wondering if you have any plans to extend that support.

So we are expanding this quite rapidly, actually. So as of now that

Trunk

supports x86,

Power PC 64,

and ARM without ARM 64,

and

OSX Linux,

Windows 32 bit and to an extent free BSD.

We have ongoing work for s 390x,

which is a mainframe architecture. So PyPI is getting,

industrial ready or enterprise ready. That's the there.

But, yeah, we are expanding this to

pretty much anything that can run

software these days except tiny embedded devices, which are just too small for that. So

probably we'll see MIPS at some point and risk 5, and then we'll cover the entire range of architectures that you actually want to support these days. That's not legacy hardware.

Right. Yeah. You definitely have to have some cutoff point of,

how far back you're willing to support things. Because I can't imagine anybody wanting to run, PyPI on a 486 or the even older 8086.

I think we ship,

the default version that requires SSE version 2,

which has been introduced

in Pentium 3 or Pentium 4. And there have been

complaints that it, it, like, doesn't work on specific hardware,

which is already, like, 2 decades old or, like, a decade and something.

I don't know.

I don't know exactly when it was introduced, but a while ago.

You'd be surprised how many people end up backporting

all kinds of crazy things to, for instance, the Amiga.

But that, it's certainly understandable that, you wouldn't want to support every crazy archaic architecture out there.

Yeah. Exactly.

And,

aside from the CPU architectures, are there any minimum

space or RAM requirements for their necessary to be able to run a language written against the RPython platform?

It all depends on the details, but RPython

and all the interpreters are garbage collected languages. So you would want at least a couple megabytes of RAM. If you have a platform where RAM is really scarce and you have some kilobytes of RAM, you can write in our Python program for that, but you're gonna run into trouble.

Like, things will try to allocate, and it's impossible to allocate. Like, you wouldn't write a program that that has to run-in

fixed amount of small memory. That's that's exactly what c is for. Mhmm.

So is Python similar in concept to other efforts like Parrot and the Perl world?

No. Parrot tried to do what JVM does, which is provide

a

common

platform, common virtual machine that speaks 1 language,

and then

everybody would just compile to this high level

platform

and and be happy. And

this doesn't seem to be working very well. That same goes with JavaScript these days. Like, you can compile any language you want to JavaScript, but you either have to choose. Your language has to be like JavaScript.

I don't mean syntax because you can change that. But semantically,

either has to be like JavaScript or will it be very, very slow.

So

you have this this semantics mismatch that makes it

very difficult to compile certain things to a different high level virtual machine. And this is what Parekh tried to do, and this is where it failed because it turns out it's impossible to find a reasonable common subset

because everybody is different. If you write stuff in our Python, you can write

anything. We've seen people writing an ARM emulator in our Python, for example, and it was pretty decent.

It wasn't as fast as the as the fastest ARM emulators out there, but it was it was

much less effort. The fastest ARM emulators these days

used jitting technique to achieve, like, reasonable performance on x86, by the way.

But it was faster than any sort of interpreted ARM emulator out there. So people have done very, very different stuff, and it's very difficult to think how would you write an ARM emulator that compiles to JVM and is actually fast.

Yeah. With the recent advent of web assembly, that whole idea is sort of getting revisited in a slightly different light, and then also in a slightly different context, LLVM

can be sort of thought of as a, common compilation target as well.

Well, LLVM is yet another something completely different. LLVM can be thought of as portable assembler.

Mhmm. And it's definitely a notable goal. Like, you want the portable assembler. It's great because having 7 different back ends that and

it things that are mostly similar but slightly different and definitely not compatible is is annoying. So

LLVM is

but that's about it. LLVM won't give you more tools. Like, it won't come with a garbage collector. It won't come with a just in time generator,

and stuff like this. So this is entirely different project. It serves its niche, and

the idea is that you can compile

anything to LLVM, which is this low level assembler,

but only 1 and not n.

While r Python is you use our Python to write stuff. You don't want to use LLVM to to write anything. Like, in LLVM bit code, you'd probably write in c plus plus or c.

For anybody who's actually interested in using our Python for their own work, what would be your recommendation for getting started?

There is documentation.

There's a collection of

blog posts about how to write your own interpreter.

Just googling around should give you enough documentation to get started. It's

it's a good middle ground, as in

you probably won't get as much performance as writing a very custom

custom cut assembler generator like LuaJIT,

but also will be massively better than your first

interpreter written in c.

So it's this middle ground where you want you will get most of the speed at relatively minimal cost.

And are there any particular areas of the project that you need help with, and how can people get involved with that work?

People can do well, our Python is an umbrella project for a lot of things. Like, there's

some research done on

software transactional memory. There there is project

on providing numeric computing on the r Python platform,

etcetera, etcetera. Like, there there's a lot of different projects that and, generally,

I would suggest that people scratch their own itch and try to make things

that they're interested in, and that's usually the best way to get involved. Like, find a problem that interests you,

and and then see how it fits in the project.

Yeah. Software transaction memory is definitely a very interesting area of research, and I don't know if you're able to dig into that a little bit. I know that that's 1 of the ways that PyPy is attempting to

create an answer for the parallelism problem.

So soft new transactional memory is very interesting because it's this sort of project where

let me start with explaining what it actually does. So the idea is that you

you write your code, and as long as the code doesn't do any IO,

you optimistically

paralyze couple threads of execution.

And then if they come into conflict with each other, you roll back 1

1 thread. So to the user, it looks like you're running couple of threads with 1 gigantic log. So it's much easier to reason reason about, but it's a better way to write software, essentially. Now the problem is that with the current hardware and the current level of knowledge on how to do things, you're still paying a relatively high price for for a software

memory. Like, we haven't been able to get consistently

below 2 times the the cost, and that's too much for some people or, in fact, for most people.

So it's a kind of strange project where if you can't get the single thread performance within certain range of of things running without the software transactional memory, you have this really interesting research project that doesn't do anything useful. If you can

get it within, say, 20% of the cost of single threaded, you now get parallelism for free, and that's a new model to think about software, and this is completely revolutionary.

And there's middle ground somewhere in between whether and the middle ground depends a lot on, I would say, engineering, but there's a lot of science involved in how do you actually want to do it. Can we get some support from hardware?

There has been definitely

attempts to do that from Intel with introduction of hardware to Einstein memory, but it comes with own

own set of problems.

So

how do we do that is a very open and interesting question. And if somebody solves it, it will be

a new way how we think about,

parallel software, I think.

Yeah. It's definitely

I'm definitely intrigued to see how that ends up turning out because if we could get cheap and easy easy parallelism in Python, I think that that would assuage a lot of concerns that people have about the future viability of Python in the face of some of the new generation of languages.

Yes. I mean, STM gives you something more than just multiple threads being able to run at the same time because people have multiple threads

in c. And

as far as I know, everybody tries to avoid this, like, fire unless they absolutely have to because it's a major

nightmare to deal with and to debug problems. You can't write the reasonable test to check if there are no race conditions, for example. So

that's why SDM is so interesting, not just because it gives you multiple threading, but it also gives you a better way to think about software.

So are there any questions that we didn't ask that you think we should have? Or anything else that you wanna talk about before we move to the PIX?

I think 1 interesting

thing to think about, which I've been I've been thinking a lot about myself and and definitely

is about private project, but not just about private project, is that the question is how do we pay for open source? How do we make sure that open source is

developed in a way that's independent of large companies

and

in a sustainable way because open source is just

so much better way to develop software than

it's so good that we

really don't see much of like, all the language platforms that are proprietary essentially died or went to open source. Otherwise, you can't survive in this world. So

that's something that I don't have any actual answers, but I think it's an interesting question to ask.

Yeah. It's definitely 1 that keeps recurring, particularly lately. I've seen it crop up a number of times. And as you said, it's not an easy question to answer, but definitely an important 1 to continue thinking about and try to come up with an answer for. Like you, I don't have

a solution for it yet, but,

perhaps we can have a future episode to dig into that idea a little more deeply.

I really like Eric's solution when we had him on for read the docs, the

companies

that

utilize

them

should

pay

into

them.

And

I

the companies that utilize them should pay into them. And I think programming languages are are are similar. Right? I mean, and it's hard it's very hard to get companies to recognize this and to be willing, but I think it's a good idea in any case. And, yeah, we should do an episode on that. It's a great plan.

I I like the idea of making comments paid. I don't know how you would go about this, though. Yes. Right. Exactly. I agree that's guilty, but the main problem, I think,

is probably the answer is, like, multiple ideas. But, like, the main problem is that these days, if you talk with with

companies as an open source developer,

they're gonna talk with you from a marketing budget perspective.

Their contribution to open source

is marketing for them. Unless the project becomes so essential to their business that they essentially take over. And it's only possible very large companies like Google or Facebook when they just take over gigantic open source project because

it's essential to their existence.

But we want them to look at this as

investment for the future, like something that's

engineering effort, not a marketing effort. That's that's a major shift in in view that

we are missing here

because they don't consider open source engineering. They just consider it something that exists there, and you can throw a few dollars and make it a good marketing tool. I'm sure we could spend all day debating the relative merits of various plans, and it's definitely an important conversation to have, but I don't think we'll come to a conclusive answer.

So with that, I will go ahead and move us into the picks.

My first pick today is going to be the Pycoders

2015 recap.

They went back through the past year of their weekly newsletters and pulled out all of the most common

projects and articles,

and it's just a really

good resource to get a high level view of the different things that happened in the community over the past year.

So lot lot of good information, good utilities.

Highly recommend checking it out.

My next pick is going to be a, 3 in 1. So

I recently picked up an Xbox 1 for the family,

and I got it with the Kinect sensor.

And I also picked up the game Shape Up, which is,

it uses the connect for its play, and it's a gamification

of different exercise routines.

And I have,

I have I have children who are occasionally high energy, so it's a good way for them, you know, when it's raining outside and they need to move around to get them to spend some of that energy. And it's also fun for the wife and I to play with them and against each other to, you know, just play along with the games because they're very entertaining and there's a lot of,

humor to the to the different scenarios. So we've been enjoying that. It's a good way to encourage you to do the exercise that we all know we should be doing.

And for my last pick, I'm gonna choose the movie Selfless.

It's an interesting sci fi movie that came out recently,

and the basic premise is that there's a, you know, very rich individual. He's dying of cancer. But he is approached with the possibility

of transplanting his consciousness into another body.

And he's initially told that the body is

grown in a vat, you know, genetically engineered,

and so there's no, you know, loss of human life or effect to any other people. And at the risk of ruining the story, I will stop there. But definitely worth a watch. And with that, I'll pass it to you, Chris.

Cool beans. So my first pick is a Tumblr.

Now, a lot of people think tumblers are basically just memes and and other, you know,

frivolous crud, but that's absolutely not the case. This is the,

NPR's

Science Tumblr,

but it's really interesting, very visual, very cool. It's just it's great stuff. You should check it out. My next pick is a card game.

In the category of card games that that are

really, really simple, that you can sort of teach to people in a in a matter of a couple of minutes. The rules can be described in a single sentence. But there's actually a fair bit of depth and strategy there,

which I really prize that kind of thing because my wife won't play anything else. So

I I was really happy to find this.

It's called Category 6.

That was the version that I played. It's known by many other names. The original name was called 6 Nimit.

It's really neat. It's it's basically,

you have to place cards in a column,

and you're trying not to place the 6th card, and each card has to be numerically greater than the last. It's just a lot of fun.

My last pick is a CD

or a recording.

I've had this CD

probably since I first got shortly after I first got my CD player in, like, 1988

or so. So it's

old, but it's really good.

I'm 1 of those people who sometimes likes to fall asleep or work to

environmental noises. The sound of rain falling,

the sound of a thunderstorm,

the sound of,

a meadow,

and the various sort of electronic,

generated

approximations

thereof just don't do it for me cause I have really good hearing, and I know what these things actually sound like,

and the the fake versions just sound horrible and wrong to me.

And this CD is some really amazing recordings

of the outdoors.

It's called Environments,

and I really love it and haven't found anything better than it to this day.

Actually, I'd I'd love it if anybody has other recordings

of this kind of thing that they like that are more recent.

And that's it for me for picks. Masiyech, what do you have for us?

I was presented with the list of picks a bit on the flight, but I'll go ahead and try with Saigon South Africa. I would help me invite people to come over

to the beautiful city of Cape Town.

It's rough. It I don't think dates are

set yet, but it's,

usually October.

So

that's when

places like East Coast or Europe get really gray and just not fun to to stay stay at.

While Cape Town has

beginning of summer. We get, like, over 300 days of sun each year, and it's just a lovely place. And that's it from me.

Alright. Well, thank you very much for taking the time out of your day to join us. And for anybody who wants to

keep track of what you're up to and follow what you're doing and what's going on with the RPython project, What would be the best way for them to do that?

Well, the

we are usually very active on IRC. So just find us on the free node, and

that's the way to get a hold of most of us.

If not, then the mailing list is the main is the main place. We also run a consulting company around PyPI called baroxsoftware.com,

and we do

various extensions and improvements to both PyPI and our Python

if your boss finds it interesting.

Great. Well, thank you again, and I hope you enjoy the rest of your day. I'm sure everybody will enjoy learning some about RPython and, how it relates to PyPy.

Thank you, and have a nice day.

The Python Podcast.init

Summary

Brief Introduction

Interview with Maciej Fijalkowski

Picks

Keep In Touch

Links

The Python Podcast.__init__