Hacker News Reader

Comment by jongraehl | Hacker News Reader

> First of all, they're testing on MacOS, which is not going to be the platform they're actually using for the server code. The backends can be very different.

Unless you have evidence that Go has MacOS-only bugs, this is meaningless speculation (though I agree that it's possible that there's no problem on Linux and that people don't generally run mac servers, I'm not sure why we should privilege your hypothesis).

Agreed about GOMAXPROCS=4 - that seemed questionable to me (I don't know what it does, precisely, but I don't see a 4-anything limit in the Scala code).

View on HN

Thanks to parent (after edit) for really testing. It turns out that he was right that Go on Mac is substantially worse than Linux - my bad. Maybe the Go lib authors didn't put much effort into reading the subtly different BSD/Darwin vs Linux syscall semantics.

To explain the Nagle algorithm's irrelevance to this case, we have to understand how it works. It doesn't delay any writes once you read. It only affects two consecutive small writes (my memory was fuzzy so I checked http://en.wikipedia.org/wiki/Nagle's_algorithm ). Odds of preemption between the client's write and its read seem small, so it shouldn't matter whether you Nagle or not.

Yeah, I always seem to forget the exact details of Nagle (probably because every project I've worked on just turns it off). Write-write-read is the killer, I guess-- just doing a small write followed by a small read, or vice versa, should not be affected by Nagle. So the results I got make sense.

Re: MacOS, I do know that some of the Go developers use Macs as their primary desktops. So I don't think they neglect it, but given that they're targeting the server space, it makes sense to optimize Linux more.

I still haven't seen any really good explanation of these results. I don't buy the argument that the JVM is providing the advantage here. The main thing that the JVM is able to do is dynamically recompile code, and this shouldn't be a CPU-bound task.

It's also hard to accurately profile Go programs on OS X because of bugs in it's now quite stale kernel. Specifically SIGPROF on OS X isn't always sent to the currently executing thread. Afaik this isn't a problem on newer FreeBSD kernels.

Reply on news.ycombinator.com