On Sun, Feb 5, 2017 at 7:59 PM <fwang2...@gmail.com> wrote: > I make a test to see the performance of select, and found the result is > not good. > > I make 1000 SeqQueue objects and run its messageLoop function (which does > a small piece of work, and is listed as below) in 1000 separate go > routines. The CPU cost is more than 20%. > If I make the ticker 1 second, the CPU cost can slow down to about 2%. > > > The key difference in your Node.js vs Go test is this:
* Node.js is concurrent but has no inherent parallelism * Go is concurrent but also employs parallelism by default When a system has no parallelism, it can optimize for this. In particular, there are many cases where you don't have to take a lock because no-one else but the current (single) thread is able to manipulate the data. Also, scheduling decisions can be immediate. Furthermore, Node.js has no preemption but prefers cooperative behavior which eliminates a large number of concurrent access patterns which needs lock protection. In contrast, a system with parallelism has to lock data which needs to synchronize, or it has to solve synchronization problems in other ways through CAS-operations or the like. Synchronization has overhead. It isn't free, and a test which essentially focuses on synchronization is going to be slower in any system where you truly has to guard against parallel access to data. Well written systems tries hard to minimize synchronization to a few places so the overhead is rather small. The benefit appears when your system gracefully scales to multiple processor cores with no additional effort on your part. The key is to employ Amdahl's law in the parallel case: minimize the sequential part of your program as much as possible, so you get the best parallel speedup behavior out of it. Or employ a slight rephrasing of Amdahl's law "you can solve a problem K times larger in the same time" which is sometimes easier since the computational overhead can benefit from a larger data set in some cases (especially if it is a constant) I'm willing to bet that as you start doing real work in your system, which happens to be CPU-bound, then Go will easily outperform Node.js. Especially because it will be able to easily utilize more than a single core of the CPU. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
