Hacker News Reader

Comment by openasocket | Hacker News Reader

Well, one advantage the Go runtime has is the green threads are cooperatively scheduled, so switches are a lot more lightweight.

View on HN

> Well, one advantage the Go runtime has is the green threads are cooperatively scheduled, so switches are a lot more lightweight.

Switches occur on timeouts (which involve a round trip through the kernel), on I/O events (which also involve a round trip through the kernel), or on goroutine message passing. So in every case except goroutine message sends, the switches don't actually save you a trip through the kernel.

Except when the IO doesn't go though the kernel in the first place of course.

What I/O doesn't go through the kernel?

For the example if you are using kernel bypass of the network stack, which is increasingly common in high throughput/low latency applications.

Is anybody doing kernel bypass networking in go?

If you're going to bypass the kernel network stack for performance, you're definitely not going to write the rest of your code in go. The garbage collector, goroutine scheduler, and conservative compile time optimizations will totally undermine the end goal.

If you're in that world, you're using C, C++, or That if you're feeling dangerous.

I've done kernel bypass work on the JVM.

The JVM is used a lot in Fintech.

Of course it isn't the OpenJDK, rather specialized JVMs like Azul or they code using C style coding with the GC out of the out paths, having profiled the applications with tools like Java Mission Control.

These are the customers driving Oracles effort for value types, AOT compilation and JNI replacement.

Why not just use C and C++, one might ask?

In spite of all these tricks and required knowledge, salaries are lower than for C and C++ developers and overall project costs are anyway lower due to shorter development times for the other tools not available in C and C++.

Hence why Fintech nowadays is looking into languages like Pony, because they don't want to wait for Java 10, if possible.

So an area where Rust might eventually earn some friends.

FWIW, I wasn't thinking bout go.

For I/O you can buffer inside the application whether the respective file is readable/writeable or not. If it's not readable you can directly switch to another goroutine without invoking a syscall. The scheduler will later get notified by select/epoll that the file is readable/writeable, adjust the buffered status and reschedule the goroutine.

But ok, for reading you might often have a buffered state of readable while in reality it's not and you only get this information through EAGAIN on read, so you won't avoid the syscall there. For writing you most likely always would.

Couldn't you switch on timeout using some kind of CPU counter, e.g. RDTSC?

Then you're polling the system clock all the time, which is a large unnecessary throughput loss.

But that's just one instruction, highly paralelisable (I assume), as opposed to going through the kernel... Anyways, I haven't measured it, it's just an idea I had!

System call context switching is cheaper than and different from thread/scheduler context switching.

OK, but that's irrelevant in this context because Go has to context switch either way.

It can also switch on memory allocations and function calls as well. I'd expect a large fraction of the context switches come from those events and don't go through the kernel.

Reply on news.ycombinator.com