3 ms·
You quote things you don't understand. n goroutines (where n is big) get multiplexed to m threads (small m, typically numbers of cores). Goroutines are cheap: e
by _ak 14y ago
You quote things you don't understand. n goroutines (where n is big) get multiplexed to m threads (small m, typically numbers of cores). Goroutines are cheap: each goroutine starts at a size of 4k, and creating them is a really cheap operation. Please show me a Java thread implementation with the same properties. Good luck with that.
- pjmlp 14y agohttp://labs.oracle.com/projects/squawk/ http://labs.oracle.com/projects/squawk/ Used to power these nice devices, http://www.sunspotworld.com/ http://www.sunspotworld.com/ Here is another one, http://www.cacaojvm.org/ http://www.cacaojvm.org/
- pretoriusB 14y ago>n goroutines (where n is big) get multiplexed to m threads (small m, typically numbers of cores). You had the same thing in early Java with green-treads -- it is abandoned for modern JVMs, but you can mimic it. You can have millions of Scala actors. >Goroutines are cheap: each goroutine starts at a size of 4k, and creating them is a really cheap operation. Yes, but handling and migrating them is a "not really cheap operation". They are mostly useful as abstractions, as for performance you don't get anything over Java (if not worse: checkout Go vs Java concurrency benchmarks). >Please show me a Java thread implementation with the same properties. Good luck with that. Not sure I need all that "luck" you wish me. How about Java on Solaris, which multiplexes java threads to native threads?