Seems near the 100,000 node mark, the vector craps itself? I keep
getting "heap use after free" errors here when trying to access the
allocator vector. Disabling fsan just leads to a segment fault near
the same point.
I think we might need to introduce our own vector :)
Also fix this really weird slow down we get from doing direct mutation
to a state.allocator.get_ref (i.e. a Node by reference). Maybe the
compiler just can't inline that instruction? Regardless, this patch
fixes the slow downs!
Arranges a thread set, draws based on draw_state. No need to lock the
mutex since drawing should only require reading. Still has a timer in
case we need to do timed checks.
Pauses until state.pause_work is false (checking every
THREAD_PAUSE_DELAY), then performs an iteration. Quits when
state.quit_work is true (based on loop). Generally delays itself by
THREAD_GENERAL_DELAY.
Our threads need to negotiate access and mutation to the two
resources - we don't want them treading on each others toes when
generating new child nodes /or/ when trying to remove/add work to the
queue. The former situation is particularly worrisome due to how weak
the indexing system is with the allocator.
conflicts with prev code base.
Also std::optional doubles the size of the underlying type.
horrifying! I don't want to have to give 16 bytes over for something
that could be embedded in the 8 bytes of the u64 directly. I'm
thinking we could just use i64's instead, sacrificing that top bit to
indicate if the value is present or not.
The left, currently processed (centre) and right fractions are
returned by iterate. This allows us to see exactly what fractions
have been generated/worked on in every iteration.
One God structure which will hold all the necessary state, ensuring I
only need to compute stuff like bounds at most once, better than
computing it on every draw (which is WAY slower at scale).
Using a stack or queue, we can replace a function recursive tree
traversal with a single call. A stack would make it a DFS while a
queue would be a BFS. Since there's only ever two children, and at
high iteration counts we're getting quite large depth, it would be
best to do a DFS, hence the stack.
Draws the current node by converting its norm value (which is in
(lower, upper)) to a screen value, drawing a line there.
It then recurs on the children of the node.
