Top all-time · #14121
owen.cafe
Personal blog · owen.cafe/postsprogrammingsystems
owen.cafe is a personal blog at owen.cafe about programming and systems. Since 2023, 5 different Hacker News readers have linked it 13 times, most often “A faster bump allocator for rust”. No feed was found, so read it on the site itself.
Too few sampled comments (1) to say how often HN recommends it.?
Why HN links it
The linked post is about a Go function whose speed doubled after adding a print call. The one comment explains the likely compiler cause: a CMOV versus a branch decision, based on how the compiler treats branches with IO.
Summarised by Claude from a sample of 1 HN comments that link here. Each comment is marked recommending, critical or neutral (citing without judging); how this works.
Owen's personal website and portfolio
Most-linked posts?
- A faster bump allocator for rust2 people · 4 mentions · first linked 2026-06-04
- Six times faster than C2 people · 2 mentions · first linked 2023-07-06
- Speeding up tree-sitter-Haskell 50x2 people · 2 mentions · first linked 2023-08-07
What Hacker News says?
The go compiler might have a heuristic where a branch with IO is considered cold compared to a branch without. In the original, it essentially faces If <cond>: Mov Else: Noop Considering these branches unpredictable, it generates a CMOV. With If <cond>: Mov Else: Print It now considers the first branch how and the second cold, and thus branch predication valuable, and generates a branch instead. Turns out for the us…
Comment linking /posts/six-times-faster-than-c/
on “Print(“lol”) doubled the speed of my Go function”Submitted Quantifying pass-by-value overhead as a story · 116 points
HN discussionThis is pretty much `assembly language the game`: https://tomorrowcorporation.com/humanresourcemachine It's not a useful architecture, but it teaches the thought process really well, and you end up discovering a lot of optimization naturally. For this article, I'm measuring every step to see what the performance implications of the changes are, which, along with some educated guesses and some googling/reading other…
Comment linking /posts/the-same-speed-as-c/
on “Six times faster than C”Submitted A faster bump allocator for rust as a story · 3 points
HN discussionThe array lookup approach taken in part two: https://owen.cafe/posts/the-same-speed-as-c/ But taking the length of the string as a parameter is not, because that changes the problem statement (making the solution vectorizable) Also note that you'll try to read element -1 of the input. You probably want to change the `>=` to a `>`
Comment linking /posts/the-same-speed-as-c/
on “Six times faster than C”Submitted A faster bump allocator for rust as a story · 2 points
HN discussionNice! There's a part two in which I rewrote the C. I got a 12x speedup :) https://owen.cafe/posts/the-same-speed-as-c/ And as others have pointed out, you can tweak the input, then vectorize the algo, if you want to go that route. I considered this a pedagogical exercise and I sincerely hope nobody will start dropping down to assembly without a very good reason to.
Comment linking /posts/the-same-speed-as-c/
on “Six times faster than C”Submitted A faster bump allocator for rust as a story · 2 points
HN discussionThe version that's friendly to the compiler is described in part two: https://owen.cafe/posts/the-same-speed-as-c/ It achieves 3.88GiB/s I intentionally didn't go down the route of vectorizing. I wanted to keep the scope of the problem small, and show off the assembly tips and tricks in that post, but maybe there's potential for a future post, where I pad the input string and vectorize the algorithm :)
Comment linking /posts/the-same-speed-as-c/
on “Six times faster than C”Submitted Speeding up tree-sitter-Haskell 50x as a story · 2 points
HN discussionSubmitted Speeding up tree-sitter-Haskell 50x as a story · 2 points
HN discussionSubmitted Six times faster than C as a story · 2 points
HN discussionSubmitted A faster bump allocator for rust as a story · 1 points
HN discussion