Besides that, Rust code is actually much easier to maintain , thanks to type system guarantees.
Besides that, Rust code is actually much easier to maintain , thanks to type system guarantees.
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...
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.
[0] Casey Muratori - Refterm Lecture Part 1 - Philosophies of Optimization https://www.youtube.com/watch?v=pgoetgxecw8
It's not a huge error, it just speaks to the people doing the work not having a solid footing in the concepts
Can't they run Pylint on itself?