pqueue VS aoc2021

This limitation did give me an excuse to implement Dijkstra's algorithm from scratch, which was fun; it also allowed me to play around with the pqueue library, which is very convenient although also imposes its own set of constraints that require the user to have a good amount of foreknowledge about the data they plan to insert into the queue. Since I didn't have that for this problem, I chose a pessimistic heuristic that doesn't seem to impact performance much for the data sizes we're dealing with here.

I've done every year in Haskell (2015 2016 2017 2018 2019 2020 2021), and so have several other people such as /u/glguy. I don't see if /u/mstksg has anything published for 2015 but they've done 2016 2017 2018 2019 2020 2021 along with some pretty good writeups, I recommend checking those out.

I ran my own benchmarks for a whole ton of code at https://github.com/ephemient/aoc2021 on both Linux x64 and macos x64, and ended up disabling Kotlin/Native because it was varying between 10x and 100x slower than Kotlin/JVM, eventually timing out on CI. The generated code may be reasonable thanks to LLVM, but the runtime certainly is not.

Took a while for me to get around to completing this in Kotlin, Python, and Rust as well, since I was working on optimizing other solutions, but I finally made it.

So I switched tacks and implemented this in Kotlin, where mutation is easier. First version was brute-force with duplicate state avoidance (checked before the state explosion at every input), which worked quickly enough for part 1, but ran into OOMs for part 2. Once I replaced the HashSet with a custom LruSet (and later a simpler CacheSet which simply overwrites on hash collisions) it ran part 2 in a few minutes. I then ported this into Haskell.

Haskell 1171/339

Kotlin, Python, and Rust solutions are the same solution but much uglier.

I'm doing the same cached recursion in Kotlin, Python, and Rust.

Haskell 621/603

Haskell 258/240

Haskell Kotlin 622/1185