3 ms·
And make a simple iterator into a multithreaded program with channels and goroutines? Slower. More complex. Why?!? Just call your function in a loop.
by slashdev 3y ago
And make a simple iterator into a multithreaded program with channels and goroutines?
Slower. More complex. Why?!?
Just call your function in a loop.
- Groxx 3y agoWhich is to say: yes! Many do it with channels currently. It's awful, but they do it.
- konart 3y ago> Slower Why would that be slower?
- Mawr 3y agoThe design of channels is constrained by the need to support concurrency. If you do not need concurrency, using something designed to support it will be suboptimal. And because it's specifically concurrency, the overhead will be substantial. ... that's the theory behind it. For more grounded explanations, see [1] & [2]. [1] https://news.ycombinator.com/item?id=29510751 https://news.ycombinator.com/item?id=29510751 [2] https://ewencp.org/blog/golang-iterators/index.html https://ewencp.org/blog/golang-iterators/index.html
- konart 3y agoYeah, I kind forgot we don't have anything concurrency related here. Thanks for the links!
- slashdev 3y agoChannels and the goroutine scheduler need to be thread safe. They use locks and/or synchronized instructions that run much slower because they need to synchronize between the different cores of your CPU (or between CPUs, if you have more than one, which is slower still.) Running goroutines also saves and restores registers, trash part of the cache, or move to another core with a cold cache. Threads have more overhead, and processes more still, but that still is very slow.