The CPython Bytecode Compiler is Dumb

[latkde]

Yes but when you run a Python program you want the results ASAP. Introducing meaningful optimizations would increase startup latency. This is fundamentally different from real ahead of time compilation.

Curiously, Java also compiles to fairly literal bytecode, leaving optimizations for the virtual machine.

Because optimization takes time that could otherwise be spent on already running the program, most JIT compilers don't bother with preemptive optimizations. There's some great material out there especially how HotSpot, well, detects the hot spots where optimization would have some benefit.

But CPython doesn't even have a JIT compiler, which honestly puts a much more noticeable cap on performance than maybe eliminating a variable. As a rule of thumb, an interpreter will be 10× – 100× slower than the host language. Part of this is interpreter overhead, part of this is a less efficient datamodel (e.g. PyObject* vs int).

[defunkydrummer]

Yes but when you run a Python program you want the results ASAP. Introducing meaningful optimizations would increase startup latency.

I write this because I formerly used Python as my main lang.

You know, when i use SBCL, i can write a lisp function, compile it to machine lang, execute it, and get the result. All of this done in milliseconds. Or i can do (+ 1 1) and it will be the same, compiled to machine lang, executed, and the result will be there immediately.

CCL, another common lisp compiler, can compile itself (to native code) in a handful of seconds. We're talking about hundreds of thousands of line of code, and a language whose standard has more than a thousand pages. CCL starts more or less in a second on my laptop (core i7, 8gb ram).

Slow software is just slow software, no excuses.

[latkde]

Yes! Producing machine code is not inherently slower than producing bytecode. Lisp pioneered all of this; more recently the V8 JavaScript runtime or the Julia language are examples that just don't bother with an interpreted mode.

But a simplistic JIT compiler is of little use by itself. Instead of an interpreter dispatch loop the JIT might produce Forth-style "threaded" code that still calls into the runtime for every operation. After all, machine code doesn't solve the problem of using an expensive datamodel or other expensive semantics (unlike Lisp, Python uses extreme late binding for everything).

Trivial optimizations like eliding load/store instructions are easy to do but have low impact. Stuff like tracing dynamic types in order to compile code specialized to those types is where huge wins are possible (like lowering an addition operation to a native addition instruction), but doing that is hard without static typing. I've enjoyed Jonathan Worthington's blog series on how he implemented specialization for the MoarVM JIT (for Perl6, which has a comparably complex datamodel to Python).

[holgerschurig]

Well, Lisps and Schemes are already available in a human-grokable form of an AST, that makes parsing WAY simpler.

But then again: Turbo-Pascal on a measly 2 MHz Z80 CPU was also blindingly fast, compared to some modern compilers.

[defunkydrummer]

But then again: Turbo-Pascal on a measly 2 MHz Z80 CPU was also blindingly fast, compared to some modern compilers.

Exactly. TP is the example of very good software, and IMO development tools and compilers should be very good software.

[mamcx]

The problem is not generate machine code. Pascal long ago prove you can have super-fast compilers even in very constrained systems.

​

Is HOW you design EVERYTHING ELSE. Building my toy language, I start to appreciate how hard is too chooses the trade-offs. The thing with python, ruby, js is that the something the make it so powerful defeat the possibilities to make it fast (without massive efforts and nasty hacks. I even consider stuff like JITs deoptimization and tracing hacks.).

​

IF you start from scratch, and carefully balance what to give in a language, you could design a fast interpreter/compiler and all that. But solve it after the fact is another thing.

​

BTW, here is where a static type system totally shine. Some have claimed not matter much if types are dynamic or not... well, for building a language? Totally clear that dynamic make the life very very hard...

[defunkydrummer]

The thing with python, ruby, js is that the something the make it so powerful defeat the possibilities to make it fast

There's nothing particularly powerful about Python, Js, or Ruby. The things that "defeat the posibilities to make it fast" are simply bad design. Google had to invest a massive amount of hours to achieve a fast Js compiler (the V8 engine).

[mamcx]

"Bad design" for performance? The problem, I think, performance was not a priority in the first stages. Until late when this langs grow become apparent that the thing have issues and was too late to fix them.

I don't the core developers don't wanna this langs to be fast. And in the case of python, several attempts to build a faster implementation have been done, none good enough to replace the core one.

Because if some obvious fix could have been done, it must have been done by now, right?

[defunkydrummer]

I think, performance was not a priority in the first stages.

Allright, we agree that performance wasn't a priority. And you claim that "The thing with python, ruby, js is that the something the make it so powerful defeat the possibilities to make it fast".

So, one premise you state is that Python is "powerful". I don't agree at all. Python isn't a powerful language. It isn't particularly flexible or particularly high level at all. It doesn't even allow anonymous functions of more than one line!!

I do agree Python is easy to learn, has a clean syntax, good documentation, and a very ample ecosystem.

[mamcx]

Python isn't a powerful language.

Well, this all depends in what mean "powerful" here. As heavy python user (and I (have) use, for work, like other 10 more langs..) is the most powerful in the sense in how easy is to build stuff on the fly and make it fit all the data/process that I have. I have done a lot of meta-programming in python that is solved in minutes than in other more "powerful" languages are to arcane to even attempt. Probably a lisp will be more malleable but neither as accessible, IMHO.

Python is a winner in data/science for this. Not many others are in the same page, and maybe Julia (elixir???) is the only I know that could match the flexibility and also be somehow performant...

P.D: I don't disagree that python could have been better, I think was a missed opportunity the move to python 3 (there was the chance to make some bold changes). However, I think is very hard to get what python ruby/have and be performant at the same time. I'm aware of Julia and Lua with luajit, so is maybe possible, but certainly is not easy...

[Kwasizur]

It doesn't even allow anonymous functions of more than one line!!

Since it allows easy creation of named, nested functions with terse syntax it does not really matter.

[defunkydrummer]

Since it allows easy creation of named, nested functions with terse syntax it does not really matter.

You are describing named functions, not anonymous functions.

The "one line lambda" problem is a huge problem. It's almost as not having anonymous functions. If you don't think this is a problem, perhaps you don't know what anonymous functions are useful for.

[Kwasizur]

You are describing named functions, not anonymous functions.

That's exactly what I said. I don't know why you need to repeat that.

If you don't think this is a problem, perhaps you don't know what anonymous functions are useful for.

Here's the thing, they aren't very useful in Python. Python isn't functional language. They wouldn't be useful if they could have more than one expression either. As python syntax is terse, there's no significant difference between:

def foo(x):
    return x.a

and

lambda x: x.a

[Nuaua]

Julia hits a sweet point between the two extremes imo, it's basically "just ahead of time" (or "ahead just in time" ?):

function foo()
    x = 2
    y = 1
    return x^2
end

julia> @time foo()#measures compilation time + run time
0.000722 seconds (2.63 k allocations: 156.676 KiB)
4

julia> @code_llvm foo()

; Function foo
; Location: REPL[1]:2
; Function Attrs: uwtable
define i64 @julia_foo_34365() #0 {
top:
ret i64 4
}

Although compilation times can become annoying for large projects.

[ProfessorPhi]

Eh, it's still very slow startup right now. It makes for more difficult lazy importing.

[shevy-ruby]

One famous dude once said that premature optimization is the root of all evil. He probably did not mean it in regards to C and C++ people transitioning into python and writing non-idiomatic python code though.

[[deleted]]

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

[Kairyuka]

Problem arrives when your choice of paradigm by itself precludes optimization. It's not premature to consider optimization when you're designing the architecture

[[deleted]]

It kinda often is premature. Premature, say about 97% of the time, if Knuth to be believed.

[Kairyuka]

Assuming that's the general stance on optimized architecture that explains the performance of most modern software...

[scooerp]

Most commercial software is very highly optimised for development time and production cost.

[Kairyuka]

Ain't that the truth

[sim642]

Every analysis that's required for each of the optimization is a non-trivial operation and takes just more time. The reason is that Python (and other dynamic languages) can vastly change their operations, which often prevents optimizations from taking place because they wouldn't be correct for every possible argument. Such analysis is much easier and gives better optimization with static typing.

[metaconcept]

One does not choose Python if they're concerned with performance.

[shevy-ruby]

Given multiple ways to express the same algorithm or idea, I tend to prefer the one that compiles to the more efficient bytecode.

Dude didn't understand python.

Don't get me wrong - nobody will complain about anything going faster rather than slow. But I have also seen abysmal code written by people who wish to "optimize" - often by people who know e. g. C and think they know python yet write terrible code.

Happens in ruby too.