You can't get 2000x faster without actually eliminating some large percentage of the work, you just cannot. You have to find some way to get rid of 99.95% of the work you were doing.
Usually those inflated numbers come from single-thread to multi-thread comparisons, where you can fudge as much as you want by adding more cores. They claim this is a single-core to single-core comparison, so basically that means they had a heinous performance bug hidden in their code, almost certainly an n^2 behavior. If this is true 2000x is not the limit of what they could have claimed as speedup. Why not 10,000x? Why not 10,000,000x? All are equally true, and none of them could be fixed by a faithful port of the codebase from one language to another.
So I kinda read it as them being confidently, arrogantly stupid, waving around a result without seemingly having thought about what it means. I think it means they could get most of the speed without ever having had to leave Python if they just fixed one bug...
The 2000x number is based on a pathological directory in black's repo https://github.com/psf/black/tree/main/profiling which make duplicate-code really slow and a fix was done in pylint 4.1.0 according to pylint's maintainer.
>You can't get 2000x faster without actually eliminating some large percentage of the work
Yeah, exactly. That's how optimization works! Recognizing that in many cases, the work is that was being done is not necessary to produce the result you actually need, that it could have been in a different way.
This can sometimes involve adding complexity (by means of a better data structure or algorithm, e.g. a quadtree), and sometimes involve removing it (non-pessimization[0]).
That being said, it's certainly also possible to achieve a speedup by breaking things, which you are suggesting is the case here. I can't comment on that part.
I like the other commenter's information here https://news.ycombinator.com/item?id=48597915. It confirms what i suspected: the source of the 2000x slowdown is very much fixable in Python.
It's not a huge error, it just speaks to the people doing the work not having a solid footing in the concepts
Your best result is not even an order of magnitude faster, while this repo is claiming on average almost 2 orders of magnitude faster. Extraordinary claims require extraordinary evidence sort of thing.
Usually those inflated numbers come from single-thread to multi-thread comparisons, where you can fudge as much as you want by adding more cores. They claim this is a single-core to single-core comparison, so basically that means they had a heinous performance bug hidden in their code, almost certainly an n^2 behavior. If this is true 2000x is not the limit of what they could have claimed as speedup. Why not 10,000x? Why not 10,000,000x? All are equally true, and none of them could be fixed by a faithful port of the codebase from one language to another.
So I kinda read it as them being confidently, arrogantly stupid, waving around a result without seemingly having thought about what it means. I think it means they could get most of the speed without ever having had to leave Python if they just fixed one bug...