aoc2022 VS rust-mos

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

rust the compiler, hell no.

But there is an llvm-mos project to generate 6502 code and that can be used to cross compile rust code.

https://llvm-mos.org/wiki/Welcome

https://llvm-mos.org/wiki/Rust

https://github.com/mrk-its/rust-mos

It was possible thanks to great https://llvm-mos.org/wiki/Welcome project (it adds 6502 target to LLVM). Adding 6502 support to rust was easy part :] https://github.com/mrk-its/rust-mos

This is a super fun project to play around with. I'm currently trying to build a C64 sprite multiplexer in mostly straight C++ using LLVM-MOS and while it's definitely not going to be the most optimized multiplexer out there, I'm finding it most adequate performance-wise.

Whereas it's probably a long way away from being able to use this for democoding due to the mostly cycle-accurate nature of the effects, for creating homebrew games and utilities this is really quite suitable: write high-level logic and sprinkle in some inline assembly here and there for the really performance critical parts.

The code that is being generated is already quite good and (on first glance) looks better than what's coming out of cc65, for instance.

There's also rust-mos which uses LLVM-MOS to compile Rust code. It unfortunately still has some issues (e.g. [1]) but that is looking really promising as well.

Kudos to all involved :)

[1] https://github.com/mrk-its/rust-mos/issues/16

The MEGA 65 doesn't appear to have shipped yet. The best data I could find is the MEGA 65 is based on a "GS4510". The "GS4510" is compatible with a "4502", which in turn is compatible with the 65CE02. The 65CE02 uses a different manufacturing process but the same ISA as the 6502, which is supported by rust-mos and lvm-mos](https://github.com/llvm-mos/llvm-mos).

Using llvm-mos, rust-mos, a lot of time compiling compilers and support from Mariusz (the rust-mos author), I was finally able to program like it was 1982...

This fork is handy for that. It’s fun to play with, but you need to do a decent amount yourself to get it set up.

https://github.com/mrk-its/rust-mos

Thanks to llvm-mos project there is also working rust fork for MOS-6502: https://github.com/mrk-its/rust-mos/tree/mos_target, so you can target 8-bit atari and c64