81–90 of 99 posts
Earlier quoted context omitted.
i am not a node.js expert. one thing i am wondering is that, modern computers have more than just one core. how node.js utilizes these multiple cores?
By starting multiple processes. See cluster ( https://github.com/LearnBoost/cluster ), fugue ( https://github.com/pgte/fugue ), multi-node ( https://github.com/kriszyp/multi-node )
IMHO i think node.js sucks because it forces you to manually pass callbacks around. can't it remember my call site for me and use coroutines or call/cc or yield or something? even fork() exists on UNIX (or pthread_create()). why is passing callbacks around the answer? it's like using GOTO.
I'm sure things will be a lot better if/when the V8 engine supports let/yield.
I'd guess you used MRI 1.8.X.
I decided to benchmark other versions(and implementations) of Ruby.
= jruby 1.6.4 (7.3 seconds)
user system total real
7.388000 0.000000 7.388000 ( 7.349000)
user system total real
5.940015 0.006878 5.946893 ( 5.842485)
user system total real
38.250000 0.090000 38.340000 ( 38.376857)
user system total real
136.960000 0.240000 137.200000 (137.437748)
It's the equivalent of tying a giant boulder to the back of a Ferrari 599 and scoffing at how Ferrari can dare to call it a "high performance" car. Stop trying to drag giant boulders around.
I like how every rebuttal turns into "how fast can you compute a fibonacci number". I was looking for a function that burned a nontrivial amount of CPU, the choice of fibonacci was arbitrary. Let's move on from that. What I was showing was that if your request handler does a nontrivial amount of CPU work, it will hold up the event loop and kill any "scalability" you think you're getting from Node. If you Node guys we…
Node is an asynchronous programming framework bundled with a largely async library. If you have 40 cores on your system, you would presumably run 40 instances of node for a CPU intensive webserver(using multinode etc). So the event handler won't get stuck as long as there are available cores. What about a single core system? Well I guess a threaded/multi-process solution would time slice the fibonacci requests betwee…
Eh? Think you could do async IO in both Perl & Python (and C and erlang ..) years before node came along..
Earlier quoted context omitted.
> Also, most other web stacks will discourage you from running a 30s fib on a thread processing web requests. This isn't specific to node. Difference being, with other stacks a request running for 30s will have little impact on the rest of the machine. With node, the whole server gets stuck, not just that precise request and the machine resources necessary to perform the computation (or whatever). The fib example is…
Only if you're crazy enough to put something in production running a single node instance.
As a cancer survivor, just wanted to let you know that the poor taste exhibited here is pretty sad. When you want to make your point next time, use a title that doesn't include something that kills people. Thank you.
Earlier quoted context omitted.
Node is an asynchronous programming framework bundled with a largely async library. If you have 40 cores on your system, you would presumably run 40 instances of node for a CPU intensive webserver(using multinode etc). So the event handler won't get stuck as long as there are available cores. What about a single core system? Well I guess a threaded/multi-process solution would time slice the fibonacci requests betwee…
How is running 40 instances of node processes different from running 40 instances of a single threaded web server? How is running 40 instances of single threaded event loops better than running 10 instances of a process with 4 threads each? If you had a choice would you not rather have light-weight processes (threads) rather than actual processes because of lighter memory requirements? Threads are too hard to program…
40 Instances of a single threaded webserver can block for I/O. If your webserver is 50% CPU bound this means that your CPU utilization is lower than in the case of a perfectly async system. You will serve fewer requests per second than an async framework. This is where the rule of thumb "no of threads = 2X no of cores" originates. Of course this rule wont work well for heavily I/O bound servers with high latency I/O. With node.js latency/IO percentage etc won't matter.
> If you had a choice would you not rather have light-weight processes (threads) rather than actual processes because of lighter memory requirements?
It would be great to have a multithreaded async framework. However a multithreaded environment eventually ends up introducing several blocking I/O functions which Dahl wanted to avoid. Hence the choice of Javascript.
node.js is one of a 100 possible solutions. Nobody insists that you use it. In fact I haven't even written a single line of node code. However I have done enough systems work to know the benefits of async programming.
> Threads are too hard to program to? Try STM?
STM can only handle scenarios that do not involve I/O. One of my colleagues was in the group at Microsoft tried STM with I/O that fell hard on their faces. Sure there are plenty of approaches - threads, actors, STM. Async programming is one such approach. If you want to write an async web server, right now node.js is the only solution. I think it might be possible to do a pure async web server in Haskell, as any IO gets captured in the type signature but I don't know of any async Haskell webserver framework.
> I'm not buying the notion that node's event model has any advantage over anything whatsoever.
You are basically asserting that async programming has no advantage over any other approach whatsoever. Having dug into hard disk device drivers, filesystems and caching for the Windows CE kernel, I would have killed to have a proper async I/O framework in CE from the ground up. We had a gazillion locks in the kernel modules, for gazillion data structures when all we really wanted to do was perform I/O without grabbing a lock. The Linux epoll, BSD kqueue and Windows IO completion ports are all async APIs added for high performance systems. These APIs are, strictly speaking, not required if you have threads but when you get into sufficiently advanced systems programming you cannot live without these. Trying to say that async programming is useless is equivalent to claiming that APIs such as epoll/kqueues are useless.