Just finished it. It was indeed really fun 
What kind of performance do you have? (when running headless). Mine takes about 12s to complete
My solution: advent/lib/2019/day13/part2.ex at master · cblavier/advent · GitHub
cblavier
0
bjorng
Erlang Core Team
I had problem with part 2 in the morning. The paddle would miss the ball and the would be lost almost immediately. It turned out that I updated the joystick state both when the score was received and when the ball was painted. Removing the update when the score was received fixed the problem.
Since I was late with posting anyway, I decided to do some clean up. I rewrote part 1 to use the same play bot as part 2, and inspired by @aaronnamba’s use of IO.ANSI I added a mix task to show an animation of game being played. To run the animation, just type mix animate.
0
bjorng
Erlang Core Team
cblavier
NobbZ
It’s 3.5s for part 2 on my office VM. Have no further data points for comparing.
Part 1 runtime is negligible.
1
cblavier
It’s worthy to mention that all puzzles don’t take the time processing time
- my puzzle is processed in 12 seconds
- @bjorng’s puzzle is processed in 8 seconds
- @NobbZ 's is processed in less than 6 seconds
Still my implementation is the slowest and don’t find any obvious improvement. I’m wondering if the process + message passing implementation for the Intcode machine is suboptimal 
0
NobbZ
My puzzle input is available in the linked repository, you coul test your implementation against my import to determine if it was my machine or your input that made the difference. I can’t test your input on my implementation on my machine before Monday though.
0
cblavier
It’s actually what I did against your puzzle (my previous post wasn’t clear).
It took 6sec on your puzzle whereas my puzzle took 12seconds.
But I’m still looking for optimization … nothing obvious yet
0
NobbZ
From a first glance over your code, pulling inputs one by one and handling them one by one seems costly.
I’m on a year’s end party of my office at the moment, but I’ll try to compare your input to mine on my home laptop tomorrow and post the result here.
1
ferd
Author of Property-Based Testing with PropEr, LYSE, & Erlang in Anger
If I remove all the sleeps, my own program took about 550ms on my input while drawing, and and about 450ms without drawing. I do handle all inputs and outputs individually and with message passing as well. I’m not sure they should be that expensive.
Looking at the source code for the computer though: advent/lib/2019/computer.ex at master · cblavier/advent · GitHub
This little bit is:
if new_output do
if output_pid, do: send(output_pid, {:input, new_output})
outputs ++ [new_output]
else
outputs
end
You end up appending more and more output as the game moves forwards because you accumulate it.
You’ll drastically speed up the program if you do [new_output|outputs] there and reverse the result when you return the list of outputs at the end of the program.
This endless suffixing is probably explaining all the time lost to rewriting and GCing terms. Reversing once at the end will ensure O(1) adding within the tight loop and a single rewrite once the program is done.
7