I like this author's work on fast game structures for Lisp, shows what you can do if you're willing to do a bit of work on explicit types and so on. It's not obvious from the readme but the trivial-benchmark code includes details like time spent in the garbage collector (0 for this) and memory allocated, not just wall clock time. If he wants to do more interesting benchmarks, a standard set to use includes https://movingai.com/benchmarks/grids.html which includes some maps from real games.
It's quite a bit faster than my Lisp version, at least, though mine's an unoptimized (lots of lists) incompletely ported C++ version. Tempted to dig out the C++ version and compare since it was pretty fast... I originally ported it to make a joke about a vtuber's long neck: https://pbs.twimg.com/media/FAJQkskVQAoiGlT?format=png&name=... (Edit: screenshot from C++ version: https://www.thejach.com/imgs/visibility_with_astar.png Note how the shorter path would be going through the central chamber, but visibility is high there, so it goes down the corridors. Original had lots of extra features like fog of war, visibility tests/terrain analysis, smoothing and rubber-banding, a Floyd-Warshall implementation...)
My senior design project required us to use two rovers running FreeRTOS with sensors of our choice to do something interesting. We also had a requirement of using a very basic computer vision camera and wireless communications. We ended up making a pacman game with one ghost rover and a pacman rover. Pacman was controlled via a PC while the ghost was given pacman's position from a CV camera above the play field and implemented A* (which me and another teammate were just learning about in our Intro to AI class). It was really fun and we got some extra points for tying in something from another class which was cool.
> 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?
It's quite a bit faster than my Lisp version, at least, though mine's an unoptimized (lots of lists) incompletely ported C++ version. Tempted to dig out the C++ version and compare since it was pretty fast... I originally ported it to make a joke about a vtuber's long neck: https://pbs.twimg.com/media/FAJQkskVQAoiGlT?format=png&name=... (Edit: screenshot from C++ version: https://www.thejach.com/imgs/visibility_with_astar.png Note how the shorter path would be going through the central chamber, but visibility is high there, so it goes down the corridors. Original had lots of extra features like fog of war, visibility tests/terrain analysis, smoothing and rubber-banding, a Floyd-Warshall implementation...)