6 ms·
This was a good read! Thanks for sharing
by yveezy 3y ago
This was a good read! Thanks for sharing
- renox 3y agoA good part of the article is about a non-realistic microbenchmark (nobody spawns empty threads).. Also measuring the performance difference with threads making some work would be more interesting IMHO.
- marcus0x62 3y agoI did some non-scientific testing with this last week and, at least for my problem (brute-forcing RC4 keys with relatively small numbers of long-lives threads,) threads and go routines were approximately equal in terms of performance with goroutines very slightly faster (around 5% or so.) I have another test I'm running with the same workload, but with more dynamically created threads (n keys dispatched to a pool of threads/goroutines until the key space is exhausted) but I haven't finished the threaded version for comparison yet.
- gpderetta 3y agoWouldn't you have exactly 1 thread per CPU for this sort of brute force embarrassingly parallel, CPU intensive computation? You should be context switch approximately never which makes coroutine vs thread moot.
- marcus0x62 3y agoThe point was more to see what the overhead is for CPU-bound tasks that do need to switch, not that this is the best approach for this particular task. I just happened to have the threaded version available, so I thought it made a good point of comparison.
- akvadrako 3y agoIt's a good place to start since empty threads should show you the maximum advantage of goroutines. It also shows that the overhead of a million threads is reasonable if you can actually handle them doing something.
- renox 3y ago>It's a good place to start since empty threads should show you the maximum advantage of goroutines. That's the part I'm not so sure..