logoalt Hacker News

kllrnohj • 11/07/2024 • 2 replies • view on HN

> 1. No overhead from libc; minimizes syscall cost

The few nanoseconds of a straight function call are absolutely irrelevant vs the 10s of microseconds of a syscall cost and you lose out on any of the optimizations a libc has that you might not or didn't think about (like memoization of getpid() ) and you need to take on keeping up with syscall evolution / best practices which a libc generally has a good handle on.

> No dependency on libc and C language ABI/toolchains

This obviously doesn't apply to a C syscall header, though, such as the case in OP :)

Replies

matheusmoreira • 11/08/2024

> you lose out on any of the optimizations a libc has that you might not or didn't think about (like memoization of getpid() )

Not much of a big deal. These "optimizations" caused enough bugs that they actually got reverted.

https://www.man7.org/linux/man-pages/man2/getpid.2.html

  Because of the aforementioned problems, since glibc 2.25,
  the PID cache is removed: calls to getpid() always invoke
  the actual system call, rather than returning a cached value.
Get rid of libc and you gain the ability to have zero global state in exchange. Freestanding C actually makes sense and is a very fun language to program in. No legacy nonsense to worry about. Even errno is gone.
➕ show 1 reply
gpderetta • 11/07/2024

A syscall can be way less than 10us. Especially if it is not doing I/O.

➕ show 1 reply