6 ms·
I'm pretty sure this doesn't measure what it claims. It's a mostly sequential flow with very little meaningful concurrent work going on. I would imagine a for l
by strmpnk 11y ago
I'm pretty sure this doesn't measure what it claims. It's a mostly sequential flow with very little meaningful concurrent work going on. I would imagine a for loop would put all of those to shame. I'm not sure why anyone would optimize their runtime for what's basically yet another process ring benchmark but I know it's gotten slower over time on a couple of the measured cases because it's just not a real example and making this fast trades off other things like good scheduler balancing.
Also check out Pony if you want something were spawn and send become basically free. It'll run pretty close to for-loop speed for the number adding which should be a baseline calculated in all implementations.
- wizzard0 11y ago> I would imagine a for loop would put all of those to shame. Indeed, see ".net sync" version. The point is to measure process spawn/message passing performance.
- zzzcpan 11y agoHe has a valid point though. Goroutines are more like for-loops than processes. You can't kill them, can't manipulate them, can't store references to them, etc. Comparing that to actors is incorrect.
- dxhdr 11y agoSomeone should hack together C coroutines using Duff's device and throw it up there. It'd win handily, probably around 1ms. You've got around 100 million instructions to use in 1ms on that i7-4770 and no cache to hit, go nuts.
- igouy 11y ago>> basically yet another process ring benchmark For those who don't know what you're referring to, an example: http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=threadring http://benchmarksgame.alioth.debian.org/u64q/performance.php...