Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python-based compiler achieves orders-of-magnitude speedups

news.mit.edu

Post reply on HN
Print view View original

171–180 of 193 posts

Re: Python-based compiler achieves orders-of-magnitude speedups

#171

Post by tekknolagi »

robertlagrant wrote: post #94
jstx1 wrote: post #25

Earlier quoted context omitted.

Have a look at Cinder - https://github.com/facebookincubator/cinder - it's Meta's performance oriented fork of CPython that they use to run Instagram (which is a big Django app).

I always wondered with Cinder why they didn't turbocharge PyPy development instead.

Two main reasons:

* C extensions

* Instagram's forking server model

I gave a talk that touched on some of this last year: https://2022.ecoop.org/details/ICOOOLPS-2022-papers/5/Cinder...

I wonder why the recording is not up...

Re: Python-based compiler achieves orders-of-magnitude speedups

#172

Post by tomn »

tomn wrote: post #80
tlarkworthy wrote: post #44

Earlier quoted context omitted.

JavaScript/lua are dynamic and they are fast. It's other choices (GIL) which cause problem rather than the nature of the dynamic language space

The GIL improves single-threaded performance compared to other options.

Maybe i should have explained this..

To share objects between threads, some synchronisation is needed, for example to update reference counts. There are a few ways to do this:

- make the user add locks; the problem with this if it goes wrong it can crash the interpreter and make it impossible to debug the problem from within python, which is not user-friendly, and lots of existing code will break. Competent users are already doing this though, so it's nearly free. - add fine-grained locking/synchronisation for object internals within the interpreter. This slows everything down, even if you're not using threads. - Lock the whole interpreter state whenever a thread is running. This makes threads less useful (no speed-up from threading pure-python code that isn't doing IO; you have to use multiprocessing for that), but it's cheap as you only need to lock/unlock when you're doing something slow anyway (IO, thread switching, native code).

I think this explains why GIL removal has not been successful yet despite much work: the alternatives slow down single-threaded code, which is not worth it when nearly all sensible uses of threading don't benefit either.

Re: Python-based compiler achieves orders-of-magnitude speedups

#173

Post by capableweb »

ginko wrote: post #116
capableweb wrote: post #101

Earlier quoted context omitted.

Github reports it's 55% C++ and 43% Python, not too bad if it's correct.

I would expect a large chunk of the 43% Python to be tests.

Yeah, that'd make sense. Good point.

Re: Python-based compiler achieves orders-of-magnitude speedups

#174

Post by CJefferson »

vlovich123 wrote: post #73
pjmlp wrote: post #62

Earlier quoted context omitted.

The difference is that the other languages FFI don't expose internals like CPython does. For example, JNI only exposes handles and you need to convert an handle to a pointer, so the runtime knows for the time being that handle is special and being used by native code. When it is only an opaque handle, lots of optimizations can happen and the native code won't see them.

Doesn’t PyPy accomplish it via CPyExt? It sounds like Cinder, Instagram’s version is CPython+JIT (among other things). I haven’t looked at the details so maybe it’s not a sufficient speed up and that’s why all these parallel efforts haven’t been merged? The part I’m missing is how what you said makes it intractable when we have counter examples within and without the language. Sure. Maybe some optimizations aren’t po…

Things aren’t impossible, but they are very hard. As you know about CPyExt, it’s probably best to point to you pypy’s article on why it makes things hard (you may have already read this!) https://www.pypy.org/posts/2018/09/inside-cpyext-why-emulati...

Re: Python-based compiler achieves orders-of-magnitude speedups

#175

Post by paro_nej »

dbrueck wrote: post #155
paro_nej wrote: post #145

Earlier quoted context omitted.

My claim is that there is no additional information that Python provides as opposed to C that would make it faster. And hence, the only conclusion I have is either they have supercharged their compiler for that particular benchmark OR they have chosen to handicap C as once can express the computation in C that emits the same assembly that they lowered to and hence my point on handicapping the C benchmark.

> My claim is that there is no additional information that Python provides as opposed to C that would make it faster Ok, but that's not what they are claiming - their claim (at least based on what the article is saying) is more about one toolchain vs another, i.e. "if you use our compiler (that takes python code as input) then the resulting executable will run as fast (or possibly faster than) programs created by all…

Beating gcc/clang/icc is not a trivial task. One can engineer the pair `{benchmark compiler pass}` in such a manner that they show a speedup, but over a benchmark suite say like the SPEC suite, general community consensus is that it is very difficult and their paper doesn't reveal that they've found a secret sauce (sauce := compiler pass).

Re: Python-based compiler achieves orders-of-magnitude speedups

#176

Post by SloopJon »

UncleEntity wrote: post #35
SloopJon wrote: post #32

Earlier quoted context omitted.

Another big difference: "Codon is licensed under the Business Source License (BSL), which means its source code is publicly available and it's free for non-production use. ... each version of Codon converts to an actual open source license (specifically, Apache) after 3 years." https://docs.exaloop.io/codon/general/faq

Compilers traditionally don’t taint users code with their own license, seems this one does.

I don't see any indication that Codon makes any claim to generated code. It's just that the license prohibits production/commercial use of the compiler--not much different than other proprietary compilers like, say, Visual Studio.

Re: Python-based compiler achieves orders-of-magnitude speedups

#177

Post by syngrog66 »

took me a while to decode the fact that Codon is (AFAIK) just a Python-to-native compiler. and an incomplete/non-conformant one to boot. The title and OA was written in a breathless, but murky style

"Oh... a native compiler. That cheats by not really honoring Python. Got it."

Re: Python-based compiler achieves orders-of-magnitude speedups

#178

Post by ActorNightly »

afdbcreid wrote: post #148
ActorNightly wrote: post #119

Earlier quoted context omitted.

>I'm kind of starting to see what Guido is talking about when he says Python is a legacy language that's probably on its way out. Even in the interpreted world, languages like Janet and other newcomers are performing fascinating experiments, often doing more with less. Wow, what a way to mischaracterize what Guido said. His point was about languages evolving to be more abstract than Python or any of the ones you ment…

Rust is different because it is trying to answer real needs. It is not going to replace Python, and if you're seriously thinking about writing your code in Python you probably shouldn't be thinking of writing it in Rust. There will likely also be less Rust code than Python code. But it can replace C/C++, not completely and not in the near future, but it is possible.

Both Python and Rust guarantee memory safety. Python does it through automatic reference counting at runtime, Rust does it through compile time checks. If you are writing backend code, you could really do it in either, and you would hypothetically choose Rust because its compiled and going to be fast.

The problem with Rust is that they have the unsafe operator. When using a 3d party library, I have no idea if someone put a bunch of unsafe code in there, so all memory safety guarantees go out the window. Sure, you can grab the raw source and compile it yourself, but then that introduces a whole bunch of friction into the dev process.

And the reason unsafe is in Rust is because you can't write standard library stuff, especially with performance in mind, using traditional Rust constructs.

In the end, Rust doesn't give you anything over a compiled C extension to Python, that can be written as memory safe in the sense that it just receives a buffer of data to process with preallocated memory, runs said processing, and returns the data. This is pretty much the standard way that ML works except the compiled extensions just get put on the GPU rather than CPU, and the overhead of the translation layer is extremely small in comparison.

Re: Python-based compiler achieves orders-of-magnitude speedups

#179

Post by ActorNightly »

mrkeen wrote: post #158
ActorNightly wrote: post #117

Earlier quoted context omitted.

What is this talk about "rescuing" Python performance? Python does not need to be rescued. Its fast enough. For 90% of applications, you are kidding yourself if you need more speed. These are enhancements on Python, where you want to run stuff even faster on par with other languages.

> What is this talk about "rescuing" Python performance? Which part don't you like: That python is relatively slow? https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Or that people are trying to fix its slowness? See the thread you're currently in.

Python is slower than other languages, yes.

Python is not "slow" in the sense that it not applicable to use when you wanna run real world applications.

Yours is the equivalent argument for buying a BMW M3 over a Toyota Corolla because it can do a faster lap time around a track and thus is better for your commute, except in the real world with traffic and traffic lights, on a 30 minute commute home, you will probably arrive at your destination 1 minute quicker in the BMW over a Corolla.

Re: Python-based compiler achieves orders-of-magnitude speedups

#180

Post by ActorNightly »

switchbak wrote: post #166
ActorNightly wrote: post #117

Earlier quoted context omitted.

What is this talk about "rescuing" Python performance? Python does not need to be rescued. Its fast enough. For 90% of applications, you are kidding yourself if you need more speed. These are enhancements on Python, where you want to run stuff even faster on par with other languages.

Its performance and poor support for parallelism has prevented me from using it in places I've wanted to for years. Is it "fast enough"? fast enough 90% of the time? Or just fast enough to leave you uncertain that it's even a good choice? Sorry, we have productive choices now that don't leave me worrying about this situation. I still like it though, and if they could solve those issues I'd probably use it a lot more!

If you want to crunch a lot of numbers in parallel, GPUs are your friend, and thus C/C++ (or any of the python libraries that already set these up for you).

If you are trying to run a lot of executions in parallel where you need the full instruction set of the CPU over a GPU (namely, the compare/jump operations, otherwise known as if statements, for loops, e.t.c), then you are most likely either extremely resource constrained (like writing code for a microprocessor or embedded system), at which point you will still use C/C++, or writing something like a video game, which again is C/C++/C# (or Swift for Apple).

For most every other use case, Python is simply applicable with its vast array of libraries. For example, at my work, we use FastUI with orjson for a backend that needs to handle some significant TPS. Its fast enough. Could we write the entire thing in another language and use less ECS containers/EC2 instances? Sure, and we will save on cloud costs but lose massively on developer costs.

Post reply on HN