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

181–190 of 193 posts

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

#181

Post by igouy »

ActorNightly wrote: post #179
mrkeen wrote: post #158

Earlier quoted context omitted.

> 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…

Or is the equivalent a BMW M3 over a Fordson tractor? :)

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

#182

Post by Doxin »

FridgeSeal wrote: post #159
bravura wrote: post #125

Earlier quoted context omitted.

If you code a website, your speed issues probably come from the database layer. Not your Python.

What are you doing to your database? Lol Most databases I’ve dealt with will happily outstrip Python for a good chunk of the common queries.

For sure, but django for instance is really good at turning something that ought to be one query into N+1 queries.

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

#183

Post by fud101 »

Doxin wrote: post #182
FridgeSeal wrote: post #159

Earlier quoted context omitted.

What are you doing to your database? Lol Most databases I’ve dealt with will happily outstrip Python for a good chunk of the common queries.

For sure, but django for instance is really good at turning something that ought to be one query into N+1 queries.

how do you deal with this?

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

#184

Post by fud101 »

Mikhail_K wrote: post #113
msla wrote: post #105

Earlier quoted context omitted.

I wonder what experienced Common Lisp compiler devs could accomplish if they turned their attention to Python.

https://julialang.org/benchmarks/

no thanks, julia is a nicer matlab. python is a proper general purpose language.

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

#185

Post by jojohohanon »

_gtly wrote: post #56

Paper here: "Codon: A Compiler for High-Performance Pythonic Applications and DSLs": https://dl.acm.org/doi/pdf/10.1145/3578360.3580275 "Currently, there are several Python features that Codon does not support. They mainly consist of runtime polymorphism, runtime reflection and type manipulation (e.g., dynamic method table modification, dynamic addition of class members, metaclasses, and class decorators). There are…

Isn’t it “self”, really? [1]

Assume your python program is fully static and well behaved from a compiler perspective. JIT compile it, and observe what it does, so that you can invalidate the compiled code and re-JIT it if it does something overly dynamic.

Incidentally, what JVM did. (I’m sure now it’s been tweaked beyond recognition)

[1] https://bibliography.selflanguage.org/pics.html

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

#186

Post by crabbone »

mrtranscendence wrote: post #134
crabbone wrote: post #36

Can we please not? Humanity wasted close to 50 years optimizing compilers for one garbage language. Wasted unimaginable efforts, money and developer hours... and all could've been avoided if the same people dedicated a fraction of those resources to language design. Same thing happened with Java. And now the existence of a well-developed compiler became an argument in its own right in favor of choosing a bad language…

Such an overwhelming amount of perfectly good solutions are created with Python that I have trouble conceiving it as a "trash" language. Clearly it's at least good enough in many scenarios. For example, I use it for machine learning and data science professionally and I find it much more pleasant to use than alternatives in that space (e.g. Julia and R -- both have advantages over Python but have disadvantages too).…

> Such an overwhelming amount of perfectly good solutions are created with Python

Name one. I'll tell you why it's trash.

> Clearly it's at least good enough

Trash (literal, from the dumpster) is often good enough to eat. What's your point exactly?

> I find it much more pleasant to use

It's a skill issue.

> it's easy to find libraries and examples,

This has nothing to do with the language. Give Julia 20 years of popularity, and it will have just as many useful libraries and examples.

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

#187

Post by ReflectedImage »

ActorNightly wrote: post #178
afdbcreid wrote: post #148

Earlier quoted context omitted.

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…

Well Rust will replace C++ basically. It does C++'s use cases better than it.

It's not a Python replacement in any sense of the word.

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

#188

Post by Mikhail_K »

fud101 wrote: post #184
Mikhail_K wrote: post #113

Earlier quoted context omitted.

https://julialang.org/benchmarks/

no thanks, julia is a nicer matlab. python is a proper general purpose language.

Julia is not a proper general purpose programming language, because it has one-based array indexing?

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

#189

Post by WhatTheFlak »

fud101 wrote: post #183
Doxin wrote: post #182

Earlier quoted context omitted.

For sure, but django for instance is really good at turning something that ought to be one query into N+1 queries.

how do you deal with this?

Don't abuse the damn ORM.

And write SQL directly for medium complexity queries.

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

#190

Post by WhatTheFlak »

ActorNightly wrote: post #117
zmmmmm wrote: post #109

Am losing count of all these efforts to rescue Python's performance - they all seem to amount to the same thing: it's not very hard to achieve this if you throw out fundamental aspects that make Python what it is. The premise is always that syntax is the barrier, and that people struggle so much to learn a new syntax that this is what keeps them using Python even though its performance is abysmal. But what if this is…

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.

Python is currently running on 100,000s of CPUs right now. There's an environmental cost to that.

Moreover, people have huge python apps that they can't just rewrite and python just isn't fast enough. This has happened so many times. So many man hours have been spent optimizing python code, that we have over a dozen different implementations in just this thread alone and it doesn't include 3 that I know of.

Python's current Achilles heel is actually it's performance. It's slow as fuck. Those 10% of applications matter. And faster performance won't hinder anything for people writing 100 line scripts.

Post reply on HN