You should read the comments following the article you referenced. In addition
there is a long thread on hackernews that might be worth browsing:
https://news.ycombinator.com/item?id=36024209
But if you want a real insight into how concurrent programs behave, you are
better off writing your own
Ha ha. Yes, I am similarly bearded grey.
I didn't think it was worth filling in after Etc. I almost stopped reading
after ChatGPT on the basis that if you cannot write the simple driver code,
you can neither verify that the driver is correct, nor have the
understanding of the system needed to inte
Thank you. I had the same reaction. I'm a grey beard who in the past
specialized in benchmarking and performance tuning. Synthetic, micro,
benchmarks of the type used in that blog post are borderline useless.
Especially when comparing different languages. Even when used to measure a
single metric s
This benchmark is worthless for all languages used.
- Each Go routine will be given a 2K stack.
- Go routines are managed by Go, threads by the operating system.
- C# uses a thread pool.
- There's a lot wrong with this article, not just with things being
claimed about Go.
- Bench
I was going through a blog where they compare different language threads to
see how much memory they consume for a million tasks.
Blog : https://pkolaczk.github.io/memory-consumption-of-async/
Do we have any benchmarking/report before that Go routines take more memory
with more threads?
I kn
