When you think about the performance of your software, there's nothing more low-level and fundamental than how your code executes on the CPU itself.
Many of us study and try to understand how to maximize performance at this low level, but few are in a position to define what actually happens there.
That's why I'm thrilled to share the work that Intel, the largest PC chip manufacturer, is doing specifically to make Python faster and to make their chips execute Python code even better.
This week, you'll meet David Stewart, Engineering Manager in the Intel Data Center Software Technology Group at Intel.
We'll discuss a wide variety of work Intel is doing in open source and Python.
This is Talk Python to Me, Episode 57, recorded May 2, 2016.
This music I constructed line by line, just like when I'm coding another software design.
In both cases, it's about design patterns.
Anyone can get the job done.
It's the execution that matters.
I have many interests.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter, where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm.
And follow the show on Twitter via at Talk Python.
This episode has been brought to you by SnapCI and now Metis.
Thank them for supporting the show on Twitter via Snap underscore CI and this is Metis.
That's right.
Metis and their data science education team have joined the show to keep the episodes coming.
Be sure to find them on Twitter and tell them thank you.
David, welcome to the show.
Thank you very much, Michael.
It's great to talk with you.
Yeah, I'm really excited to have you on the show today.
And I'm looking forward to looking inside what you guys are doing at Intel with Python.
It's going to be a lot of fun.
Yeah, it's really been exciting to me.
I think people have been really responding when I hear that Intel is doubling down on Python just because of its power and popularity.
So I think it's exciting to be a part of that for sure.
Yeah, it's really exciting to be part of Python in general.
I mean, it's really surprising and a pleasant way to me to continue to see this language and ecosystem that's 25 years old gaining momentum and gaining speed.
Kind of feel like it would have done whatever it did in the first five or ten years, but that's not the case.
It's great.
So nice to see Intel.
Your listeners probably, you're probably already aware of the fact that the top, the majority of the top CF schools in the U.S. are teaching Python as the first introductory language, right?
That's often a surprise when I talk, I was just talking to a professor at computer science last week and he was like, really?
They just didn't know about that.
So, yeah, it's really taken hold.
Yeah, I think that's great.
And, you know, to be honest, it makes me a little bit jealous.
Yes, I, my very first CS, not my first programming class, but my first CS class that was for programmers was in Scheme and Lisp.
And I would have definitely preferred.
Oh, my gosh.
Yeah, I would have definitely preferred to get Python in there.
But, you know, you get what you get.
Yeah, no.
I know what you're talking about.
Well, you know, if you were talking about Pity here, my first was with Fortran.
And, in fact, I had to teach Fortran programming to, you know, to engineering students and the like as a part of a graduate teaching assistantship back in the day.
So, yeah, I didn't necessarily do a lot of programming in Fortran myself, but it was one of those things where you sort of had to cut your teeth on something.
And there's still people using Fortran these days, but it's probably more than Lisp.
But, yeah, it's got to be waning.
I hope so.
I think we share some common history.
Like, I started out in, yeah, I started out in an engineering field, not in computer science.
And when I got there, they said, you have to have a programming class.
I said, great, can I take C++?
No, you have to take Fortran first.
This is the most important language you will ever learn in your life.
Then you can go take those other less meaningful ones.
So I took that and then I went to CS.
I said, can I please take C++?
No, you have to take Scheme.
I'm like, why can't I do a real programming?
Anyway, I'm going to get some hate mail for saying that, but that's okay.
I'm sure you will.
No, I really, I do like C++, but I wish I had Python in the beginning.
That would have inspired me more, even though I was already inspired to do programming.
Yeah, and I think that it's been particularly interesting.
There's so many open source projects that are, you know, kind of advanced by some corporate entity or something like that.
Python is a phenomenal project.
It's sort of like the Linux kernel itself, right?
There are plenty of companies involved with Linux, but it's really, you know, with Linus Torvalds being the, you know, the lead,
it makes a final decision on things.
And Python, that's one of the strengths, I think, is the kind of approach that Guido uses.
Guido Van Ropsen, who is the benevolent dictator for Life for Python.
I think he's really created, you know, just kind of an ethos and a culture around this project that I think is super unique.
And, in fact, it's a great, I hold up as a great example for people who aspire to, you know, establishing open source projects.
I mean, hey, this is one of the ways that you talk about, yeah, 25 years of, you know, experience.
And Guido's, you know, I think a phenomenal leader for that movement.
Yeah, for sure.
Yeah, he's doing a great job.
And I think there's a lot of positive examples of the Python community being a very positive place for open source.
And that's great.
So, before we get into the story about what you guys are doing with Python, maybe you could just sort of tell me how you got into programming in Python.
You said you took Fortran in college.
So, how did you get to there?
Yeah, I mean, you know, when I got my bachelor's and master's in computer science, I mean, C was really the most interesting language.
to me at the time because I was doing a lot in operating systems.
And so, I've been probably over the years of my career probably more interested in, you know, operating systems in general instead of languages per se.
And since C is a great language, you know, initially when I worked with it was Unix and then, you know, Linux, obviously.
I think that's one of the things that it was just when I think in terms of programming, it's still hard for me not to relate back to C.
But, you know, the Python work came as a result of a couple of things I got involved with back in 2010.
What happened was I was asked to start up a new project here at Intel to work on embedded Linux.
And it was kind of an amazing thing.
The core of this project had this something called BitBake.
And if you're not familiar with it, what BitBake does is it's a desktop application that will build a complete Linux distribution.
Now, this is actually quite interesting because what it does is it builds the compiler first, right?
And it has to bootstrap several different paths of the compiler building to get a functional compiler, right?
And then it goes and a Linux distribution could be made up of, like, literally a thousand different projects all over the Internet.
Individual projects with their own source control systems, their own repositories.
And this system will actually download the sources from all these different projects, goes and patches the source.
Of course, if you have an open source system, you want to be able to, you know, do patching of those things, right?
Then it will configure them, build them, build a package repository, build a running Linux image, and then an SDK.
And the amazing thing is that it does all of this in an hour, like one hour on a desktop computer.
And you're going, wait, hold on.
What magic is this thing doing?
And I started talking to the architect of this thing, and it's a massive Python program.
So BitBake is actually completely written in Python.
I was like, you know, I got to confess.
I was like, holy cow, this is a scripting language?
And I heard about, you know, things like, you know, you're able to serialize and deserialize objects.
And it's like, hang on, this is really powerful stuff.
So I worked on that project for about five years.
That was a project called the Yocto Project.
So anybody who knows that, that was something I was involved with.
And then, you know, things were going, you know, pretty well.
And I kind of get, you know, a little bit, you know, sedate, I guess, when things are going too well.
So I always like to have a challenge.
And at that point, Intel was really interested in, as I said, doubling down on Python,
because it's primarily the core of a lot of key things that Intel is invested in in other areas.
And so, and besides its overall popularity as a, you know, as a programming language.
So that was when I really, you know, got personally very invested in what was going on in Python.
So I, you know, started a group and we have engineers that are at the core of working on that.
So that was where I think I got really a lot of Python religion, obviously, at that point,
was not only seeing it as a user, incredibly powerful, but also be able to now, I think,
affect it positively on a community basis.
We're going to dig into some of the cool stuff you guys are doing on a community basis as well.
But you sort of started out with the philosophy of it's in Intel's interest to sort of understand
modern cloud computing and the languages that drive that and make that stuff go really well.
That's correct.
I mean, if you think about, you know, Intel, obviously, we try and sell processors in the data center space.
I think we've had some success there.
One of the things that if you look at overall, how are people programming those data center processors?
Well, there's obviously a lot of C++, C#, and Java, no question.
But as we kind of analyzed things, we said, well, gee, there are 7 million PHP programmers out there.
There's like 9 million JavaScript programmers, a considerable number on, you know, on data center computers.
And then Python is huge in that respect, too.
So if you look at the top languages that people are using our processors to run, right, it sort of says, well,
how do I, you know, I'm all about customer choice in that respect.
I'd like to make sure whatever customers are using that they get the best, you know,
possible experience with our processors.
And so it just feels like whether, you know, it's OpenStack work or some of the things that people are using Python for in,
like high-performance computing or big data analytics, machine learning.
There's just a lot of applications of Python.
And it just seems like for Intel as a company to not be kind of investing that and making it great on our processors,
it's just not a good idea.
So one of the things I love about this is that we're being agile with respect to how we invest in the software that's running on the data center on our processors.
And we're trying to, again, if our customers are using this stuff, we want to make sure that we have the best sort of, you know,
the best sort of experience for them.
So hopefully they'll come along and buy our processors on an ongoing basis.
Yeah, I hope so.
It sounds great.
So can you give me some idea of what, like, what are you studying in Python?
Are you looking at sort of the CPython implementation and how it's working and understanding how that's running on your chips and things like this?
Or what's the story there?
Yeah, yeah, yeah.
But our philosophy is, you know, it's kind of what I call the core software strategy, which basically says this.
It's like you can go off and, you know, work on speeding up some, you know, customer's application or some other, you know, kind of system.
You know, that's great.
But then, you know, at the end of the day, you know, you've optimized that one piece of software.
You haven't really, you know, optimized anybody else's Python code, right?
So, for example, let's take Swift.
It's an open source object storage subsystem that's part of OpenStack, and it's implemented in Python.
And if you look at that and you go, well, I could go work on the Swift source code, right, the Python source code to make it faster.
But then it'd be better if I could actually speed up Python instead, that core software.
And so, in theory, if I speed up Swift, I'll also speed up anything else that's using that accelerated Python, right?
So, the way we achieve that core software strategy is we've developed some really amazing abilities.
I mean, the engineers on the team have just done an amazing job to analyze exactly where the processor is spending its time as it's running, you know, major Python code, right?
So, we're actually able to go at a very deep level, and we had some really very interesting discoveries that we've made at the microarchitectural level.
And, you know, I can tell you more about that.
It's kind of interesting.
I mean, clearly, we see some things that are some challenges from a microarchitecture standpoint.
So, we go, well, if we're going to improve the performance, we need to do what we can to address those things with the current products and then give feedback to our chip architects to say, hey, man, you need to change the way that the chip is designed to run these languages better.
So, this is a – it's like a – not an either-or for us.
It's like a both-and.
Understanding the architecture at a deep level, we can go in and really speed up Python, and we can also go tell the chip architects to design better chips.
So – and along those lines, yeah, our philosophy is totally upstreaming all of these things.
And so, as much as possible, I sort of go – I mean, philosophically, I like to put the cookies on the low shelf so everyone can get at them.
As much as possible, I want to make sure that we don't just do some amazing sort of things and that we upstream them.
But then, you know, I want to make sure people know about them, right, so they can take advantage of them too.
And I want to make it – I want to be a contributor to the community so that they can, you know, take advantage of the hard work that we're doing as well.
Yeah, that's really excellent.
So, it manifests sort of in two ways.
You can improve CPython, and we're just getting started talking about the possibilities there, right?
And then, how dramatic of a change can you make at the chip level?
I mean, I think it's really cool that you're, like, thinking about, okay, well, here's our current architecture and the way things are working.
But when you run Python code, this could be better.
Would the chip actually detect what type of code it's running?
Like, does it work at that level?
Or are they just – you're like, these types of operations could be better?
Well, actually, our chip architects have a long practice of looking at how current software runs on current chips.
And we actually have some great tools to be able to analyze that at an instruction level that says, okay, you're running – oh, I don't know whether it's a database or whether it's, you know, Python or something else.
And you're able to analyze, you know, okay, here's the series of instructions that get run.
And then they can play a lot of interesting, you know, conceptual games with that and say, well, what if we added this instruction, a new instruction to optimize this thing?
Or what if we change the way the cache works to, you know, run this stuff better?
Or, you know, and, you know, we're actually – by having us involved with them, we're actually able to come up with some really interesting ideas and say, well, hey, maybe we could have this kind of, you know, acceleration
or this kind of idea about how to run these languages better, right?
So our hope is that, yeah, you know, and so the current chips are really designed from just years of running code, you know, of existing software against it.
And so, you know, some of it's making up for bad software practices, bad programming practice.
And it's like, oh, if people were to code this way, maybe if we organized the chip this way, it would run, you know, sort of poor code faster or something like that.
Not to say that anyone's code is crap.
I'm not saying that.
But there's a lot of crappy code that's out there, right?
Yeah.
I'm sure none of your listeners have bad code.
I'm sure they don't.
But if they listen to other podcasts, they may.
I'm just teasing.
I'm sure they're fixing other people's bad code, not their own.
But, I mean, you know, that's a key, you know, observation in terms of the chip.
Now, I couldn't necessarily go into a lot of ideas on the podcast, but we're working on a bunch of really intriguing ideas, in my opinion, about ways that we can really run this stuff much, much better.
I think it's cool to know that you guys out there are actually thinking about, you know, specifically studying these different runtimes like Python and Node.js and PHP and so on.
And understanding sort of how they're working and not working on your hardware and then adjusting for that.
When would the first sort of fruits of these labors show up?
You said in 2010 you got started with the Linux embedded stuff and then later you got into Python.
So how far down the road does this stuff land?
Yeah.
And by the way, the one thing I was going to add to your observation about the work that we do, we've actually been doing this work with Java now for, I think, 15 years.
And we have this nice little chart that we compare from generation to generation how much the chip speeds it up, but how much our software, you know, JVM's, you know, changes have accelerated in each of those generations.
And so we're just playing back the same playbook, basically, that we've been using for years with Java.
What I would say in terms of the fruits of our labor, actually, when we began the group, we had our first performance patches available to the community, I think, within about like three, four months or so.
And we're on the order of like a 10% performance boost.
And, you know, you think, well, 10%, that can't be great.
But, in fact, here's my experience with data center level code, whether it's, you know, massive database benchmarks like TPCC or this, you know, running Swift or some of these other big, big, big customer workloads on a data center.
If you can boost something, you know, 5% to 10%, you are just like, you are like golden.
That's like awesome.
It's very unusual to find a real customer benchmark that gets, you know, some multiple of, you know, many X speed.
It just doesn't happen, right?
And so, realistically, if you can improve the throughput by a few percent, usually people are pretty happy about that.
So, we came up with our first patches.
Yeah, I'm pretty sure it was about three, four months after we started analyzing things and look at some low-hanging fruit of places where we could pull in some stuff pretty quickly and get the experience with the community, you know, talking with Guido, talking with other community developers to try and really, you know, hone our, you know, our efforts there.
And the first time we kind of took a look at PyPy, that's when we said, well, shoot, maybe we could get a much, much higher, you know, return with PyPy.
Maybe we could get a whole lot more than just a few percent here and there.
So, that became extraordinarily interesting.
Thank you.
Yeah, that's awesome.
And that's kind of what I was hinting at, like we're just getting started.
So, the majority of people who run Python code, they run it on CPython.
That's the default thing you get if you go to python.org and you download it.
But there are many other runtimes or implementations.
The most popular one around performance is probably one called PyPy, P-Y-P-Y.
But we also have PyStin coming out of Dropbox and Guido's group there.
We've got Psython, Jython, IronPython.
There's a lot of options.
And so, you turn to the probably one of the more established high-performance alternatives to CPython, PyPy, right?
That's correct.
And, you know, for us, it's like I didn't want to be married to anything until we really got a chance to see, you know, kind of what was going on in the landscape.
I mean, we looked at all of these, frankly.
And they all have their pros and cons.
I mean, things like Psython, et cetera, you know, basically creating C code.
That's a nice model for performance.
The challenge is that kind of takes away some of the, you know, development speed you get from an actual interpreted language.
You know, and PyPy for it, and Pidgin and Piston have interesting qualities.
I don't, you know, the thing that I like about PyPy is as follows.
I mean, for one thing, it's been around 10 years, right?
So, it's got, as far as I can tell, the broadest compatibility of any of these efforts.
It's focused on both Python 2 and Python 3.
I think that, you know, it really hasn't received a ton of, you know, broad sort of help from folks, you know, like these performance guys that I work with here at Intel.
I mean, I think they've done an amazing job, absolutely amazing, stunning.
I am incredibly impressed.
We had a great sprint with them, you know, basically in March of this year, and face-to-face effort with their core developers, and it was just really very, very effective.
And then there was another release of PyPy that came out as a result of the sprint.
You know, so I think we're just getting started working with it.
The results have been nothing short of stunning.
I mean, this is what really impressed me because, like I said, we're working with Swift because it's a part of OpenStack.
We're doing a lot of stuff with OpenStack at Intel.
You know, Swift is the part of OpenStack that seems to spend a lot of its time in Python.
As we analyzed it, 70% of the cycles, 70%, 80% of the cycles when you're running Swift is actually in the Python interpreter itself.
So, it's like, oh, there's a lot of opportunity there.
Then we look at, we split that down further, and it's like really being, you know, like 30% of those cycles are just in the main interpreter loop of CPython.
So, we said, well, let's try PyPy, as you said, P-Y-P-Y, and it's incredible.
We got 111% throughput improvement.
Now, pause for a second and say, okay, I was looking at a few percent here and there, and here I've gotten more than double the throughput of using PyPy, right?
It's like compared to CPython, amazing.
And then it's like an 87% response time improvement.
And it's like if something's like a software system, I mean, throughput's great because, right, you can scale up more and more users and you get, you know, great throughput.
But the response time is what people really respond to, right?
I mean, this is like it means they're accessing files, whether you're like, for example, Wikipedia, all of the, you know, sort of images that people look at in Wikipedia are all managed by Swift, right?
So, you can look at something like that, and that just brings up your Wikipedia pages faster.
And I've talked to various customers who are using Swift for their, you know, object storage system.
And, yeah, this is a huge deal when you get that kind of improvement.
So, it's like, well, with such amazing, you know, speedups, why wouldn't we try to, you know, see if we can, you know, provide a little, you know, love to the project to see if we can, you know, really do it, you know, continue to make this maybe even the default of how people use Python.
Okay, yeah, that's really amazing.
Do you know if you can run all of OpenStack on PyPy?
Yeah, we're actually in the process of getting that together.
We have, let's see, so far Swift, Keystone, Nova, and Neutron ported.
And I would, you know, I would say trying to get like a proof of concept where we have all the core services running in PyPy.
And I'd like us to really be able to do that maybe before the next OpenStack Summit in the fall in Barcelona.
So, I'm hoping that we'll be able to show that off.
Keystone, I said, is another interesting service that's written in Python.
Keystone, if you're not familiar with it, is the user authentication part of OpenStack.
So, essentially, every OpenStack service has to go through Keystone to see if you're authorized to do the things you're saying you want to do, right?
And so, it's a really, you know, centralized part of the project.
And we were able to speed it up by 37% using PyPy.
So, that's, again, pretty darn amazing.
So, I think I'd like to see the entire, yeah, I'd like to see PyPy as the default.
In fact, years ago, the OpenStack gate had a requirement that everything had to work with PyPy.
And a year or so ago, that got dropped.
And I'd like to bring that back.
And, if possible, try and drive, you know, something that would have the whole, you know, community basically making use of PyPy within OpenStack.
Yeah.
Yeah, that's really cool.
If you're running something like OpenStack, you're running on a lot of machines.
And efficiency is going to make a big difference in that type of system, right?
Absolutely.
And, you know, if you think about this, in some respect, it's not kind of radical.
Every other interpreted language, whether it's Java, JavaScript, PHP, you name it, Lua, they have all gone the direction of a JIT in order to improve performance.
And here, let me tell you how this works, right?
If you've got two, let's say you're adding two integers together, right, in Python.
Very simple operation.
You know, if you're running native code on our processors, right, there's one instruction that adds two integers together, right?
In some cases, it can be even less than one instruction with opcode fusing some features that we have.
With Python, CPython in particular, we did a measurement and showed that on average, it takes 76 instructions to add two integers together, right?
So automatically, you can see a stunning difference.
And, you know, we've got great processors.
They run instructions very fast.
But you're running one instruction versus 76 is definitely going to be faster.
That's a very hard thing to compensate for.
Yeah.
So as a result, you know, the processor spends a lot of it because the code footprint is just huge on something like Python.
And so, you know, you spend a lot of the processor spends a lot of its time.
We talk about it being cycles stalled in the front end.
And what that basically means is the first two stages.
If you think about it, I'm sorry to, let me just mention this briefly.
I won't geek out on this too much.
But it's like if you think about the five-stage pipeline for a processor, a modern processor, you get best performance if you can get all the stages of the pipeline running in parallel, right?
The problem is our processors are spending like half of their time twiddling their thumbs waiting for new instructions to get fetched and decoded.
So if we can, you know, make a huge difference to that, and a lot of it, frankly, comes down to simply the size of the instructions, the size of the code footprint that we're trying to process, right?
And so JIT directly addresses that because what a JIT is going to do is it's going to look at the hot interpreted, you know, code and generate native code, right?
So instead of that 76 instruction for an ad, if it's a hot ad, it will basically run in one instruction because it will be running native code instead.
So this is not a huge secret.
It's not magical.
It's something that is a really, you know, well-worn technique to make this happen.
And I'm telling you, every other language has gone this direction.
And as I've, you know, as Guido and I have talked about this as well, he's like, you know, he's, you know, supportive.
He's like, he says, I don't have a dog in the fight.
You know, he's basically, he's more, I think, interested in the advances of the language as opposed to these performance things.
Usually he's not thinking in terms of the performance side.
But I'm, you know, I'm thinking about the performance side.
I said, hey, could we really help the overall project by, you know, having a, you know, a great interpreter for Python that really runs really super fast?
By the way, they're able to achieve greater performance by several other things in terms of the garbage collection that they're able to do.
In various ways, they have much lower memory footprint as well.
And so this is something that several of these techniques they're able to use to get really stunning performance.
Yeah, the PyPy guys are doing a great job.
And they definitely do some interesting stuff.
I talked to them on episode 21.
One of the things that I thought was interesting is the way that they don't immediately JIT everything, but they kind of wait until they find a hotspot.
And then they go and JIT that.
Right.
That's, again, a well-worn technique that has a ton of fruit in the Java space, as an example.
Right.
They even called their JIT a hotspot is what it's called.
Right.
So this is a common technique, and I think it works really well.
Yeah.
I think the challenges that you run into is languages like Python, they're so flexible and you can change the types so much that it's not as easy as JIT in something like Java.
Right.
Oh, yeah.
And particularly when, you know, because it's one of the really attractive things about the language is how, you know, flexible it can be in terms of typing.
You don't have to spend a lot of time, you know, coming up with the types and documenting all those things.
And so, you know, coding that is Pythonic, it really has that, you know, kind of power and flexibility.
Unfortunately, that power and flexibility also comes with a cost and typically, you know, means that you have to spend a lot of code trying to figure out, now, what is the type of this thing?
And did it change since the last time I looked at it?
Right.
So that's a strong consideration when trying to run this stuff fast.
Yeah.
I think there's a lot of attention being given to speed and Python lately.
I've noticed a big uptick in projects and people focused on trying to make Python faster, be that through PyPy or the Microsoft Pigeon or I just spoke to the Euphoria guys about distributed, compiled Python.
There's a whole bunch of really interesting things.
And they're not all mutually exclusive.
I think they're going to come together and some pretty amazing stuff is going to come out of it.
Yeah, I agree with you.
I think that one of the strengths of the Python community is the fact that you do have a lot of freedom for innovation.
And, you know, the uptick in performance projects, I've noticed that as well.
I think part of that's just because it has become so well adopted that I think if they don't solve the performance thing, you know, I think people will sort of get frustrated and go on to other things.
You know, for example, in the high-performance computing space, you have people who are scientists and, you know, people studying data and things of that sort as opposed to being programmers, right?
And they love Python because they can, you know, implement their code using Python.
But then they go, well, this is performing slowly, so, you know, let me recode it in something else, right?
And I think our vision would be that people don't have to, you know, change their language to get better performance.
I'd love it to be a no-compromises, you know, experience with Python, right?
And then we can bring to bear the best of our, you know, microarchitectural analysis tools, software optimization tools, and, frankly, analysis tools as well.
We've got a terrific visual profiler called VTune that lets you, you know, pinpoint the exact area in your Python code that is, you know, causing your problems, performance problems.
We also have, you know, a set of Python libraries that are, particularly if you're using NumPy, SciPy, Pandas, SciKit Learn, a variety of those packages.
We have an accelerated version of those as well in a Python product.
So there's a lot of, you know, but our common vision, you know, goes end-to-end in that sort of thing, whether it's the upstream stuff that we're doing or the Python product.
We just want to make sure that the experience people have with Python is no compromises relative to performance.
Yeah, that's great.
And I want to talk about the NumPy, the data science stuff in a moment.
This portion of Talk Python to me is brought to you by Metis, offering data science training in New York City, Chicago, San Francisco, and online.
Led by a deep team of senior data scientists, Metis delivers immersive boot camps, corporate workshops, online training, and part-time professional development courses in data visualization, machine learning, big data, and other data science skills.
Their full-time boot camp is the only accredited data science boot camp available and includes extensive career support.
Metis maintains a busy event schedule, so be sure to check them out on Meetup and keep in touch via at ThisIsMetis on Twitter and learn more about them on the web at ThisIsMetis.com.
So you said that you had worked with the PyPy guys and you actually got them together to do a sprint with some people on your team.
Is that what the story is?
Yeah, that's right.
Yeah, it turns out that all of the core PyPy developers are in Europe, except for Maciek, who's in South Africa.
And I have a staff of developers working on Python that are in Europe.
And so we brought everybody together.
It turns out it's in Bucharest, Romania.
And so we got everybody together physically in the same room.
There were actually a couple of folks from the academic world, a couple of universities that wanted to come in and, you know, work.
Once I got wind of this happening, they said, man, we want to get involved in this, too.
So, you know, it was a very effective sprint and great to get that teamwork going.
I feel like we now have a great understanding not only of, you know, PyPy, but also the microarchitectural tools that we have to analyze performance and things of that sort.
So we can now turn this thing, I think, into a really powerful kind of collaboration with the PyPy project.
Oh, that's great.
And I think that's really great that you were able to help get everyone together because that's one of the real big challenges of these open source projects that are somewhat large is just physically getting the people together.
So there might be people on projects that have never met before, right?
Absolutely.
And, you know, I tell you, I've been working in specifically open source projects since like the mid-2000s.
And it's true that, you know, open source would never have been, you know, wildly successful without the Internet.
But trust me, when you can get people physically face-to-face, you can get human-to-human contact in a physical, you know, same physical space, you eliminate a lot of inefficiencies and barriers and you get a lot of progress very quickly.
And so as far as I'm concerned, that's a worthwhile sort of investment to get the smart people together in a room and work on real problems and produce code as a result.
Yeah, even just getting to know people for a long weekend.
That can last like a whole year's worth of goodwill from that, right?
Absolutely.
No question.
Yeah, great.
So that's a huge commitment back to the PyPy group and all of that is open source, of course.
Have you done anything where you've taken some of this work and research and gotten it back into CPython?
Yeah, we're trying to be not an either or for me, at least.
It's like there's still, you know, adoption of PyPy is currently not very high.
A lot more people are running code on CPython.
So it's not like an either or for me.
It's more like a both and.
And the same thing goes for Python 2 versus Python 3.
I mean, even though Python 3 is the place where Guido and the rest of the community, the development community, would like everybody just to be doing things on Python 3, reality is core services and OpenStack, a lot of other code is still in Python 2.
So that's our commitment to the community is as we do performance work, we're doing it for both Python 2 and Python 3.
And we're really trying to pull off a thing where we can do CPython and PyPy as well.
So, you know, we have, I think there's some chemical issues that we can, like I said, give a little bit of love to in terms of making it much easier to use PyPy in many of these circumstances.
So there's some engineering work along those lines as well that we're trying to invest in also to eliminate if there are any deployment issues or any issues with, you know, with the garbage collector or something like that.
So we're really trying to, you know, really eliminate those.
And there is a class of code that is challenged partly because PyPy is so fast.
You know, this is the amazing thing to me is that we've encountered a couple of places where, you know, people have coded a timeout in Python.
And, you know, the code wasn't exactly correct.
And so when you switch to PyPy, which is multiple times faster, right, suddenly these timeouts fail because, you know, the code, you know, isn't exactly correct.
Now, it's not necessarily something I can fix in PyPy.
I mean, I'd love to figure that out somehow, but I'm not sure that's going to be possible.
But, you know, we've seen this now in a couple of very interesting instances where people, you know, write their code.
And, you know, it's, you know, suddenly when you speed it up a lot, it breaks because it made some assumptions about how slow it should be running.
It got to the weight too quickly, huh?
It's an odd problem to have.
But, you know, that is, frankly, when you're going to do a drastic improvement in performance, you may find an issue like that that pops up.
So in any case, that's something we've seen a little bit of.
But hopefully people can fix their code because I think that's probably a good thing, right?
Yeah, absolutely.
That's obviously the fix.
Like, hey, let's just not wait so long.
Anyway, so it sounds to me like you have this multi-pronged approach.
You're trying to make the processors faster by understanding how they run Python code, trying to make CPython faster, trying to make PyPy faster.
Another one of the prongs on making things faster or addressing this Python performance story is around something you call the Intel distribution for Python.
And you kind of hinted at that before, right?
What's the story there?
Yeah, and this is, again, we have sort of two-pronged strategy here.
One strategy says let's do, you know, everything upstream in open source.
And the other is, is there some way we can kind of pinpoint some of the key pinch points that people have?
And then it may be that we have some code, you know, internally that will accelerate those things.
So, you know, in particular when you're running, you know, math functions, this is something that in the evolution of people's Python code, right?
They write these things initially in Python, and then it's like, wow, this is kind of a performance pinch point.
Is there something we can kind of do to improve it?
So a lot of times people recode these things in C, and it's like, okay, and NumPy is a great example of that, right?
So what we've actually been able to do is say, gee, we have this library here.
It's called MKL.
It's called our math kernel libraries, right?
Where some incredibly smart people have gone at the deepest possible level to have math functions and execute them just as fast as possible, right?
So they're highly tuned, very, you know, very, very bespoke sort of code, right?
So, you know, what they've done is done an amazing job hooking up MKL with NumPy, SciPy, and these other popular libraries.
And so that's code that they actually call the Intel Python distribution or Intel distribution.
I might have the name wrong, but it's actually in beta now as we're talking, and so that should be something,
some get in on the beta program, or if they're listening to this at a later time, they may, in fact, be already released.
So that's another, I think, great alternative, particularly if you're using those scientific libraries to basically make use of that
and see, you know, if that's going to improve things.
In some cases, I think they found some code that's, you know, again, it can multithread some of these operations,
whereas with, you know, regular Python, it's more or less single-threaded.
And so with multithreading, depending on how many cores you can throw at it,
they've seen up to 100x on some math functions that they've been able to speed up.
So that's pretty stunning.
There's also some data analytics functions that are part of this, and so I think that's a really intriguing option as well.
Yeah, that does sound intriguing.
And it sounds to me like what you're actually targeting there is you're targeting the C extensions
or the C foundations of some of these heavily C-sped-up libraries.
Yeah, that's exactly right.
It's a strategy that, again, is like we don't want to have people make a choice between, well, do I want to stick with Python
or do I want good performance, right?
We want to be able to make it so that it's a no-compromise situation.
So, frankly, this is another alternative that lets us, you know, target, you know, some users that really want super high performance
in this mathematical area.
And high-performance computing is another area that we've invested in pretty heavily here.
So this is a way to, you know, get directly into that space and help them out.
Yeah, and I guess you guys probably understand better than anybody how to exactly line up the math to work on your processors, right?
Yeah, we really have some amazing tools and analytics to do.
Yeah, when you sit next to the guys designing the chips, it's usually, you know, much easier to be able to squeeze out that last little bit of performance in any possible case.
Yeah, yeah.
Sounds great.
I'll be sure to link to that in the show notes.
So one of the things that we talked about last week is you were actually at the OpenStack conference, right?
Maybe you can give us a...
That's correct.
OpenStack Summit.
Yeah.
Awesome.
Give us a rundown on what happened there.
Yeah.
This is really exciting because the OpenStack Summit is, you know, every six months.
This one was in Austin, Texas.
And what was interesting about this is that OpenStack as a project is going through a lot of really interesting evolution as cloud computing obviously takes over the kind of the fastest growing segment of the data center kind of area, right?
So software-defined infrastructure is incredibly important.
And something like 70% of OpenStack is actually written in Python.
So one of the things that we did was jointly with the project technical leader, or PTL, of Swift, he and I have been collaborating together on PyPy,
and we were able to jointly present our performance results and showing, hey, here's the effect performance-wise of using PyPy with Swift.
And again, I think I mentioned the statistics earlier.
It's like more than double the throughput, right?
We have data which shows that we can, you know, get 111% throughput improvement and 87% response time improvement.
You know, that's stuff that we've seen.
The PTL, John Dickinson, works for a company called SwiftStack.
And in their product sort of environment, they have a Swift-based product family.
And so, yeah, they were able to see, you know, similar results.
And so jointly we were able to present this.
And people were very excited about this.
The response was extremely positive, partly because of the opportunity to see the collaboration go on.
You know, anytime you go in with open source and you can collaborate and talk about how we're working together to make people's lives better,
I think it's all good, right?
So that was – but what was funny is I've got to tell you a story.
When I landed in Austin, so I get to my hotel that I'm staying at for this conference,
and I'm walking over to the conference venue to get my conference badge.
The first person I see on the street, I'm sad to say I didn't recognize him,
but he recognized me and he said, oh, it's Mr. PyPy.
Somehow, then I found out, okay, why have you recognized me?
Anyway, so it's – I think the word's kind of getting out that this is something that, you know,
we see some real value in.
We'd like to try and help people out through advancing it a little bit.
Yeah.
Yeah, you must be being effective if you're getting recognized on the street as Mr. PyPy.
That's awesome.
My usual comment is a good reputation takes a long time to build, but a bad reputation is instantaneous.
So, you know, I think we'll – you know, hopefully we can keep it to be a good reputation as opposed to a bad one.
Yeah, absolutely.
Okay, well, that sounds really interesting.
That's great you were able to share your results with everyone.
Another thing that you said that was pretty interesting, sort of completely unrelated to this,
but you've been talking about how the Python community is a really welcoming community.
And I can tell you from doing training and speaking at conferences that are not just Python conferences
but have many languages and technologies that when I do Python talks,
the group of people in the room are more representative of the group of people out in society,
which is really great.
Well, I totally agree with you.
I think it's amazing to see, particularly because I've spent a number of years in other open source projects.
And so I know at sometimes a painful level how challenging it can be for some people who are not males in particular.
And this is one of the cases where I don't want to point to particular projects or something like that,
but I've been involved in a number of projects.
And it's hard sometimes to find projects that not only have great diversity but inclusion as well.
And so one of the things that's been very impressive to me,
the first Python conference I went to actually was EuroPython.
And Guido made a – actually it was before Guido came on as a keynote speaker.
The very first keynote of the project, of the conference,
was a conference given by the founders of Django Girls.
And it's two female engineers.
And Django Girls was set up by then as a nonprofit to basically have women teach other women how to code in Python, right?
And it was a great keynote.
I mean they actually did a bunch of it as like a fable, you know, kind of talking about –
essentially talking about how challenging it is for, you know,
women to really be considered part of the community, right, of any sort of community.
And so Django Girls, what's amazing is they started up with pretty much nothing.
And after the first year, they had had 100 workshops all over the world.
Again, women teaching women how to program in Python, right?
And this was incredibly impressive.
I mean Guido actually in his keynote, he – you know, I think he's part of the reason.
It's like this.
I think he's very committed.
He was wearing a PyLadies T-shirt in the conference.
PyLadies is another, you know, part of the Python community that works really well to help encourage women be involved in Python.
He – in his keynote, he said – most of it was Q&A from the audience.
And he said, let's alternate a man and a woman asking questions, right?
So he made it super clear that that's a priority for him.
And I asked him about it.
Is that, you know, something that he – it's important to him?
He said, yeah, absolutely.
And so he's making a difference.
He's putting his own, you know, kind of stamp behind that.
And I might – on a personal basis, I had – you know, my daughter is – one of my daughters is 24 and she's still trying to find kind of her career direction.
And she said, Dad, you know, if I wanted to learn programming, you know, what would you suggest?
And I said, well, I think you should try Python.
And I said, in fact, you know, you ought to check out this Django Girls thing to see if there's a workshop.
Well, it turned out, you know, we live in the Portland area.
There was a Django Girls workshop in another, like, six weeks.
And I said, oh, look, you could get involved in that.
And she submitted an application, explained, you know, what she'd be using her knowledge for and how – you know, why she wanted to learn it.
They accepted her in the workshop.
And, you know, she was a little nervous.
She said, gee, I'm not sure I'm smart enough to actually, you know, do well with this, right?
And I said, no, no, no.
You know, and I understand sometimes people can feel that way.
Typically, they've been made to feel not smart, which, you know, I try and do everything I can with my daughters to make them feel like they're – you know, they're both brilliant.
They have no worry about that.
But sometimes the environment is one that wants to, you know, make people who are, you know, women not necessarily feel very smart.
And so I said, you know, I encouraged her.
She went through the workshop.
She was very successful with it.
And I'm hoping, you know, fingers crossed that it would be something she'd be able to, you know, make a living doing if she digs it.
So, yeah, I love the fact that Django Girls is – you know, has this available.
And it's, again, part of – I think a core part of the Python community.
I think it's one of the things that makes it a very attractive community is how important it is for the community to – for women to help, you know, other women.
And for the entire community to have better inclusion.
Now, is it perfect?
No.
I think there's some challenges still.
I interviewed one of the – a fellow of the Python Foundation.
Her name is Terry Oda.
And I talked to Terry and I said – I asked her how it is from her perspective as a woman.
I mean, it's one thing for me as a male to say, gee, this seems really good.
Well, how about a perspective of a woman?
And she's part of the, you know, the Intel – or, sorry, the Python Foundation.
She's also an Intel employee.
And she said, yeah, you know, she said that it's a good environment.
It has the – you know, it could do better in terms of having more core developers who are women.
And so there's more, you know, work that can be done to, you know, get more of that inclusion and diversity within, you know, sort of the core development community.
But it is a great project for its diversity and inclusion.
Yeah, that's cool.
I think the Python community is more welcoming than most.
And I think this is just, you know, more evidence of it.
So that's cool.
Hopefully we can inspire some more people to go out and check out some of these projects that are out there and freely available.
Very cool.
I agree, yeah.
So getting near the end of the show, let me ask you a couple of questions that I always ask my guests while I still have you.
If you're going to write some Python code, what editor do you open up?
Oh, yeah.
I'm an old VI guy.
So, you know, with my roots back in Linux and back in the old days, or Unix, you know, before there was a Linux.
So, yes, when I edit, I use VI.
Okay, excellent.
Yeah, that's definitely a popular one.
And of all the PyPI packages, you can include Intel ones if you want, there's a ton of them.
And nobody could possibly know about them all.
There's, you know, close to 80,000, maybe over.
I haven't looked in a while.
What ones do you like that maybe you'd recommend people check out that are not necessarily the most popular?
I'd ask the question, though, what's my favorite interpreter?
My favorite interpreter for Python these days is definitely PyPy.
Yeah, okay.
That's great.
It's a very meta answer, right?
Like, it's PyPy that runs all the packages.
I'm not a politician.
I don't even get paid to be a politician.
But sometimes I know how to, you know, reframe the question.
Yeah, absolutely.
Okay, so do you have a final call to action for listeners, things they should do or check out?
Yeah, I would absolutely have people take another look at PyPy.
You probably have in the past.
In particular, we would love to have people check out, if you're using, you know, OpenStack or Swift,
we would love to get people to, you know, check it out with the latest version of PyPy
and really try to give us some feedback in the Swift community or in the Python dev community.
We monitor Python dev.
And if you have some observations about PyPy that would be helpful, saying, you know, for example,
if you have some Python code and if you either find you have some, you know, challenges with it,
we would love to hear that because one of the things we'd love to do is I've got engineers I can, you know,
try and ask to, you know, basically say, hey, let's go solve these.
I've given the call to action to our engineers to say, try and, you know, resolve these,
any sort of compatibility issues or other deployment issues and let's make, you know,
try and make this a great experience for people.
So if you can help us out in terms of, you know, get your hands on PyPy, try it against your Python code
and give us feedback in terms of what might be missing or could work better, we would love to hear that
and we'd love to dialogue with you on it.
Okay.
So absolutely try your code on PyPy and send these guys some feedback.
That's great.
All right, David, it's been a super interesting conversation.
I'm really excited to see the work that you're doing appear in the Intel chips going forward
and in both the runtimes in CPython and PyPy.
Thank you, Michael.
I love talking about this stuff.
I'm incredibly passionate about it and I'd love to, you know,
I'd see our love for technology be able to be made use for a lot of people.
So I'm hopeful that people will get excited about this stuff as a result too.
Yeah, absolutely.
Thanks for being on the show.
Talk to you later.
Thank you.
Snap.CI is effective in deep training for data scientists.
Metis is effective in deep training for data scientists.
With immersive boot camps, in-person and online courses,
you can learn the core data science skills you need to take your career to the next level.
Are you or a colleague trying to learn Python?
Have you tried books and videos that just left you bored by covering topics point by point?
Well, check out my online Python course called Python Jumpstart by Building 10 Apps at
talkpython.fm/course to experience a more engaging way to learn Python.
You can find the links from this episode at talkpython.fm/episodes slash show slash 57.
And be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes,
Google Play feed at /play,
and direct RSS feed at /rss on talkpython.fm.
And there's been a few requests for the Ogthera format,
a more open format than MP3.
And I added that link as well in the footer of the website.
Our theme music is Developers, Developers, Developers by Corey Smith,
who goes by Smix.
You can hear the entire song on talkpython.fm/music.
This is your host, Michael Kennedy.
Thank you so much for listening.
Smix takes us out of here.
Stating with my voice, there's no norm that I can feel within.
Haven't been sleeping, I've been using lots of rest.
I'll pass the mic back to who rocked his best.
First developers.
First of all, first of all, first of all, first of all.
Thank you.