5 ms·

Key takeaway: "the [speed] difficulties come from Python's extremely rich object model, not from anything about its dynamic scopes or dynamic types. The proble

by mhneu 10y ago

Key takeaway: "the [speed] difficulties come from Python's extremely rich object model, not from anything about its dynamic scopes or dynamic types. The problem is that every operation in Python will typically have multiple points at which the user can override the behavior, and these features are used, often very extensively." Also, Kevin and Pyston's team are too modest to state this directly in this article: They made good and steady progress, but it's taken them a long time. A lot of that time was spent making them experts on Python runtime and Python JIT options. With several more years of fulltime work we could have a JIT that we all use instead of CPython. Pyston showed that certain features of Python make it slow and difficult to JIT. The best case scenario for Python's future would have been for Kevin and Pyston to work with the Python core team to decide how to tweak language features for speed (perhaps marking certain object modifications as being "slow" in the same way rust has an "unsafe" marker). With Pyston shutting down, I think the horse of python speedups is out of the barn and is never coming back. More discussion: https://news.ycombinator.com/item?id=13534992 https://news.ycombinator.com/item?id=13534992

mhneu 10y ago
One other key takeaway from the comments on Kevin's blog: "Hi John, I share some of your disappointment in the outcome [ed: Dropbox switching hot Python paths to Go], but at the end of the day I’m an engineer because I want to make an impact as opposed to just working on interesting problems, and I think the Pyston decision reflects that [ed: the cost-benefit of future time invested vs amount of speedup we might gain is not good]. I think there are some other areas of Python performance that are very important, perhaps in the numerical computing space, and I’m currently taking a look at that. Who knows how this will all work out!" One personal comment: I still think that with two dedicated full-time engineers with the experience the Pyston guys have, some syntax tweaks could be proposed that make python more efficient. That would require working with the Python core team, which is sort of a bear given the amount of effort and time required for PEP 3118 and PEP 523. Which gets back to the question of making an impact.
tbrowbdidnso 10y ago
I don't get why it seems like languages are designed for convenience then later down the road billions of hours are spent trying to get better performance. I have seen this happen over and over with PHP, Ruby, js, and now Python. The best solution is to stop using a slow language for these types of applications. Personally I don't see a point to investing so much in these projects, since all it does is encourage developers to continue their bad behavior. "Oh don't worry about it, they're working on a JIT if performance is ever an issue" -- lead dev deciding to write something that is expected to handle 10k transactions per second a few years later in Python. If performance is ever going to be important just use a high performance language and be done with it. Then you don't have to spend years and millions reinventing the wheel like Facebook did with PHP.
- kibwen 10y ago
  > I don't get why it seems like languages are designed for convenience then later down the road billions of hours are spent trying to get better performance. It's easy to explain. 1. Most languages are designed for personal satisfaction of the author, not for commercial success. Perl, PHP, and Ruby were all just personal projects. Python was a language intended for education, then pivoted towards Perl's niche in the 90s. 2. The vast majority of languages that are designed will fail and be abandoned without anyone having ever heard of them. 3. Designing a pretty and elegant language is hard, but fun. You don't even need to implement it. 4. Designing a language that is deliberately amenable to optimization is also hard, but not fun (especially when optimization has to be prioritized over elegance). It's also hard to prove that your design actually yields good performance, which is hard and not fun. Furthermore, the only point of designing such a language is to hope to someday fully implement it, which is very hard and extremely not fun. And hoping to implement such a high-performance language in a cross-platform way is, for any single person, basically impossible. The modern resurgence of high-performance languages like Rust is because, thanks to retargetable backends like LLVM, the idea of a hobbyist designing a new high-performance cross-platform language has gone from "basically impossible" to "unbelievably tedious though possible but also on some level your language has to basically pretend that it's still C". And also the consolidation of platforms for the past few decades now mean that there's fewer targets to support in the first place, and hence fewer C compilers than ever, so if you just want to transpile directly to C you can, though you'll still spend the rest of your life adding hacks to your compiler to work around bugs in every combination of platform/C compiler/C compiler version out there.
x0x0 10y ago
I'd be curious if someone could share some examples. My poor understanding of Kevin's claim is that, essentially, python is too dynamic, particularly in the core library. It seems like the approach to that is devirtualization, perhaps something along the lines of Julia. But Kevin also points out that using llvm was a failure for the pyston project. If anyone fills in some of the blanks, thank you in advance.

by mhneu 10y ago

mhneu 10y ago

One other key takeaway from the comments on Kevin's blog: "Hi John, I share some of your disappointment in the outcome [ed: Dropbox switching hot Python paths to Go], but at the end of the day I’m an engineer because I want to make an impact as opposed to just working on interesting problems, and I think the Pyston decision reflects that [ed: the cost-benefit of future time invested vs amount of speedup we might gain is not good]. I think there are some other areas of Python performance that are very important, perhaps in the numerical computing space, and I’m currently taking a look at that. Who knows how this will all work out!" One personal comment: I still think that with two dedicated full-time engineers with the experience the Pyston guys have, some syntax tweaks could be proposed that make python more efficient. That would require working with the Python core team, which is sort of a bear given the amount of effort and time required for PEP 3118 and PEP 523. Which gets back to the question of making an impact.

tbrowbdidnso 10y ago

I don't get why it seems like languages are designed for convenience then later down the road billions of hours are spent trying to get better performance. I have seen this happen over and over with PHP, Ruby, js, and now Python. The best solution is to stop using a slow language for these types of applications. Personally I don't see a point to investing so much in these projects, since all it does is encourage developers to continue their bad behavior. "Oh don't worry about it, they're working on a JIT if performance is ever an issue" -- lead dev deciding to write something that is expected to handle 10k transactions per second a few years later in Python. If performance is ever going to be important just use a high performance language and be done with it. Then you don't have to spend years and millions reinventing the wheel like Facebook did with PHP.

kibwen 10y ago
> I don't get why it seems like languages are designed for convenience then later down the road billions of hours are spent trying to get better performance. It's easy to explain. 1. Most languages are designed for personal satisfaction of the author, not for commercial success. Perl, PHP, and Ruby were all just personal projects. Python was a language intended for education, then pivoted towards Perl's niche in the 90s. 2. The vast majority of languages that are designed will fail and be abandoned without anyone having ever heard of them. 3. Designing a pretty and elegant language is hard, but fun. You don't even need to implement it. 4. Designing a language that is deliberately amenable to optimization is also hard, but not fun (especially when optimization has to be prioritized over elegance). It's also hard to prove that your design actually yields good performance, which is hard and not fun. Furthermore, the only point of designing such a language is to hope to someday fully implement it, which is very hard and extremely not fun. And hoping to implement such a high-performance language in a cross-platform way is, for any single person, basically impossible. The modern resurgence of high-performance languages like Rust is because, thanks to retargetable backends like LLVM, the idea of a hobbyist designing a new high-performance cross-platform language has gone from "basically impossible" to "unbelievably tedious though possible but also on some level your language has to basically pretend that it's still C". And also the consolidation of platforms for the past few decades now mean that there's fewer targets to support in the first place, and hence fewer C compilers than ever, so if you just want to transpile directly to C you can, though you'll still spend the rest of your life adding hacks to your compiler to work around bugs in every combination of platform/C compiler/C compiler version out there.

x0x0 10y ago

I'd be curious if someone could share some examples. My poor understanding of Kevin's claim is that, essentially, python is too dynamic, particularly in the core library. It seems like the approach to that is devirtualization, perhaps something along the lines of Julia. But Kevin also points out that using llvm was a failure for the pyston project. If anyone fills in some of the blanks, thank you in advance.