Are you a different anon?
It's only been the two of us in this thread so far.
I saw your latest spiral on /lambda/ I really like the look of this one. I think it's my favourite aesthetically.
Thanks. Feel free to critique the code if you have cairo experience or see something that could be improved.
Some further observations:
- (extract-5 position end) is computed twice on the alternate branch of copy-path-iter!.
- The slice-length computation of copy-slice-append-iter contains an inlined version of (min 32 (- read-end read-position)). Making this explicit seems cleaner to me.
- Your code uses both (modulo read-position 32) and (logand position #b11111), which is a bit curious.
- A named let near the top level, like the *-iters, is perfectly fine. But named lets that are buried deep inside other computations, like largest-divisible-exponent-32 or the two versions of make-path, seem a bit excessive. They might be good candidates for splitting out into helper functions, like pow32? is split out.
These are still only superficial observations, mainly because your use of the continuation parameter of naive-append-vector is a nice trick that I still need to have a think on.
>>13
I just noticed something strange about copy-slice-append-iter. Correct me if I'm wrong but it seems to me that, for every leaf vector except the first, each leaf vector is looked up twice, starting all the way from the root, once by the second vector-copy! in the current round, and again by the first vector-copy! in the next round. These two calls:
(radix-ref-depth read-radix (+ read-position 32) 5)
(radix-ref-depth read-radix read-position 5)
perform the exact same work across a pair of consecutive rounds, where read-position has been incremented by either 32 or the distance to read-end. I would think that avoiding such duplicate work at the algorithm level would rate higher than whether SIMD was available.