Writing this benchmark code is only the first hurdle: running it is awful. Doing 100x or 150x big samples means the benchmarks basically take a full 18 hours to run. Doing the full set means it locks down my computer for 50 hours. I need to likely just turn down how much its doing...
Living disaster, ready to strike!
- danger/threat
- thephd.dev/
✨ Somehow Is A C Expert ✨ Smooches Unicode-kun 💕 Pixel Art is Cool 🎨 Banner by Bugurri and Avatar by KIING KIISMET ✨
You must log in to comment.
in reply to @ThePhD's post:
The trick we ended up using for this is running the benchmarks for a short enough time that each iteration fits in a time slice, so there's at most one scheduler interruption. This fairly neatly sorts the time results into two buckets very quickly.
Oh. That sounds like a neat trick.
I figure I have to do some OS-specific shenanigans so I can acquire the current scheduler timeslice and try to allow the runtime to be at most 190% of that?
I think we just guessed tbh, but I wasn’t involved in the details