Comment by agentS | Hacker News Reader

Comment by agentS | Hacker News Reader

Parent Full thread

> What's changed in the last decade?

The nature of the problems we are trying to solve, and the hardware we are solving them on.

> But yeah in general the C interop is very simple in most languages.

You're not taking into account the fact that the C code cannot be allowed to block the main loop of the program; as is true in any event driven system. Yea, other programming languages might not have to deal with concurrency issues, either by ignoring threading, giving up on an asynchronous system, or giving up on C interop; none of which seem like a worthwhile sacrifice. What is your problem with this implementation technique? It's performant in practice, and its not in your face when actually writing code. This is not complexity you have to worry about. It happens "behind the scenes" as it were.

Go might be challenging to search for, but you're not writing search queries, you're writing posts about programming. It's pretty unambiguous as far as I'm concerned.

And fyi, I've never downvoted you. I think with the increasingly desperate tone in your writing, its not hard for people to realize that you're just hating on Go, and at least the responses to your misinformation are educational, and often interesting.

> the hardware we are solving them on

The increase in cores, NUMA now being pervasively inescapable, and context switching becoming cheaper, actually makes this problem worse for M:N threading.

I don't have a problem with Go using M:N threading, but we must also be honest that something is being given up in order to gain something else; Go has a nicer programming model, but its performance envelope shrinks and becomes less predictable.

It may not be a victory across the board, but it certainly isn't a loss across the board. That's all I'm saying.

Let me answer some of your points more specifically: NUMA is a concern, but with some work on the schedular to give goroutines slight affinity for threads, this can be largely mitigated. This could be as simple as a scheduler policy like `take the first queued goroutine that previously executed on this thread, looking upto 5 into the queue, otherwise take the first one` instead of `always take the first one`. The difficulty with this strategy is you could experience starvation of goroutines, and there are a ton of other complexities, which is why the current scheduler is so simple. I believe this will get better...

Context switching isn't the issue with threaded implementations of servers. Writing a server with a thread per connection is a bad idea because of the memory requirements. 1000 connections will lead to gigabytes of memory in use.

I don't think Go's performance envelope has shrunk or become less predictable, IMO. I think what we've given up is control over what threads execute what goroutines, essentially, the NUMA argument above. This will hopefully get better with time.

> less predictable

Alas, it is, because there's no communication between the kernel scheduler and the user-space scheduler. The resulting interaction has non-intuitive results.

Here's an old paper about some of the measured consequences: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50....

> I think with the increasingly desperate tone in your writing, its not hard for people to realize that you're just hating on Go, and at least the responses to your misinformation are educational, and often interesting.

I get exasperated is because you guys rarely ever back up your claims. For instance, the response I get to what changed is 'things'. What things? Did synchronization between threads get 100x more expensive? Does unpredictable blocking like from page faults no longer happen? Are real time and consistent scheduling no longer important? What 'nature of problems' changed?

> You're not taking into account the fact that the C code cannot be allowed to block the main loop of the program; as is true in any event driven system.

Why can't the C code block? Because they do their own M:N threading and segmented stacks. Why do they do that? To run on 32-bit without complications. That's exactly the point I've been making.

Why in 2009+ care about a 32-bit implementation? Like I said originally, good question.

Reply on news.ycombinator.com