I haven't nickel-posted for a few days, but I have still been writing nickel for advent-of-code! So, that means, nickel thread. tl;dr: nickel is still slow, it is not fast.

Though, first, as a random aside it turns out they do not yet have exhaustive tests for their stdlib. As shown by an update making a stdlib function reliably error: github.com/tweag/nickel/issues


My main realization since last time was that function calls appear to have a cost based on their call depth, and that dwarfs basically all else once you hit several hundred calls deep.
Which, given that it's a functional language, even just finding the max of an array is typically a `fold` operation recursive to the depth of the array. There's no TCO or anything to make it efficient.

· · Web · 1 · 0 · 0

That realization has let me write a foldl that has a call stack depth of 2, rather than O(n), which honestly has solved the performance issues for half the days so far

Unfortunately, just having a faster foldl has not been enough to make day11 complete.
At this point, my day11 solution uses all my ram (64 gigs) for something like 25 "rounds", and part2 requires 10k rounds. I feel like this really might be the point where I have to start improving the interpreter itself since that memory usage is just ridiculous.

I'm going to try and get it to work without interpreter changes a bit more since I do have some ideas to try still...

Sign in to participate in the conversation
Wobscale Social

wobscale.social - a server for friends of the Wob, affiliated with Wobscale Technologies