3 ms·
The go memory usage can probably be explained by the fact that go uses fairly large stacks for goroutines (according to https://go.dev/doc/go1.2#stack_size http
by znpy 3y ago
The go memory usage can probably be explained by the fact that go uses fairly large stacks for goroutines (according to https://go.dev/doc/go1.2#stack_size https://go.dev/doc/go1.2#stack_size it’s 8kb per goroutine, even though that’s old)
- pkolaczk 3y agoIf it was true, the results would be much worse. The average from my measurements is a bit above 2 kB. This website says it is 2 kB: https://tpaschalis.me/goroutines-size/ https://tpaschalis.me/goroutines-size/
- amscanne 3y agoStacks changed a lot in Go subsequently. I believe that in 1.2, segmented stacks were still being used. (They now are contiguous and copied on upsize.)
- ilyt 3y agoIt also runs actually in parallel, unlike the Rust and JS ones
- tialaramex 3y agoThe Rust threaded solution obviously produces actual threads, which will run "actually in parallel" if that is technically possible on your system. The Rust tokio solution will use tokio's runtime which automatically spawns an appropriate amount of worker threads to parallelize your async tasks (by default it asks the OS how many CPUs there are and creates one such thread for each CPU). The async-std implementation is roughly similar.
- kibwen 3y agoThe Rust version is running in parallel. Tokio's runtime is parallel by default.