My first guess would be that your solution is faster b/c you’re using spawn, which means you’re leveraging multiple cores. The Enum.find version is sequential.
sasajuric
Author of Elixir In Action
0
egze
NobbZ
Finaly I found some time to do it. And a small typo took me half an hour to figure out the problem… I did for noun <- 0..99, verb <- 0..9 do … end…
1
xfix
I’m learning Elixir currently, and here is my mine: lib/day2.ex · master · Konrad Borowski / advent_of_code_2019 · GitLab
I’m pretty sure it can be improved, but I quite like what I have here.
2
egze
Here is mine: aoc/lib/aoc/y2019/d2.ex at master · egze/aoc · GitHub
Thanks @NobbZ for the boilerplate.
1
faried
I’m learning Elixir, and didn’t know about Enum.find; I couldn’t figure out how to do an early return from inside for noun <- 0..100, verb <- 0..100, do: ..., so I picked a terrible way to do handle it: spawn 10k processes! (I finished reading the Concurrent Programming section of Programming Elixir last night.)
What’s interesting is that I read sasajuric’s solution, adapted it, and it seems to run slower (!) than what I have: 175769 microseconds for my part2, 682567 for theirs. Maybe it’s because of all the destructuring? Both solutions in one file.
1
sasajuric
Author of Elixir In Action
This is my take. It’s not super fast (takes about 2 sec on my machine for part 2), but does the job.
The most interesting part to me is instruction execution. I define the instruction mapping, and then have a generic exec function which interprets the instruction, fetching the correct amount of arguments based on the arity.
2
bjorng
Erlang Core Team