4 ms·

In your Go benchmark code, how is the calculation actually being done across threads? I don't see the `go` keyword anywhere in the source code.

h4x0rr 3y ago
I'm wondering that as well. The c# code seems really unrealistic though, using a lot of tasks for CPU bound work. A fair comparison would at least need to involve some degree of IO. Does go maybe automatically parallelize everythinh it can? That would be one potential answer to the initial question
SmooL 3y ago
Yeah this isn't using goroutines at all? I don't see how this is a good comparison of goroutines vs coroutines.
cyberax 3y ago
But that's the point I'm trying to show. In Go code all calls are the same. There is no sync/async distinction. In contrast, in C# (or any other similar system) async calls are _expensive_ compared to regular function calls.
- mftb 3y ago
  You've misunderstood how go routines work. You need to put the "go" keyword before the function call in order for it to be run concurrently.
  - cyberax 3y ago
    I know perfectly well how goroutines work. I'm NOT trying to show that Go is faster than async/await or anything similar. I'm showing that nested async/await calls are incredibly expensive compared to regular nested function calls.
    - foton2097 3y ago
      You need to add to go keyword to change a normal function to a goroutine. If you would remove async/await and Task/Return from the C# code example, it would perform pretty much the same as Go. If you want to show that async/await calls are expensive, than you should have shown two code samples of C#, one with async/await, and one without. Or could have done the same for Go, show one example with goroutines, and one without. But I think everyone already know that async/await and goroutines has it's costs. The problem is more that you are comparing Go without goroutines (without it's allocation costs) to a C# example with a poor implementation of async/await.
- deleted 3y ago
  [deleted]
yencabulator 3y ago
Just like there's no `spawn` or such in the async code. It's trying to show the overhead of the async machinery, compared to "uncolored" unfunctions.

h4x0rr 3y ago

I'm wondering that as well. The c# code seems really unrealistic though, using a lot of tasks for CPU bound work. A fair comparison would at least need to involve some degree of IO. Does go maybe automatically parallelize everythinh it can? That would be one potential answer to the initial question

SmooL 3y ago

Yeah this isn't using goroutines at all? I don't see how this is a good comparison of goroutines vs coroutines.

cyberax 3y ago

But that's the point I'm trying to show. In Go code all calls are the same. There is no sync/async distinction. In contrast, in C# (or any other similar system) async calls are _expensive_ compared to regular function calls.

mftb 3y ago
You've misunderstood how go routines work. You need to put the "go" keyword before the function call in order for it to be run concurrently.
- cyberax 3y ago
  I know perfectly well how goroutines work. I'm NOT trying to show that Go is faster than async/await or anything similar. I'm showing that nested async/await calls are incredibly expensive compared to regular nested function calls.
  - foton2097 3y ago
    You need to add to go keyword to change a normal function to a goroutine. If you would remove async/await and Task/Return from the C# code example, it would perform pretty much the same as Go. If you want to show that async/await calls are expensive, than you should have shown two code samples of C#, one with async/await, and one without. Or could have done the same for Go, show one example with goroutines, and one without. But I think everyone already know that async/await and goroutines has it's costs. The problem is more that you are comparing Go without goroutines (without it's allocation costs) to a C# example with a poor implementation of async/await.
deleted 3y ago
[deleted]

yencabulator 3y ago

Just like there's no `spawn` or such in the async code. It's trying to show the overhead of the async machinery, compared to "uncolored" unfunctions.