Personal thoughts about Pyston's outcome
blog.kevmod.com
blog.kevmod.com
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
"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.
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.
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.
The parts that make Python slow make it easier to hack on, but they don't make it elegant in any meaningful sense.
> Designing a language that is deliberately amenable to optimization is also hard, but not fun (especially when optimization has to be prioritized over elegance).
Elegant languages are usually amenable to being efficiently implemented without the implementor having to do anything special. That's because elegant languages guide you towards using the simplest, least powerful features that are powerful enough to solve your problem. For example, in Standard ML, I don't use higher-order functions that much, not because they suck (they don't), but rather because first-order functions and functors (which can't be recursive) are powerful enough for most things I want to do.
On the other hand, in a language like Python, it can be very difficult to find features that solve exactly your problem and nothing more, so often you have to reach for super-powerful hammers (operator overloading, metaprogramming, etc.). These hammers are almost invariably more general than the intrinsic demands of your problem, but, since the language designer can't provide an implementation that only works for your use cases, you must pay the price of the unnecessary generality of the feature.
Why start writing something in one of those languages? They have high-quality frameworks that make it quite easy to ship early and ship fast: the vast majority of web-based startups fail, or at most stagnate with at most tens of thousands of users, and for them the performance of the common interpreters is fine. If we want to see a phase shift away from them, we need frameworks that allow quick prototyping written in languages which are more easily optimised (and, honestly, JavaScript really isn't bad in terms of writing a JITing compiler).
The irony is that the companies investing the most money into eventual JIT/compilation are the same ones that wrote code believing it would "come around" one day.
The only way to stop the madness is to avoid using these languages for high performance code in the first place.
Having used many fast/slow languages over the years I'll say I don't really notice any increase in productivity one way or another, and no difference in the richness of the library ecosystem.
Are there any studies that show more dynamic languages are more productive? Usually the argument is made that the more abstracted the language is from hardware the better it is to work in, but I don't notice a productivity difference in C#/Java vs Python/perl
To take FB as an example: AFAIK, it was written in PHP because Zuckerberg knew PHP. There was no expectation it would "come around" and it continued to be in PHP because bills had to be paid and rewriting everything would stop new features from being launched and hopefully reach profitability.
If you're a small startup your first goal is almost always to hit profitability, and then your goal is almost always to maintain that. As a result, language choices are frequently made by what founders know rather than any technical merit.
1. There exist massive existing codebases in these languages, and simply the cost of a rewrite, retraining all of the engineers, and building new tooling is more expensive than making these languages run fast. In the case of V8, the cost for Google was to convince the entire web not to use V8.
2. These languages are in fact, the best tool for the job. The semantics of the language are the best tool for the job, and writing in another language is going to slow down the team (in the long run) more than making the language faster.
3. Opportunity cost is key when starting. I've seen this first hand with C* vs. Riak, and K8s vs. Mesos -- sometimes, choosing the language that lets you run faster, even at some sacrifice will put you ahead early in the game. You can figure out later how to replace all your duct tape, while dancing on the corpses of the competition.
It's a tradeoff - what are you trying to accomplish, and what would you rather spend your time doing?
More flexible languages are often also more expressive and have better tooling (e.g. for a CRUD app it's hard to find something nicer than Django / Rails), but tend to be slower. The other end of the spectrum is more performance-oriented languages where everything is way more verbose, and has low expressiveness, there's a lot of boilerplate, writing any code that does something relatively simple is more onerous. So depending on what phase of development you're in and what you're doing, the "obvious" choice can be different. And as companies grow and mature, those goals also shift.
Granted, that gap is closing with compiled / systems languages getting more and more expressive (Rust, Nim, Go?, C++11/17?), but it's also closing with scripting languages getting faster (very blanket statements here).
The fact that python, and some Java, but decidedly not C++, is the de-facto standard tool for the scientist these days should give you pause. Machine learning, gpu computing stuff, large scale data processing with spark - you can all do it with python. Sure, it's all C and Fortran and Java behind the scenes, but who cares? No one wants to bother with that if they can avoid it. They just need to get their job done.
Another example, more towards your requests per second example, is Japronto (https://medium.freecodecamp.com/million-requests-per-second-...) - turns out if you take time to optimize the event handling and the http parsing, suddenly you're back in the ballpark of compiled languages. Sure, other bits of code are going to then become the bottleneck, but those can be made faster too.
The "high level developer interface + compiled and optimized internals" combo is just very hard to beat, because it's always going to be good enough where it counts.
Also, performance improvements for a language or specific libraries is something that can be done as a centralized effort by experienced and knowledgeable people on that specific subject. Chances are most people aren't going to write a matrix multiplication operation that'll beat BLAS stuff, so why bother unless you have an extremely good reason? This is much more efficient and happens "for free" from the point of view of the end-user developers (also computers are getting cheaper and faster, also for free). So why bother?
I think Facebook / HHVM / PHP was sort of the boundary of how far this can go, but I think it's a testament to it rather than against it. Granted, not every company is Facebook, but like I said, the gap is closing too. But I think more dynamic languages are always going to become "fast enough" faster than more static languages becoming more expressive and nimble, and will often beat the latter in available tooling (I remember "package management" and build tools in C++, ugh.)
Why readers are downvoting it shall remain a mystery.
Usually, it's many orders of magnitude less than billions of hours, and the reason is that raw machine language is fast, all higher level languages are designed around ideas of desirable abstractions.
"I urge designers of future dynamic languages to study Lua and LuaJIT if you want your language to not inhibit JIT development."
and [2]:
"Agreed. Also Smalltalk's memory model was a lot easier to optimize than languages like Python and Ruby. (Java inherited some of that.) Not having syntactic sugar makes optimization easier. In addition, language designers need to make parser tools easy to make and robust."
Because CPUs are so fast there is usually no need to worry about performance and clarity of code and convenience is more important.
Also you have to remember that Python "grew up" from early 90s through early 2000s. That when most CPUs were not multicore and CPU speeds were doubling every year almost. You could write something in Python, and in a few years, it would speed up just by going to a better hardware.
You had the alternative of "here is 2000 of lines of C++ with templates, pointers, references, inheritance, constructors of various types, kind of meh standard library" vs "here is 500 lines of Python that you can read, understand and fix in much less time". Python was slower but that's ok. Getting faster machines was easier and cheaper than than work-hours poring over bugs and segfauls in the C++ code.
The one reason we talk about Python and speed is because it was widely adopted and in some cases companies wanted more "speed" from it. Then multi-CPU machines become commodity and there was more talk about the GIL and such.
If anyone fills in some of the blanks, thank you in advance.
PyPy is not that bad as they describe it in incentives to start Pyston. PyPy now has cpyext and Python 3.5 support is funded by Mozilla.
Another reason is pluggable JIT to CPython such as Pyjion. This is already possible in Python 3.6.
Currently you can use Cython for hot spots in your CPython apps and even release GIL.
It's not typing that's the problem, it's dynamic behavior like monkeypatchable methods which require dict lookups.
It's a little tiring, as somebody who regularly puts production workloads onto PyPy, to hear this bullshit. The truth is that PyPy has been regularly spanking Pyston on benchmarks[1] and has been adding Python 3 support while Pyston has struggled to handle its Python 2 commitments.
It's great that you wanted to build a JIT. JITs are fun and cool. But if you just wanted shit to work, you could have used PyPy years ago and not jumped through all these hoops.
Yet again, the fact is that if you invested any code into C extension modules, you picked the wrong path. Good night, Pyston; you were a cool experiment and I hope that your contributors try sending patches to PyPy next time. (Pyjion, you're next.)
[1] https://pybenchmarks.org/u64q/benchmark.php?test=all&lang=py...
I also think Kevin hits the nail on the head regarding what makes speeding up Python difficult. It's the same thing that makes writing Python so enjoyable: the object model.
Using a JIT to generate very fast code for dynamic (even highly dynamic) languages is a really interesting topic. But it seems to involve jumping through a lot of hoops to get performance that is a fraction of what you can get out of an early 1990's era C compiler (or Pascal compiler, for that matter).
The gains that come from using typescript are productivity gains: in big projects static typing, generics, decorators, and interfaces are supposed to be a boost to productivity, not a boost to performance.
Also even if you can't statically determine the types of some variables typescript seems to be able to determine it for most. If most of the objects are statically known would it give you a large part of the speed up of a totally static system? In Java and C# there's still some intentional holes in the type systems like the dynamic keyword or casting to object
Sure, sometimes you might be able to generate more efficient code by tailoring the emitted Javascript to the VM behaviour or using something like typed arrays for low level operations, but if the target language doesn't have support for certain things like type hinting, there is not much that could be gained.
Nope, it's never been the case, even with all the flags on. It's not about implicit casts, it's about soundness in the actual type rules. Here's an example:
function append(array: Array<Object>) {
array.push("not a number");
}
var nums: Array<number> = [];
append(nums);
console.log(nums[0].toFixed());
> If most of the objects are statically known would it give you a large part of the speed up of a totally static system?
Maybe, but it's hard to say. Once you have a single hole, if you can't check it at runtime right at the hole, then values of the wrong type can spread anywhere in the program.
> In Java and C# there's still some intentional holes in the type systems like the dynamic keyword or casting to object
Right. In the above example, Java and C# would throw an exception when you added the string to the array. This check has some runtime cost, but works.
I believe TypeScript is also unsound around function types, which is harder to address because there's no easy place to know where to add the check.
I agree that making simple and dynamic languages with hugely complicated JIT-compilers is pretty absurd. We need new and fundamentally better languages, that combine performance, expressiveness, and much better compile-time guarantees.
The key is designing the extension points and the API in a way that allows efficient implementation. In Python that never happened. It seems like they basically documented the implementation and said: 'here are the dicts containing the internals, feel free to do anything you want'. That's an approach that will never result in an efficient implementation without huge efforts.
I'm familiar with CLOS, but I have never looked seriously into implementation strategies. I have read many research papers on compiler design, language design, (multiple)dispatch implementations, and I have concluded that the languages we use day-to-day are decades behind what we would be using if we took advantage of this research.
> Presumably this compiler could generate code that is faster than an interpreter like CPython,
People have been writing static compilers for dynamic languages for ages. Lisp and Scheme have been compiled for a long time.
My understanding is even simple static compilation works tolerably well for something like Scheme, but object-oriented languages like Python are a different story.
In object-oriented languages, the majority of "calls" are potentially-polymorphic method invocations. In Python, even `a + b` may call some user-defined "+" method which must be looked up at runtime.
If you statically compile that in a straightforward way, almost all of the resulting "static" code is just going to be calls to dynamic method lookup functions. Something like:
Obj* temp1 = lookup("a");
Obj* temp2 = lookup("b");
Obj* temp3 = invoke(temp1, temp2, "+");
You can look at bytecode is a compression format for dynamic code of that form. The runtime cost of "decompressing it" -- the bytecode interpret-and-decode loop may be a net win over the memory wasted by the larger native code size and the cache misses and stuff caused by that.
In order to statically compile a very highly dynamic language, you really do need to do some static analysis to eliminate some of the dynamism. That analysis is either very costly (slow, giant monolithic whole program compiles that take ages as in MLton) or doesn't work very well (failing to infer good static types and resorting back to lots of slow dynamic code), or (most often) both.
With Dart, we have a very mature whole program compiler that does concrete type inference, and it's still both too slow to run and not effective enough at inferring good types.
> However, once you add static type notations, the static compiler can (for some cases) generate code that's actually faster than a JIT.
You can do that, yes, but it requires a few things:
1. Your core libraries and idiomatic user code need to actually be fairly "static" in terms of the types they use at runtime. If the code really does use a lot of polymorphism and duck typing, all static analysis can do is tell you, "Yup. You gotta do this at runtime."
Python in particular is well-known for relying heavily on duck typing in its core libraries.
2. Your type system needs to be sound. Once you are within the bounds of static types, the compiler needs to be able to trust that those types are correct, with no soundness holes. Otherwise, it all falls apart.
3. You need to deal with the boundary between dynamic and typed code. Because of 1, you need to do validation when an object flows from dynamic-land into the typed area. That validation occurs at runtime and has its own cost. If you aren't careful, that runtime cost outweighs the perf benefits you get once you are in static code.
The "gradual typing" folks have been beating on this for years and it turns out to be really hard. Google "is gradual typing dead" to see some of the latest soul-searching.
With Dart, we had 1 since the language has always had an optional static type so typical Dart code is fairly Java-esque. We did not have 2 and that turned out to be a big problem. We have since come up with a new sound type system [1] to address that.
3 is hard, but our strategy has been to be more restrictive on what kinds of dynamic code we allow to flow into typed code. For example, you simply can't pass a List<dynamic> into a function that expects a List<int>.
By the time you do all of these things, I think you discover that you don't really have much dynamism left in your system. It is handy having a dynamic type for some places, like deserialization, JSON, etc. But if you care about static compilation and perf, actually being statically typed is just so much easier, and dynamic typing doesn't really offer that much value as an alternative.
[1]: http://news.dartlang.org/2017/01/sound-dart-and-strong-mode....
As far as I know, they don't compile ahead of time. They JIT based on the types that are seen at runtime, and from what I've heard, they generate a lot of code for various specializations.
That's a smart trade-off for a mathematical language designed for running on a desktop, but probably not super relevant here.
Or you can require the user to add type annotations, if/when he wants fast code.
In SBCL (a compiler for Common Lisp):
(defun count-even (array)
(declare (optimize speed (safety 0))) ; <- these are the optimisation settings for this function
(declare ((simple-array fixnum) array)) ; <- the argument to the function is an array of fixed sized integers
(loop for x across array count (evenp x)))
> (disassemble 'count-even)
; disassembly for COUNT-EVEN
; Size: 65 bytes
; 05A7ABC2: BB17001020 MOV EBX, 537919511 ; no-arg-parsing entry point
; BC7: 498BF8 MOV RDI, R8
; BCA: 31C9 XOR ECX, ECX
; BCC: 31F6 XOR ESI, ESI
; BCE: 31D2 XOR EDX, EDX
; BD0: 498B70F9 MOV RSI, [R8-7]
; BD4: 660F1F840000000000 NOP
; BDD: 0F1F00 NOP
; BE0: L0: 4839F1 CMP RCX, RSI
; BE3: 7D18 JNL L1
; BE5: 488B5C8F01 MOV RBX, [RDI+RCX*4+1]
; BEA: 4883C102 ADD RCX, 2
; BEE: 4883E302 AND RBX, 2
; BF2: 4885DB TEST RBX, RBX
; BF5: 75E9 JNE L0
; BF7: 4883C202 ADD RDX, 2
; BFB: EBE3 JMP L0
; BFD: L1: 488BE5 MOV RSP, RBP
; C00: F8 CLC
; C01: 5D POP RBP
; C02: C3 RET
Isn't this basically exactly what cython is?
Compilers (especially JIT-compilers) are hard to get right and even harder to get performant. Since i am interested in these areas i would evaluate Graal/truffle or Jython. I only looked briefly at it, but Jython seems very un-optimised and the JVM really improved it scripting-language support in the recent years. Is there really no way to solve the native-extension problem of Jython?
But i maybe wrong, any comments?
The native extension problem can be solved in Truffle with the LLVM bitcode interpreter. We're using this to interpret Ruby's C extensions.
Also, if it's faster and the C-extension solved by the LLVM interpreter, what's holding it back from being used?
The C extension problem is solved in theory. We're now working on making it something a bit more substantial that the research implementation we have talked about previously.
your comment today was the first time I realized there was a Truffle port for Python, and is NOT maintained by the parent oracle org. https://github.com/securesystemslab/zippy
Any particular (technical) reason ?
You are correct, it is easier to rewrite in Go. That's what Dropbox learned after putting two FTEs on Pyston for a few years.
But the larger Python community outside of just Dropbox would have really benefited from these two guys continuing to work on Pyston.
I just question whether it's the right move for dropbox. Seems like not actually tackling the problem and instead trying everything so that it just disappears.
How much of Dropbox could they rewrite for something quicker than CPython in the time taken to write a JIT? That's the ultimate business question, and there's plenty of evidence to suggest that in general JITs have been comparatively easy versus a rewrite. As the article says, they have millions of lines of code.
At the same time, at least from my knowledge of the languages, JS, Lua, and PHP are all easier to optimize than Python is (because you can do crazier stuff with Python's object model). JS and Lua also benefit from their incredibly small standard libraries which also means you don't need to potentially spend lots of time reimplementing libraries; CPython at least has most of its being implemented either in Python or through its C API which means if you have C API and licensing allows you can just pull out much of it from there.
Afaik it started out as experiment, driven by one or two engineers and got to a significant usability level before it got more resources.
Even if you have 10 or 30 engineers working on it, if they can speed up the other code written by thousands of developers, it can still materialize a huge gain.
Ok, they're doing all of this in their codebase?
This seems like "trying too hard". Yes, they can do those. It doesn't mean it's a good idea
They might not be, but the point in the blog suggests that standard libraries they consume do.
I wonder what the value proposition is in hunting down such stuff and fixing at that level (and whether that will help performance in cpython, pypy, pyjion etc.)
Pyjion is a Microsoft CoreCLR JIT that can support C extensions. That's Python's next great hope for speedup via JIT.
Note that you can use pythonnet for interop between CPython and .NET for both embedding and extending.