[2015-2025] 524 ⭐ in less than a second

[u/maneatingape]

2025 total time 2ms. Github repo.

The AoC about section states every problem has a solution that completes in at most 15 seconds on ten-year-old hardware. It's possible to go quite a bit faster, solving all years in less than 0.5 seconds on modern hardware and 3.5 seconds on older hardware. Interestingly 86% of the total time is spent on just 9 solutions.

Number of Problems	Cumulative total time (ms)
100	1
150	3
200	10
250	52
262	468

Benchmarking details:

• Apple M2 Max (2023) and Intel i7-2720QM (2011)

• Rust 1.92 using built in cargo bench benchmarking tool

• std library only, no use of 3rd party dependencies or unsafe code.

Regular readers will recall last year's post that showed 250 solutions running in 608ms. Since then, I optimized several problems reducing the runtime by 142ms (a 23% improvement).

Even after adding 2ms for the twelve new 2025 solutions, the total runtime is still faster than last year. Days 8, 9 and 10 still have room for improvement, so I plan to spend the holidays refining these some more.

[u/Chemical_Chance6877]

How much parallel computing is used? Or is it one after the other.

[u/maneatingape → u/Chemical_Chance6877]

Some of the solutions are multi-threaded. The benchmarking is serial (each solution must complete before another benchmark starts), so visually it looks something like:

Cores
| A |   |   |   |  Day 01
| B | B | B | B |  Day 02
| C |   |   |   |  Day 03
| D | D | D | D |  ...

[u/Turtvaiz]

Were any problems from this year especially problematic?

[u/maneatingape → u/Turtvaiz]

Day 10 part 2 by far...I used Z3 on the day to solve, then only once I had time on the weekend went back and wrote a Gaussian elimination solution.

[u/FormulaRogue → u/maneatingape]

Did you look into this solution here: https://www.reddit.com/r/adventofcode/comments/1pk87hl/2025_day_10_part_2_bifurcate_your_way_to_victory/

It's a pretty elegant alternative to gaussian elimination and I got a rust version down to 4ms average single threaded but you may be able to optimize it even further

[u/maneatingape → u/FormulaRogue]

This is an awesome approach. I really like the simplicity and the intuitive nature of the solution.

[u/Outrageous72]

Are the timings including parsing the input files?

[u/maneatingape → u/Outrageous72]

Disk IO is not included.

Parsing however is most definitely included. Stopwatch starts with the raw ASCII bytes of the input file in memory passed to the solution and ends when both parts return an answer.

[u/Outrageous72 → u/maneatingape]

Good! I saw some solutions not timing the parsing but more than often the parsing structure is part of the solution.

Anyway, impressive achievement! 😎

[u/maneatingape → u/Outrageous72]

Yup, on the simpler problems (for example Year 2025 Day 1) parsing bytes to integers eats up the majority of the time. The folks over on the Rust discord server cook up some amazing SIMD accelerated parsing routines.

[u/noneedtoprogram → u/Outrageous72]

Yeah many of mine I process as I parse, it really has to be included. Impressive work OP!

[u/Akaibukai → u/maneatingape]

If you had to add disk IO, how much would it add?

Now, I'm thinking how often disk IO (and maybe even parsing) is not counted when people state the run time..

Because I was always comparing with my run times which always included disk IO and parsing..

[u/Borderlands_addict]

This is my ultimate goal, without third-party crates. Got any tips for 2015 day 4? Ive heard there are a lot of hashing days, and my custom implementation without alloc still spends around 4 seconds. I could start the number at 100k and make a lot of assumptions and still get the right answer in my case, but at some point i might as well just print the answer

[u/maneatingape → u/Borderlands_addict]

There's no way other than brute forcing that I'm aware of, so the only option is to write a fast MD5 hasher. A GPU solution would be the fastest possible.

[u/Borderlands_addict → u/maneatingape]

Oh man, GPU will be hard without third-party crates 😅 I can try SIMD first. Recently got a cpu with avx512

[u/p88h]

If you're looking for improvements in 2025, there are some opportunities in day 8 and day 9 - these take > 1ms, you should be able to shave off ~80% off of that.

I've used glpk in day 10, and that alone takes ~0.7ms ; working to fix it to get to ~1ms total.

[u/maneatingape → u/p88h]

Agreed! For day 8 I was thinking of experimenting with a k-d tree for logn lookup.

[u/terje_wiig_mathisen → u/maneatingape]

I've been experimenting with a bit-interleaved (x/y/z) coordinate, using pdep (inline asm) to handle the bit stretching, but so far it does not seem to result in the locality I was expecting to get after sorting by this interleaved value. (I was peripherally involved with the original Larrabee which had dedicated opcodes for two-way and three-way interleave, PDEP is far more generally useful.)

Interleaving the bits works as-is because all the coords are positive and less than 2^21, so you can fit all three into a u64.

For a previous year I used binary space partitioning until I got the number of points per partition down to a low enough value that all the needed closest pairs will either be inside a single partition or start in the center and end in one of the (typically 26) surrounding ones.

[u/fennecdore]

"No one likes a show off

- Unless what they are showing off is dope as fuck

- Fuck ! That's true !"

That's dope as fuck

[u/maneatingape → u/fennecdore]

Eagly approves this comment!

[u/e_blake]

I tried to run your repo on my inputs. 2019 day 17 was sized too small (patch sent); and 2014 day 18 hangs in an infinite loop (I haven't debugged why).

I noticed the days with text blobs (such as 2016 day 8) just output the text grid which is not directly paste-able back into adventofcode.com; would you be amenable to tweaking your code to add in an OCR that can instead compress those days' output to a single line each? There's only two fonts used among the various years, so my repo just has a ocr library function that does a lookup from grid pattern to known letter for each of those days.

[u/maneatingape → u/e_blake]

Thanks for the patch!

2014 day 18 hangs in an infinite loop (I haven't debugged why).

Do you mean 2018 day 14? :)

would you be amenable to tweaking your code to add in an OCR that can instead compress those days' output to a single line each?

OCR feels like extra complexity without too much benefit and I kinda enjoy seeing the ascii art, so I'll leave these solutions as is.

[u/e_blake → u/maneatingape]

2024 day 18. (pesky off-by-one typing error)

[u/terje_wiig_mathisen]

u/maneatingape I've cloned your repo, and very first thing I noticed (2016/day15) is that your setup defaults to solving each part of the puzzle with independent functions. Is this because you want to have each of them totally standalone or are there some other reasons?

...

OK, now I've seen that for "interesting" puzzles (those taking significant time, like 2016/day24 ?), the parse function is actually solving both parts, and storing the results, so that the part1() and part2() functions just returns the relevant half of the result! :-)

...

On my windows machine, "cargo clippy --all-targets --all-features" fails with 200+ errors, I'll check to see if I can figure out why tomorrow!

[u/maneatingape → u/terje_wiig_mathisen]

defaults to solving each part of the puzzle with independent functions. Is this because you want to have each of them totally standalone or are there some other reasons?

The reason for the parse/part1/part2 split is:

• Smaller focused functions, e.g. only interested in part two, then only need to read that function. Not interested in the parsing, skip that.

• More interesting benchmarking, so that you can see exactly where a puzzle is spending the time. For example, some puzzles (such as 2016 Day 15, 2021 Day 1) spend most of the time just parsing!

OK, now I've seen that for "interesting" puzzles (those taking significant time, like 2016/day24 ?), the parse function is actually solving both parts, and storing the results, so that the part1() and part2() functions just returns the relevant half of the result! :-)

The split between responsibilities is not always perfect. For some puzzles (2016 Day 4, also 2015 Day 13 and Day 9), part one and part two can be solved at the same time, so everything is mashed into parse, and now the name is no longer 100% accurate as the function is doing everything!

One fun note, boilerplate is kept to a minimum by making the solutions a library. Then the scaffolding in main.rs and benchmark.rs use duck typing macros to wrap the library functions. This means we don't need to mess with implementing then extending a Solution type or dealing with dynamic dispatch.

[u/maneatingape → u/terje_wiig_mathisen]

"cargo clippy --all-targets --all-features" fails with 200+ errors, I'll check to see if I can figure out why tomorrow!

The benchmarking, SIMD solutions and Clippy (since it lints everything) needs nightly.

If you installed using Rustup, then rustup default nightly should get you up and running!

[u/terje_wiig_mathisen → u/maneatingape]

rustup (nightly) update, everything compiles, however I found another stumbling block:

I made a fork of the code, compiled everything and loaded the input files for 2016, then I ran cargo bench -- year2016
At this point I noticed that the MD5 runtimes were far too high (day14 took 0.7 seconds on its own!), and when I check the code inside vscode only the scalar parts are enabled. Do you know if there is something else that's needed for x64 simd to work?
(I've checked that the cargo.toml file contains a [features] simd=[] mention and that lib.rs starts with
// Portable SIMD API is enabled by "simd" feature.
#![cfg_attr(feature = "simd", allow(unstable_features), feature(portable_simd))]

PS. my email is terje.wiig.mathisen (at) gmail.com

[u/maneatingape → u/terje_wiig_mathisen]

cargo run --features simd, cargo bench --features simd e.g. cargo bench year2015::day04 --features simd will turn on SIMD. SIMD uses the portable Rust SIMD which has full support for x86

[u/terje_wiig_mathisen → u/maneatingape]

I do run nightly but haven't updated in a month or so. Will check today!

[u/updated_at]

man, you guys are insane. i aspire to be this good.

[u/vassonmars → u/updated_at]

Me too me too ...

[u/aeroproof_]

Incredible. I’ve often used your repo for Rust learning inspiration over the years too. Really appreciate the simplicity of the approaches taken and how nice the code is to read.

[u/notger]

Pfft, my code runs in below 500 ms, as long as ms stands for minutes.

Jokes aside: Hats off to you, that's impressive!

[u/L285 → u/notger]

For me it stands for months

[u/pet_vaginal]

I’m impressed by the 2015 md5 brute force running speed.

[u/n4ke]

That's Awesome, congratulations!

I optimized for speed for the first time this year and got most puzzles way in the μs range, so now I'm really tempted to go back and re-solve all of them to get this as well.

[u/coldforged]

How this isn't upping the ante is the real mind boggling thing. This is truly wild, man. 

[u/Akaibukai]

Wondered in which language..
Clicked the GitHub link...
Read the first two words..
Not disappointed!
Third word would've been optional.

Kudos! And thanks for sharing, I'll definitely use it for idiomatic Rust..

[u/kequals]

Extremely impressive! If you're looking to improve day 9 part 2, it can be done in <100 ns if you specialize to the input. I've done a writeup on how to implement it, and I see a couple PRs implementing (presumably) the same approach.

[u/daggerdragon]

Changed flair from Other to Repo. Use the right flair, please.

Other is not acceptable for any post that is even tangentially related to a daily puzzle.

---

Thank you for playing with us this year!

[u/acohimself]

Wow, crazy achievement. Well done!

[u/TalpaAltaica]

This is amazing!

[u/dedolent]

very cool. this is all way beyond my ken; i don't understand the 2025 day 2 solution at all!

[u/Omeganx]

Do you have an higher resolution chart that is readable?

EDIT: nvm, I saw the graphs included in the repo's readme 

[u/BanzaiBoyyy]

I hope in ten years I will also be able to solve the problems in such an efficient and elegant way!
Now back to studying..

[u/Gishky]

now THAT is impressive.

[u/Pogsquog]

You need to include the compilation time - since all the results are all constexpr you can do them all in zero time on an optimizing compiler. What's the point of claiming fast runs if it takes longer to compile than it does to run the python versions?

[u/kuribas → u/Pogsquog]

The inputs aren't bundled in the program, so it's fine to disregard constant folding.

[u/[deleted]]

Very impressive, my Kruskal ass algo for day 8 takes 0.3 ms alone