A 40-line fix eliminated a 400x performance gap

Re:A 40-line fix eliminated a 400x performance gap by ot on Tuesday January 13, 2026 @07:53PM (#46610886)

You can do even faster, about 8ns (almost an additional 10x improvement) by using software perf events: PERF_COUNT_SW_TASK_CLOCK is thread CPU time, it can be read through a shared page (so no syscall, see perf_event_mmap_page), and then you add the delta since the last context switch with a single rdtsc call within a seqlock.

This is not well documented unfortunately, and I'm not aware of open-source implementations of this.

EDIT: Or maybe not, I'm not sure if PERF_COUNT_SW_TASK_CLOCK allows to select only user time. The kernel can definitely do it, but I don't know if the wiring is there. However this definitely works for overall thread CPU time.

[ Parent | on HN ]

Re:A 40-line fix eliminated a 400x performance gap by jerrinot on Tuesday January 13, 2026 @08:02PM (#46610981)

That's a brilliant trick. The setup overhead and permission requirements for perf_event might be heavy for arbitrary threads, but for long-lived threads it looks pretty awesome! Thanks for sharing!

[ Parent | on HN ]

Re:A 40-line fix eliminated a 400x performance gap by ot on Tuesday January 13, 2026 @08:05PM (#46610998)

Yes you need some lazy setup in thread-local state to use this. And short-lived threads should be avoided anyway :)

[ Parent | on HN ]

Re:A 40-line fix eliminated a 400x performance gap by catlifeonmars on Wednesday January 14, 2026 @02:39AM (#46613391)

I guess if you need the concurrency/throughput you should use a userspace green thread implementation. I’m guessing most implementations of green threads multiplex onto long running os threads anyway

[ Parent | on HN ]

Re:A 40-line fix eliminated a 400x performance gap by jerrinot on Wednesday January 14, 2026 @04:01AM (#46613882)

In a system with green threads, you typically want the CPU time of the fiber or tasklet rather than the carrier thread. In that case, you have to ask the scheduler, not the kernel.

[ Parent | on HN ]

Re:A 40-line fix eliminated a 400x performance gap by electricshampo1 on Wednesday January 14, 2026 @03:18AM (#46613608)

noob question: "add the delta since the last context switch" how do you get the time of the last context switch? is that also some other perf event?

a quick googling shows a sched:sched_switch tracepoint; maybe it is possible to filter that for this thread when you set up the perf events

[ Parent | on HN ]

Re:A 40-line fix eliminated a 400x performance gap by nly on Wednesday January 14, 2026 @04:04AM (#46613902)

Why do you need a seqlock? To make sure you're not context switched out between the read of the page value and the rdtsc?

Presumably you mean you just double check the page value after the rdtsc to make sure it hasn't changed and retry if it has?

Tbh I thought clock_gettime was a vdso based virtual syscall anyway

[ Parent | on HN ]

Re:A 40-line fix eliminated a 400x performance gap by ot on Thursday January 15, 2026 @12:08PM (#46635673)

> Presumably you mean you just double check the page value after the rdtsc to make sure it hasn't changed and retry if it has?

Yes, that's exactly what a seqlock (reader) is.

[ Parent | on HN ]

Re:A 40-line fix eliminated a 400x performance gap by mgaunard on Wednesday January 14, 2026 @09:40AM (#46616560)

clock_gettime is not doing a syscall, it's using vdso.

[ Parent | on HN ]

Re:A 40-line fix eliminated a 400x performance gap by jerrinot on Wednesday January 14, 2026 @10:07AM (#46616869)

clock_gettime() goes through the vDSO shim, but whether it avoids a syscall depends on the clock ID and (in some cases) the clock source. For thread-specific CPU user time, the vDSO shim cannot resolve the request in user space and must transit into the kernel. In this specific case, there is absolutely a syscall.

[ Parent | on HN ]