4 ms·

How much of a performance benefit does the average application get from "futex"? Are there some workloads that are more futexable than others?

yxhuvud 3y ago
This question as stated make very little sense as futexes are mostly used to implement lock functionality. As such, they typically have overhead but provide correctness in a multi-threaded environment.
saagarjha 3y ago
They make locks faster. That’s how a typical developer will interact with them, anyway.
- kprotty 3y ago
  A spinlock can be conditionally faster than a lock with uses futex, but it doesn't scale. Futex is really meant to provide an efficient way to block and unblock threads. One could use FUTEX_LOCK_PI to have it actually implement a lock, but that's a separate argument/edge-case.
  - lathiat 3y ago
    This has varied over time depending on kernel implementations, CPU core count, number of threads, etc. Some relevant reading: https://matklad.github.io/2020/01/04/mutexes-are-faster-than-spinlocks.html https://matklad.github.io/2020/01/04/mutexes-are-faster-than...
phendrenad2 3y ago
Wow, I was genuinely curious about this, but I see curiosity is met with downvotes now.
- dan-robertson 3y ago
  I don’t think it was particularly fair. The reason is probably that the question was poorly formed: it’s like asking how much of a performance benefit an application gets from "read" (not exactly like that; you could implement locking without futexes, it would just typically be worse, potentially by a lot, and doesn’t really work in as many cases). It also isn’t really the topic which should really be the new api rather than current futexes, though that sort of thinking doesn’t really stop anyone. A better question to ask might have been for examples of cases improved by the new api. (Or rather by the new features that can be added thanks to the new api). An example improvement is that by having smaller futexes (8-bit instead of 32-bit) you can fit more in a cache line which could matter for some applications, I guess.

yxhuvud 3y ago

This question as stated make very little sense as futexes are mostly used to implement lock functionality. As such, they typically have overhead but provide correctness in a multi-threaded environment.

saagarjha 3y ago

They make locks faster. That’s how a typical developer will interact with them, anyway.

kprotty 3y ago
A spinlock can be conditionally faster than a lock with uses futex, but it doesn't scale. Futex is really meant to provide an efficient way to block and unblock threads. One could use FUTEX_LOCK_PI to have it actually implement a lock, but that's a separate argument/edge-case.
- lathiat 3y ago
  This has varied over time depending on kernel implementations, CPU core count, number of threads, etc. Some relevant reading: https://matklad.github.io/2020/01/04/mutexes-are-faster-than-spinlocks.html https://matklad.github.io/2020/01/04/mutexes-are-faster-than...

phendrenad2 3y ago

Wow, I was genuinely curious about this, but I see curiosity is met with downvotes now.

dan-robertson 3y ago
I don’t think it was particularly fair. The reason is probably that the question was poorly formed: it’s like asking how much of a performance benefit an application gets from "read" (not exactly like that; you could implement locking without futexes, it would just typically be worse, potentially by a lot, and doesn’t really work in as many cases). It also isn’t really the topic which should really be the new api rather than current futexes, though that sort of thinking doesn’t really stop anyone. A better question to ask might have been for examples of cases improved by the new api. (Or rather by the new features that can be added thanks to the new api). An example improvement is that by having smaller futexes (8-bit instead of 32-bit) you can fit more in a cache line which could matter for some applications, I guess.