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

Python: The Optimization Ladder

cemrehancavdar.com

Post reply on HN
Print view View original

81–90 of 154 posts

Re: Python: The Optimization Ladder

#81

Post by adamzwasserman »

seanwilson wrote: post #3

> The real story is that Python is designed to be maximally dynamic -- you can monkey-patch methods at runtime, replace builtins, change a class's inheritance chain while instances exist -- and that design makes it fundamentally hard to optimize. ... > 4 bytes of number, 24 bytes of machinery to support dynamism. a + b means: dereference two heap pointers, look up type slots, dispatch to int.__add__, allocate a new P…

The dynamism exists to support the object model. That's the actual dependency. Monkey-patching, runtime class mutation, vtable dispatch. These aren't language features people asked for. They're consequences of building everything on mutable objects with identity.

Strip the object model. Keep Python.

You get most of the speed back without touching a compiler, and your code gets easier to read as a side effect.

I built a demo: Dishonest code mutates state behind your back; Honest code takes data in and returns data out. Classes vs pure functions in 11 languages, same calculation. Honest Python beats compiled C++ and Swift on the same problem. Not because Python is fast, but because the object model's pointer-chasing costs more than the Python VM overhead.

Don't take my word for it. It's dockerized and on GitHub. Run it yourself: honestcode.software, hit the Surprise! button.

Re: Python: The Optimization Ladder

#82

Post by zahlman »

adsharma wrote: post #78
adsharma wrote: post #77

Earlier quoted context omitted.

It's not a popular thing to say on social media. V-lang is the one I'm tinkering with. It's like rust in terms of pattern matching as an expression, sum types, ?T instead of exceptions. Like golang, it has shorter compile times. I try to keep my argument abstract (that you need to lower python to something intermediate before rust) for that reason.

Here is a python AST parser written in V. It's targeting a dialect that's mostly compatible with a static subset of python3, but will break compatibility where necessary. In this case pattern matching, possibly elsewhere. https://github.com/py2many/v-ast

Never heard of this language, but it looks interesting. Very modern, certainly. One thing that stood out to me is that there's apparently the ability to write a bare `for` loop...? Is that just equivalent to while (true) in other languages?

Re: Python: The Optimization Ladder

#83

Post by zahlman »

pjmlp wrote: post #67
zahlman wrote: post #44

Earlier quoted context omitted.

> a garbage collected rust like language with fast compilation I don't know what languages you might have in mind. "Rust-like" in what sense?

Probably OCaml, Standard ML, Haskell, MLton, F#, Scala,.... If going to complain about some of those being slow, remeber that they have various options between interpreter, bytecode, REPL, JIT and AOT.

You know, I really should try out F# some time. I always preferred C# over Java, and I have some Scala experience (that wasn't overall very pleasant, but it was fun to use an FP language).

Re: Python: The Optimization Ladder

#84

Post by sirfz »

repple wrote: post #20

Significant AI smell in this write up. As a result, my current reflex is to immediately stop reading. Not judgement on the actual analysis and human effort which went in. It’s just that the other context is missing.

Fwiw, I thought the article is full of great information and well researched. I think your reflex is holding you back.

Re: Python: The Optimization Ladder

#85

Post by IshKebab »

atomicnumber3 wrote: post #73
IshKebab wrote: post #72

Instead of just using a language that isn't dog slow, why not jump through these 5 different hoops? It's much easier!

Because for 99% of cases python is fast enough and it's fast as fuck to code. And for the 1% that aren't, you have 50 different flavors of making it faster. And the final of which is "slap pybind on a c module to do the hot path in C" which then lets you minimize the suffering of C into a single high value location. And the rest of the code still gets to be Python.

> it's fast as fuck to code

In my experience it's no faster than other better languages like Go, Rust or Kotlin.

> And for the 1% that aren't, you have 50 different flavors of making it faster.

Only for numerical code. You can't use something like Numpy to make Django or Mercurial faster.

And even when you could feasibly do the thing that everyone says to do - move part of your code to a faster language - the FFI is so painful (it always is) that you are much better just doing everything in that faster language from the start.

All of the effort you have to go through to make Python not slow is far less work than just "don't use Python". You can write Rust without thinking about performance and it will automatically be 20-200x faster than Python.

I actually did rewrite a Python project 1:1 in Rust once and it was approximately 50x faster. I put no effort into optimising the Rust code.

Re: Python: The Optimization Ladder

#86

Post by hrmtst93837 »

rusakov-field wrote: post #8

Python is perfect as a "glue" language. "Inner Loops" that have to run efficiently is not where it shines, and I would write them in C or C++ and patch them with Python for access to the huge library base. This is the "two language problem" ( I would like to hear from people who extensively used Julia by the way, which claims to solve this problem, does it really ?)

[flagged]

Re: Python: The Optimization Ladder

#87

Post by adsharma »

zahlman wrote: post #82
adsharma wrote: post #78

Earlier quoted context omitted.

Here is a python AST parser written in V. It's targeting a dialect that's mostly compatible with a static subset of python3, but will break compatibility where necessary. In this case pattern matching, possibly elsewhere. https://github.com/py2many/v-ast

Never heard of this language, but it looks interesting. Very modern, certainly. One thing that stood out to me is that there's apparently the ability to write a bare `for` loop...? Is that just equivalent to while (true) in other languages?

It can be used in many forms, while true is one of them.

I don't have a whole lot of experience hand writing v-lang. Mostly machine generated from static python.

But I find it convenient for what it does. Golang that is less verbose, single binary for distribution and fewer tokens if you're using an agent.

GitHub.com/LadybugDB/ladybug-vlang has a CLI I recently wrote with an agent for a database I maintain.

Static python with design by contract can be a stronger specification than natural language. @antirez was discussing this on his social media today.

Re: Python: The Optimization Ladder

#88

Post by intoXbox »

Great write up and recognisable performance. For a pipeline with many (~50) build dependencies unfortunately switching interpreter or experimenting with free threading is not an easy route as long as packages are not available (which is completely understandable).

I’m not one of these rewrite in Rust types, but some isolated jobs are just so well sorted for full control system programming that the rust delegation is worth the investment imo.

Another part worth investigating for IO bound pipelines is different multiprocessing techniques. We recently got a boost from using ThreadPoolExecutor over standard multiprocessing, and careful profiling to identify which tasks are left hanging and best allocated its own worker. The price you pay though is shared memory, so no thread safety, which only works if your pipeline can be staggered

Re: Python: The Optimization Ladder

#89

Post by alisonatwork »

repple wrote: post #20

Significant AI smell in this write up. As a result, my current reflex is to immediately stop reading. Not judgement on the actual analysis and human effort which went in. It’s just that the other context is missing.

I have the same issue now. It's especially annoying when it happens while reading a "serious" publication like a newspaper or long form magazine. Whether it was because an AI wrote it or "real" writers have spent so much time reading AI slop they've picked up the same style is kinda by the by. It all reads to me like SEO, which was the slop template that LLMs took their inspiration from, apparently. It just flattens language into the most exhausting version of it, where you need to try to subconsciously blank out all the unnecessary flourishes and weird hype phrases to try figure out what actually is trying to be said. I guess humans who learn to ignore it might to do better in this brave new world, but it's definitely annoying that humans are being forced to adapt to machines instead of the other way around.

Re: Python: The Optimization Ladder

#90

Post by FacelessJim »

rusakov-field wrote: post #8

Python is perfect as a "glue" language. "Inner Loops" that have to run efficiently is not where it shines, and I would write them in C or C++ and patch them with Python for access to the huge library base. This is the "two language problem" ( I would like to hear from people who extensively used Julia by the way, which claims to solve this problem, does it really ?)

As a sibling comment mentions, yes it does. Just don’t expect to have code that runs as fast as C without some effort put into it. You still need to write your program in a static enough way to obtain those speed. It’s not the easiest thing in the world, since the tooling is, yes, improving but is still not there yet.

If you then want to access fully trimmed small executables then you have to start writing Julia similarly to how you write rust.

To me the fact that this is even possible blows my mind and I have tons of fun coding in it. Except when precompiling things. That is something that really needs to be addressed.

Post reply on HN