> This implementation of A* running on SBCL outperforms even C++ implementations, at least the ones for which I was able to find performance numbers (1, 2). You can have a look at impressively sleek assembly produced by SBCL for FIND-PATH function here.
Beating similar C++ implementations in performance seems at least a bit noteworthy, as C/C++ is often held as the language(s) to chose for best performance.
The "c++ implementations" are two stack overflow answers. I don't think the comparisons are representative of the performance of implementing A*:
1 - Is an innefficient and obfuscated BFS. It has no heuristics. (The lisp benchmark is using Manhattan distance. You can think of it as comparing walking blindfolded on a maze vs having a GPS that tells you how far you are from the exit)
2 - Is a person claiming numbers on a specific instance of a problem that was tested, without showing any code or details on what heuristics were used
>the implementations are two stack overflow answers.
This is pretty uncharitable. One of the "answers" is just a link to the authors research paper. Not like it's just something they quickly threw together for some SO post.
It is a bit strange that they link to the SO post and not the paper though.
I can't tell you how many times I've caught juniors trying to pass off unmodified SO answers as their own work. It's rather alarming to me because they have this attitude that popular things can't be wrong, and public things don't need attribution. But knowing, that people often approach life in this way, is half the battle.
Lesser known is that SO content is generally under a CC-BY-SA license, which means not only attribution, but also "share-alike", which generally means releasing derivative work under the same license...
There is significant legal risk if your juniors are pasting non-trivial code from SO into your codebase verbatim...
I guess the proof is in the pudding. What C++ implementations (with any benchmark figures published) you know about that would beat the one in this submission?
It’s also notable that the core algorithm is not a function, but a macro. That means that you end up with an exact representation of the algorithm to the constraints as defined, instead of a general purpose algorithm with parameters.
I imagine this could be done with C++ templates as well, I’ve just never used them myself.
But this gives the compiler ample opportunities to optimize, since the code is specific to the desired domain. It also hides a bunch of the clutter that typically accompanies optimized Common Lisp code with all of the declares, declaims, and type specifiers.
I was curious too, so I have ran the included benchmark for a 500x500 matrix and my naive Kotlin A* implementation runs faster on the same input. So what are we missing here?
