Hacker News Reader

Comment by solutionyogi | Hacker News Reader

Doesn't matter. Unless you do TaskFactory.StartNew or Task.Run, it's not going to try to schedule work on another thread. Everything is happening in the main thread in your code.

View on HN

See the updated version. Runs about 15-20% slower, which is far less than the difference between single-threaded version and task-based one. Also, it's pretty easy to see in Task manager how all the cores get loaded.

That looks better. However, I am really not sure what you are trying to achieve here. You didn't specify any scheduler, it means your tasks will use a default scheduler and that scheduler uses threadpool [1] and it will never create 1M threads. And as there is no actual work performed in the Task, things will run reasonably fast.

I am having hard time understanding what you are trying to test here. I am worried that .NET code is not really testing what you think it is.

[1] https://msdn.microsoft.com/en-us/library/dd997402(v=vs.110)....

You can't create 1M threads on Windows (or OS X, for that matter) because there won't be enough RAM for stack space. (also, running more threads than physical cores on CPU-bound task is pretty pointless).

Maybe you mean we should schedule something which has a complete event loop? That would be a lot more fair wrt the Akka version, but the Go version does not create any threads either.

Not sure what you mean by complete event loop. But I have a strong feeling that you are comparing apples to oranges in your benchmark.

It's indeed apples vs oranges vs pies (Actors/Coroutines/Futures). Probably should make a table :)

Reply on news.ycombinator.com