Or you can use PyPy of course, but that's a compatibility nightmare exactly when you're gluing together a bunch of C libraries with Python interfaces.
And in principle, JIT doesn't necessarily mean non-embeddable; LuaJIT is pretty good from an embedding perspective. Besides, I would assume they make JIT a build-time option so that people whose use case makes it problematic can use only the bytecode interpreter instead.
That said, your concerns about performance variability are warranted, and there are probably specific criticisms to be made about the choice of LLVM. LLVM is a gigantic dependency and I hope the performance wins of choosing LLVM rather than, say, crankshaft are worth it.
Why does that matter?
Presumably if you care about Python performance, you have a real world scenario that you can benchmark. Just make a benchmark that is as representative as possible and check if the JIT helps. If it doesn't help, it surely can be disabled via an option.
Because you need to have an idea of how many machines you need. And you need an idea of whether 'it will take as long as it takes' or if there's an issue in your code.
Sometimes Java decides to JIT using aes instructions. Sometimes it doesn't. Even if you run the same benchmark suite twice in a row it just does its own thing and gives wildly different results.
My learning was that one shouldn't depend on JIT performance and prefer using JNI libraries if you want consistency. Hence my comment being negative on JIT.
Hopefully this is a feature that can be disabled when you want deterministic behaviour. There's no reason to make it mandatory in a well-engineered VM.
If those aren't solid proving grounds for JITs, nothing is.
JIT caches, AOT have been an option for years.
And if you are really motivated, you can write stuff in C just like in Python.
You're just sticking with what you know, calling out the others for not wanting to learn.
Not a nice attitude from where I'm at.
Print Hello, world.
That's it. Time it.
Do the same with Python.
The difference is minuscule.
People don't build CLIs with them due to cultural reasons (fashion). Developers are creatures of fashion.
java: 031s python: 013s
it's 3x slower to start up… it means that any bash script with a loop calling a java command will run 3x slower.
3x slower isn't my definition of minuscule.
I'm confused, what kind of time measurement system is this? Are those 31 seconds versus 13 seconds? 0.31s vs 0.13s? If it's the first case, something is wrong with that machine, Hello World should not take that long. If it's the second, are we talking about 0.18s? See below.
> it's 3x slower to start up… it means that any bash script with a loop calling a java command will run 3x slower.
I don't know how you write your scripts, but in practice most scripts hang waiting for IO (especially network) or waiting for a specific command to process something...
> 3x slower isn't my definition of minuscule.
Nope, but based on what you've presented so far, unless I'm misunderstanding, it's my definition of "premature optimization".
> I don't know how you write your scripts,
You know how… I put print hello world in them… that was the test you asked for?
> premature optimization
Not using something that has 3x startup time, for a short lived command is just "common sense".
I'm starting to think that the issue here is that you know java but don't know python or C, and you are unconsciously trying to get water to your own watermill.
It's just that I recognize disingenuous comments.
Java is perfectly adequate as a language for writing command line tools. You're likely using one of them weekly and don't even know it.
Just don't write your Java CLIs using Spring or DI frameworks in general :-)
doubtful, since I don't have jre installed. I had to install it just to run that benchmark.
There is a reason I didn't say anything about that aspect of JITs that you mention, it's because it's not relevant to commands which are launched from shell scripts and then exit.
Incorrect, LLVM is only used in the compile time. See my other comments for details.
I've also thought this. If you're pre-baking your software, why not do this step as well?
Context: I use python for data processing and webdev. When doing data processing, Python is merely glue for libraries in compiled languages. When doing webdev, I mostly use python itself.
First, any numbers regarding benchmarks need to be treated with contempt. JITs are unbenchmarkable. No matter what you do, someone says you do it wrong. Warmed up the JIT? You did it wrong. Didn't warm up the JIT? You did it wrong. Warmed up and didn't warm up the JIT? Wrong.
You lose predictable performance characteristics due to the above. It's difficult to describe the importance of this to the people who look at Python as glue for their compiled code.
Next, on the face of it, it doesn't look like it will compose well with subinterpreters. If each subinterpreter does it's own tracing, it's going to be harder to hit the 10k watermark of jitting hot code.
This uses LLVM's JIT which is particularly slow and heavy (16MB added to the binary size) last time I tried to use it. So this limits Python attractiveness in being an embedded language.
While this remains experimental - and hence strictly optional, packaging this in distributions that use gcc would now apparently need llvm tools installed to build python. Expect feedback from distribution packagers.
Idea for improvement: when I do data processing, I'm using python to glue bits of C, Rust, and other compiled languages so this is not very useful. When I'm doing webdev, it could be useful - and I am deploying using Docker. So why not make this AOT so I can add it to a docker build step and get all the benefit without the complications of tracing jits.