191–200 of 221 posts
Earlier quoted context omitted.
And slow code, yes it has cross my mind. Usually they also call Python to libraries that are 95% C code.
The hypocrisy gets even worse: the C code then gets compiled to assembly!
Earlier quoted context omitted.
Because many never used Smalltalk, Common Lisp, Self, Dylan,... so they think CPython is the only way there is, plus they already have their computer resources wasted by tons of Electron apps anyway, that they hardly question CPython's performance, or lack thereof.
Has it ever crossed your mind that they just like Python?
> His "sad truth" conclusion is that "Python cannot be super-fast" without breaking compatibility. A decent case of Python 4.0? > So, maybe, "a JIT compiler can solve all of your problems"; they can go a long way toward making Python, or any dynamic language, faster, Cuni said. But that leads to "a more subtle problem". He put up a slide with a trilemma triangle: a dynamic language, speed, or a simple implementation.…
If Julia fixes it package manager problems (does it still take a while to load imports?), I think it could become popular.
Earlier quoted context omitted.
The hypocrisy gets even worse: the C code then gets compiled to assembly!
Except C developers actually acknowledge that, they don't call libraries written in Assembly, C code.
https://github.com/OpenMathLib/OpenBLAS https://github.com/FFmpeg/FFmpeg
Plenty of assembly in those projects but no mention of it in the README. Most C projects don't acknowledge the assembly they use.
Earlier quoted context omitted.
I've been hearing promises about "better than C" performance from Python for over 25 years. I remember them on comp.lang.python, back on that Usenet thing most people reading this have only heard about. At this point, you just shouldn't be making that promise. Decent chance that promise is already older than you are. Just let the performance be what it is, and if you need better performance today, be aware that there…
I maintain a program written in Python that is faster than the program written in C that it replaces. The C version can do a lot more operations, but it amounts to enumerating 2^N alternatives when you could enumerate N alternatives instead. Certainly my version would be even faster if I implemented it in C, but the gains of going from exponential to linear completely dominate the language difference.
Earlier quoted context omitted.
I've been hearing promises about "better than C" performance from Python for over 25 years. I remember them on comp.lang.python, back on that Usenet thing most people reading this have only heard about. At this point, you just shouldn't be making that promise. Decent chance that promise is already older than you are. Just let the performance be what it is, and if you need better performance today, be aware that there…
I maintain a program written in Python that is faster than the program written in C that it replaces. The C version can do a lot more operations, but it amounts to enumerating 2^N alternatives when you could enumerate N alternatives instead. Certainly my version would be even faster if I implemented it in C, but the gains of going from exponential to linear completely dominate the language difference.
Have you ever heard of a controlled variable?
The primary focus here is good and something I hadn't considered: python memory being so dynamic leads to poor cache locality. Makes sense. I will leave that to others to dig into. That aside, I was expecting some level of a pedantic argument, and wasn't disappointed by this one: "A compiler for C/C++/Rust could turn that kind of expression into three operations: load the value of x, multiply it by two, and then stor…
Hence, Numba.
The most interesting part of this article is the link to SPy. Attempts to find a subset of python that could be made performant.
Honestly that seems Sisyphean to me. The market doesn't want a "performant subset". The market is very well served by performant languages. The market wants Python's expressivity. The market wants duck typing and runtime-inspectable type hierarchies and mutable syntax and decorators. It loves it. It's why Python is successful. My feeling is that numba has exactly the right tactic here. Don't try to subset python from…
Python and other high-level languages may actually decrease in popularity with better LLMs. If you are not the one programming it, might as well do it in a more performant language from the start.
Eventually LLMs might even generate executables directly.
Again and again, the most important question is "why?" not "how?". Python isn't made to be fast. If you wanted a language that can go fast, you needed to build it into the language from the start: give developers tools to manage memory layout, give developers tools to manage execution flow, hint the compiler about situations that present potential for optimization, restrict dispatch and polymorphism, restrict semanti…
The frustrating thing is that the math and AI support in the python ecosystem is arguably the best. These happen to also be topics where performance is critical and where you want things to be tight. c++ has great support too but often isn't usable in communities involving researchers and juniors because it's too hard for them. Startup costs are also much higher. Ans so you're often stuck with python. We desperately…