Hacker News Reader

Comment by cdoxsey | Hacker News Reader

> Basically, the Go folks want to minimize external dependencies and the web of failure that can lead to. Fixing that is a goal I heartily agree with. However, we cannot eliminate our dependency on the platform. And using system calls directly is actually worse, because it moves our dependency from something that is stable and defined by standards bodies, to an interface that is undocumented, not portable, and may change at any time.

It's also for performance reasons. Calling a C function from Go is actually quite complicated and can involve copying a lot of data. Using a syscall directly avoids that cost.

View on HN

That has got to be a total drop in the bucket compared the cost of the syscall itself.

Kernel interrupt handling is incredibly quick.

Tasking switching an the related MMU updates is slower. As you have to perform a kernel interrupt handling action just to start initializing the task switch.

Interrupt handling is quick, paging isn't.

The KPTI Meltdown fixes mean that interrupt handling _is_ paging on a lot of chips out there.

Careful. x86 interrupt handling is slow. System calls use an accelerated mechanism that is much faster.

drops add up

Not when they are 1:1 with what you are talking about, do they?

I mean, I get that across the lifetime of an application, you might see that 1% of your cost is in this somehow, but then the easier response would almost certainly be to do less syscalls, since if this is taking up 1% then the syscalls are taking up 10%+? (And that is assuming this is 10% of the syscall. Ish)

"Using a syscall directly avoids that cost."

Quoting the author of the article,

"That said, this is nothing compared to the cost of a SYSTEM CALL. System calls are measured in usec, usually 10s of them, depending on the complexity of the system call you're calling. (In some cases, such as disk reads, it can even go to milliseconds.) I'd guess on average the cost of the transition is less than 1% of the system call you're making."

The article is not accurate.

Pre-KPTI, the cost of a system call might have been hundreds of cycles total. On a modern chip, that’s ~50ns.

Add kernel code for relevant operation. A read on a pipe might be 500ns total. A read on a cached file would be similar.

Add a few hundred cycles for KPTI.

A typically function call will be tens of cycles, but with lots of copies and stack changes can easily be hundreds.

Reply on news.ycombinator.com