Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js cures cancer

blog.brianbeck.com

Post reply on HN
Print view View original

61–70 of 99 posts

Re: Node.js cures cancer

#61

Post by masklinn »

ricardobeat wrote: post #51
masklinn wrote: post #35

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.

Even if you're not "crazy enough" to do what's prescribed, every user routed to the locked node instance will still be locked. You're just reducing the surface area of the freeze.

Re: Node.js cures cancer

#62

Post by ittayd »

zohebv wrote: post #41
tedjdziuba wrote: post #5

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…

The point of the original article is that there's no point in avoiding blocking on IO while allowing blocking on CPU.

Furthermore, since node.js is single threaded, what's wrong with blocking on IO in that single thread? The process hangs, is put to sleep by the OS and wakes when there's IO available. You gain a simpler model of programming than using callbacks/continuations

Re: Node.js cures cancer

#63

Post by ricardobeat »

masklinn wrote: post #61
ricardobeat wrote: post #51

Earlier quoted context omitted.

Only if you're crazy enough to put something in production running a single node instance.

Even if you're not "crazy enough" to do what's prescribed, every user routed to the locked node instance will still be locked. You're just reducing the surface area of the freeze.

Presumably not many requests will be routed to the locked instance - that's why it's called load "balancing".

And you shouldn't have any long-running computation on your server process anyway.

Re: Node.js cures cancer

#64

Post by piccadilly »

The original Node.JS is cancer article is a silly troll.

But it's totally ridiculous how in response, people keep writing these terrible, straw-man Python servers to try to prove that Python is so horribly slow.

If you want to write Python web apps, there is a correct way to do it, and it isn't to use SimpleHTTPServer. Write a WSGI application, and serve it with any of a number of decent WSGI servers (just for starters, try uwsgi behind nginx; but if you really insist on directly serving requests out of a server written in an interpreted language, you could try gevent).

Re: Node.js cures cancer

#65

Post by piccadilly »

ricardobeat wrote: post #48
exogen wrote: post #37

Earlier quoted context omitted.

Sure you're calling fibonacci(40) and not just defining the function?

Yes. Turns out that the recursion overhead in python is huge, it can get down to <100ms too with a non-recursive function.

I have no idea whether that is true and I'm not arguing with it.

Why are you writing web request handlers containing heavily recursive code, and why do you seem to think that indicates anything meaningful about Python?

Please tell me you are not also using SimpleHTTPServer to try to prove points about Python's performance (like http://joshuakehn.com/2011/10/3/Diagnosis-No-Cancer.html and http://blog.brianbeck.com/post/node-js-cures-cancer)

Re: Node.js cures cancer

#66

Post by [deleted] »

ricardobeat wrote: post #24

I'm getting 0.020s tops for that fibonacci code on node (time curl http://localhost/ ), even going up to `1.1210238130165696e+167` (800th number). OSX Lion on a C2d 2.3ghz. Python 2.7.1 took 1m25.259s (no server). Am I doing something wrong? Or is there some incredibly optimized code path for OSX? edit: even weirder, `time node fibonacci.js` without a server takes 0.090s.

[deleted]

Re: Node.js cures cancer

#67

Post by ricardobeat »

piccadilly wrote: post #65
ricardobeat wrote: post #48

Earlier quoted context omitted.

Yes. Turns out that the recursion overhead in python is huge, it can get down to <100ms too with a non-recursive function.

I have no idea whether that is true and I'm not arguing with it. Why are you writing web request handlers containing heavily recursive code, and why do you seem to think that indicates anything meaningful about Python? Please tell me you are not also using SimpleHTTPServer to try to prove points about Python's performance (like http://joshuakehn.com/2011/10/3/Diagnosis-No-Cancer.html and http://blog.brianbeck.com/pos…

I wasn't. I was just curious about the huge difference in performance. These numbers are from printing to console, no servers.

    def fibonacci(n):
        t = [0, 1]
        for i in xrange(n):
            t.append(t[-1] + t[-2])
        return t[-2]
    
    print fibonacci(800)

Re: Node.js cures cancer

#69

Post by piccadilly »

ittayd wrote: post #62
zohebv wrote: post #41

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…

The point of the original article is that there's no point in avoiding blocking on IO while allowing blocking on CPU. Furthermore, since node.js is single threaded, what's wrong with blocking on IO in that single thread? The process hangs, is put to sleep by the OS and wakes when there's IO available. You gain a simpler model of programming than using callbacks/continuations

Well, there is plenty of point avoiding blocking on IO if blocking on IO is your bottleneck, and blocking on CPU is not. For some reason, a lot of people have focused on that case for many years.

Re: Node.js cures cancer

#70

Post by dextorious »

jeswin wrote: post #16
tedjdziuba wrote: post #5

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…

The problem is that fibonacci was a bad choice in your example and it proved nothing. It is fairly easy to scale node with multiple processes. As long as you don't have a long running (such as fibonacci) operation. If you do have tasks like that, process outside node and check for completion. Like how Tasks work in Google App Engine. Also, most other web stacks will discourage you from running a 30s fib on a thread p…

It is fairly easy to scale node with multiple processes. As long as you don't have a long running (such as fibonacci) operation.

- - - -

Which is like the WHOLE POINT of the original article...

Post reply on HN