AoC VS advent-of-code-rust

Part 1 took a bit of fiddling around debugging. I parsed the input into a list of coordinate pairs. I then found the largest X and Y value I could possibly be interested in, and then, for each X value, I checked if the column was clear, and if so, expanded it by adding one to the coordinates of all galaxies with a greater X-value (I spent quite a while trying to find a bug here - turns out that I'd messed up my conditional jump and was instead adding one to the coordinates of all galaxies with a smaller X-value - oops), and then adjusted my loop index and bounds to account for the extra column. I did the same with the Y-value. Finding the pairwise distances was a matter of, for each pair, calculating the taxicab distance. I did some fancy footwork with x86_64's SIMD instructions, doing a packed subtraction of quadwords. Alas, a packed absolute value of quadwords was something that required AVX-512, which my CPU does not support (and, in fact, most CPUs don't support - it's probably a server-tier CPU thing).

For both part 1 and part 2, I parsed the file into a set of flags - does the current space connect north, south, east, west? Is it, in fact, an actual space in the map? And is it marked as the starting space? I then converted the starting space into a regular space, but remembered its coordinates.

Part 1 involved a direct solution - for each line, I read it into a dynamically allocated array, then allocated a new array and calculated the differences between the previous array's elements, and so on until I got an array that's all zeroes. I then proceeded to extrapolate - I found the end of the list, and added the end of the previous list to this list to get the new element to add to the end of the list - I actually didn't need to save this value in new space, I could have just overwritten the old end of the list.

Part 1 was implemented pretty much following the problem statement - I chose to represent the map using a dense data structure (since, after all, RAM is cheap enough that I can ask for 26^3 * 4 bytes (~70kib) just because). I parsed the instructions and the map, but I found I couldn't zero-terminate my instructions, since I was representing left as zero and right as two (since these were actually memory offsets). I thus used 0xff - something the fullptr folks might appreciate. The map was parsed as follows - I treated each node as a base26 integer, where the first is an index into an array of pairs of words, and each word is the index that the left and right nodes lead to.

Part 1 and part 2 were surprisingly similar - for both, I parsed the cards, mapping letter cards to their rank ordering (so for part 1, t = 10, j = 11, and so on, and for part 2, t = 10, j = 1, q = 11, and so on (although I could have just modified j = 1, I guess...), and recording the bid, as a word - I decided that I would pack the input data into a qword per hand so that I could apply my qsort function that I'd already written with minimal modifications.

Part 1 and part 2 were very similar. The parsing was very standard, but then I had to do math with floating point numbers. And that involved new instructions - cvtsi2sd, for example (convert scalar integer to scalar double), and the rest of the modern SSE floating point operations. (While you could still pretend you had an 8087 and use such instructions as fmul, in practice, it's a lot nicer to use the SSE equivalents.) I then had to round everything back into integers, but I also had to fake the rounding modes "ceil-but-always-move-up-one" and "floor-but-always-move-down-one" - which lead me to the comisd (probably stands for compare like integers scalar doubles) instruction. Apparently there's a cmpsd instruction, but it returns results as a mask, which I guess might be useful for branchless operations on floating points. I didn't want to bother, and performance was not a major concern. You do get the default floor and ceil rounding modes, though - as well as truncation and rounding to even. I also had to deal with floating point constants. Floating point constants can't be inline, they must be loaded from memory, so I had to use the .rodata section for the first time.

Here's the cross-assembler with the part 1 runtime hardcoded, and here's the cross assembler with the part 2 runtime hardcoded. Both parts follow the same methodology: copy the prepared ELF header data, then copy in runtime setup code into the file. Next, output generated x86_64 for each Elvish instruction (which includes an inlined call into the runtime), finally, copy in the runtime exit code. and output the entire file.

Part 1 and part 2 were both implemented as interpreters directly interpreting the assembly code. This was the first time where we absolutely had to deal with negative numbers, so I had to write a parser that was cool with negative numbers, and an output formatter that was also okay with negative numbers (mainly for debugging). (I should add ascii-to-signed-long to the common library.) Unfortunately, I'm not willing to do OCR using assembly, so I printed out the result as pixels and manually translated that into ASCII characters. The core evaluator between the two parts was quite similar - the only difference was what happens during the cycle. With part 1, I had to sum up certain cycles. With part 2, I had to add characters to an array.

Part 1 starts by parsing the input. I first count how many steps there are (e.g. "R 4" is 4 steps). Then, after allocating an array to hold those steps, I read in the steps and expanded repeats.

In part 1, I parsed the input, first getting the size of the input (bear in mind I'm challenging myself to assume nothing about the size of the input), then reading it in. I could probably have used loop, lodsb, and stosb to write more concise parsing code. Then, for each cardinal direction, I marked the trees that were visible from that direction, and finally counted the trees that were not visible from any cardinal direction.

https://github.com/fspoettel/advent-of-code-rust best rust aoc template imo

It's Christmas time and time for Advent of Code 2023 edition. Starting from today I will try to solve puzzles in Rust and publish a post a day in which I tell my solution. My goal is not to climb the leaderboard but to use the problems to practice writing Rust code and improve my language knowledge. Copilot yes or Copilot not? It's for learning so Copilot definitely not. The solutions will be available at the following git repository, as I don't have much time to write a template from scratch, I will use the starter template available here.

If you haven't tried Rust:

Someone put together a very nice template in Rust that automatically downloads tests, solutions, creates a scaffold for the binaries, etc and submits solutions through CLI. I used this template last year to learn Rust and it got me "up and running" quickly and easily.

https://github.com/fspoettel/advent-of-code-rust

18. 👨👴 Advent of Code is a yearly event where you can solve small (but high-quality) programming puzzles in any language you want. It can be applied to any language that you are learning. You might find this, this, and this repo useful as well where they provide templates and solutions for prior years.

I know you mentioned you were using this an exercise to learn macros so feel free to ignore this, but I like using this template repository for Advent of Code. It treats each day as a separate binary, but main.rs will run through all the days.

I'm using this template. If you are familiar with Rust you could try running my code in this template to see what speeds you get. This is with the --release flag.

Great solve! Mine ended up being much more complicated since I tired to predict the part 2... Can recommend using a template so you dont have to repeat the whole cargo things, I use this one that builds templates, test and downloads input etc https://github.com/fspoettel/advent-of-code-rust