AdventOfCode VS aoc2022

I did the same challenge this year, though I didn't use as “esoteric” languages (TeX… I love it :D), but I've made it more difficult than necessary by using the languages I'm familiar with first, before realizing this might be a mistake… I've written on my learnings on the AoC subreddit[0] and if you'd like to see my code, it's of course on GitHub[1].

0: https://www.reddit.com/r/adventofcode/comments/zwi0t4/2022_w...

1: https://github.com/d12bb/AdventOfCode/tree/main/2022

Anyways, if you're interested, here's the code. Now I'll try to get rid of all these compilers, interpreters, language servers, Neovim plugins etc. I'll never use again…

I never used Raku (or even Perl) before, but as I try to solve Advent of Code using a different language every day this year, I did today's problem in Raku. I'm quite intrigued by its Grammar feature and used it to parse the input, but found it really difficult to get working. That said, I'd like to hear from more experienced Rakuistas if what I did was even remotely idiomatic or looks just gross to your eyes. So here's my code (may be easier to read on Github):

Today's Raku: src

I'm doing different language each day, all solutions here.

It may be a nifty hash table (no, it is!:)) but the whole program runs about 12x slower on an M1 than my version where I first determine the max dimensions and simply allocate a grid of booleans... So I wonder how much the 8x8 bitset breakup could improve. But bitsets are a C++ feature. In C, like NRK: https://github.com/ednl/aoc2022/blob/main/09.c (my "startstoptimer.c" and .h are in the same repo)

I also checked lines but only after doing a rotation by 45 degrees, so the lines are straight. Compiled in C, fastest run time on M1 was 26 µs: https://github.com/ednl/aoc2022/blob/main/15.c

Same code but with preprocessed input to make it all fit into memory, runs in 7 ms on an Arduino Uno! https://github.com/ednl/aoc2022/blob/main/aoc22-15/aoc22-15.ino

Complete program runs in 463 µs on Apple M1, 2.61 ms on Pi 4. See comments at the top of the source file for how I measured. My comparison function:

Not 100% sure this is Upping-The-Ante, maybe just Other. I wanted to share some benchmark results of my solution for today, day 11 with the 10,000 monkeys, and how I got there. I think the easiest way to compare performance is to use the same hardware, and nowadays fairly common & standardised hardware might be the Raspberry Pi 4. Although, you can't buy any for years now... Best score I got when running my solution on my Pi 4 home server is 15.6 ms.

I quickly saw that I could do "item = item modulo (product of all div-test numbers)" but the implementation took me a while in C without queues or circular buffers. But that's all part of the fun for me! I didn't look for further clever optimisations because the compiled program runs in 20 ms on a Raspberry Pi 4. That was fast enough for today, I thought. Source code: https://github.com/ednl/aoc2022/blob/main/11.c

Yay, embedded software engineering!! :) Short, fast & almost no memory needed in C: https://github.com/ednl/aoc2022/blob/main/10.c or the relevant bits:

That's great, but on what hardware? My solution in C runs in 0.8 ms average (0.6 ms minimum) using hyperfine to measure 1000 runs in a Mac Mini M1. Same on a Pi 4 in performance mode: 3.6 - 3.8 ms.

Well, it took me a while to realise that in part 1 you always have to check the whole row or column because a higher tree can come at any point ... And except for skipping the borders, I couldn't come up with any sort of clever optimisation that would help reduce the O(N^2) complexity. It still runs in under 1 ms on a Mac Mini M1 according to hyperfine. Full code 52 lines without space/comments: https://github.com/ednl/aoc2022/blob/main/08.c