Hacker News

points by ActorNightly 2 days ago | 0 comments

I mean, I have had great success with prototyping stuff in python, then letting an llm translate it to C. My 3090 with Gemma4:31b does this very well with a few guidelines.

Dunno how much investment is needed into language optimization anymore.

[–] 14113 2 days ago

That works well for greenfield code, but if working on compiler optimisations has taught me anything, it's that there is a lot of legacy code out there in the world that would benefit from re-compilation with optimisations - but would be very difficult to re-write for speed (regardless of whether the work is done by a human, AI, or other machine tool). JIT compilation fits very nicely in this niche, as it means that existing Python projects can get (theoretically) better performance without re-writing.

[–] grep_it 2 days ago

I've had good success with just using mypyc (https://mypyc.readthedocs.io/en/latest/introduction.html) on typed python code.

[–] nomel 2 days ago

> on typed python code.

A fairly massive undertaking for existing code, which jit was supposed to be useful for.

[–] EdwardDiego 2 days ago

You can use static type analysers and runtime type profilers to add type annotations to a legacy codebase, but the interesting bit would be if you're built on top of a large untyped codebase you don't control like, say, Django, how far it can go.

[–] zahlman 2 days ago

I would imagine that the LLM has a much easier time adding correct type annotations to old Python code than it does translating it to C.

[–] EdwardDiego 2 days ago

In my experiments with this, maybe, sorta, it'll do some AST stuff then it'll go "dang this shit is dynamic AF" then suggest a static type inference tool, then a runtime type profiler.

Which honestly, is the right approach.

[–] lenerdenator 2 days ago

People have been calling Python a "prototyping" language for decades. I'd be interested to see how many Python projects ever actually get rewritten in a more performant language. My guess is, up until the last five years that was almost never done. Even with LLMs to help, is that the best use of your tokens and humans' time? It doesn't add a feature. It could conceivably cut costs after enough time, but only if done correctly.

[–] zahlman 2 days ago

> My guess is, up until the last five years that was almost never done.

Because having just the hot loop in the performant language is often deemed good enough. And there's tons of Python code out there where the "hot loop" is already automatically in C (the various operations implemented in C by the runtime) or where you can get close enough e.g. with Numpy. Consider that things like Pygame can exist; for a lot of the games people want to make, the only thing that really needs to happen anywhere near "bare-metal" speed is blitting.

[–] ActorNightly 2 days ago

> My guess is, up until the last five years that was almost never done.

It was done plenty. Just with extensions to python like numpy and opencv. There is no reason to translate everything versus just the critical pieces.

[–] nrawe 2 days ago

Doing it currently, Python to Go. Early indications are a 50-98% increase in speed (e.g. one testcase went from 26hrs to 30mins) for network/CPU heavy workload. Conversion via Qwem, lots of testing needed but compute savings will be worth it.

[–] mynegation 2 days ago

Did you mean “50-98% decrease in running time”? Just calculating from your 26hrs to 30 mins seems to imply so. In terms of speed that translates to 100% to 5100% increase in speed.

[–] nrawe 1 day ago

Yes, sorry, typing fast - we knew Go would be faster but not quite on that scale.

[–] mcepl 1 day ago

Where you using standard optimized libraries (e.g., NumPy for numerical computation) or did you do everything in Python? This kind of increase of speed seems to indicate extremely sloppy Python programming.

[–] gf000 2 days ago

Why not go with something like graalpy first? That's much less risk in terms of "we end up slightly changing behavior"

[–] nrawe 1 day ago

It's the same level of testing for us for either Python2->3 or Go (it's a legacy code base, low automated coverage).

Conversion is now (somewhat) easier, the testing will be the slow part. For the speed improvements, which we also need for a migration from on-prem to cloud, it's a no brainer vs the other options at our disposal (like GraalPy).

[–] mring33621 2 days ago

Agree with the general workflow: prototype with an easy-to-read language then port to lower-level, faster language