Hacker News new | ask | show | jobs
by Ragnarork 404 days ago
$20K sounds very low for the effort and expertise that are demanded here in my opinion. It would be quite a steal to bring this to the same level as the state of the art (which, correct me if I'm wrong, but I believe is dav1d?) for only that sum.
4 comments

My reading is this isn't for random engineers but experienced performance engineers with optimized toolchains who can tackle this efficiently. For someone with the right setup, this is likely straightforward work.

It's similar to job descriptions written for specific candidates they plan to hire. The question shouldn't be "why is this bounty so low?" but "what toolchain makes $20K reasonable for someone?"

Performance work in my experience has been largely organizational friction: running projects in various conditions, collecting evidence maintainers accept, maximizing that limited slice of attention people give my CLs, getting compiler improvements merged. These coordination tasks have become much easier to automate with LLMs (e.g., analyzing maintainer comments to understand cryptic 1 line feedback, what are they actually looking for, what do they mean).

My guess is there's an engineer who's either optimized their feedback cycle to under an hour through specialized tooling (more arrows) or is much better at finding the right signal the first time (more wood). I'd like to understand what tools enable that efficiency.

I assume they're hoping to nerd snipe someone
And they did it well. If I was still a student without a family, I'd sink an unreasonable number of nights into this.
It's more likely they will end up shotgunning sloppy AI PRs.
Yes, but you left many excellent candidates.
Purchasing power parity strikes again... There are places in EU where that is 6 to 12 months of pay for a programmer.
Programmers in EU who have the skills to do this type of work can likely charge much more than that for 6 to 12 months.
Absolutely. If you don't know dav1d, it's easy to overlook the complexity here.

There is a reason for this sentence: > « The dav1d and rav1d decoders share the exact same low-level assembly code optimizations—you cannot modify this assembly ».

So, it, kind of, makes the work easier, but it stills very complex I think.

The reason for that disclaimer should be obvious, any improvements to the assembly code would also benefit dav1d in c, therefore the rust code still remains worse off by comparison.

I’m sure both the dav1d and dav1d communities would appreciate improvements to the assembly code, but the goal of this contest is to improve the rust implementation only.