Node-fib: Fast non-blocking fibonacci server • Hacker News Board

Re: Node-fib: Fast non-blocking fibonacci server

#101

Post by jrockway » Tue, Oct 04, 2011, 4:47 AM UTC

marshray wrote: post #88

jerf wrote: post #17

Earlier quoted context omitted.

Yes, you too can by required by the compiler to implement cooperative multitasking by hand. In 2011. Yes. It is an answer to the criticism made, and I acknowledge that. But it is not a very good answer to the objection. The better answer is "don't do that in Node.js", which is still not all that great (it's really easy to accidentally write something that blocks badly), but is better.

Yes. It is an answer to the criticism made, and I acknowledge that. It's an answer that says: "You're using the wrong tool for the job." Which is particularly weird given that Fibonoacci itself is probably the most overused example of algorithm-to-promote-paradigm in computer science. Except it's for a different paradigm: recursion, not asynchronous IO. Still, it's interesting in a recursive sort of way.

Fib is designed to be a piece of code that runs really slowly but doesn't require typing in many lines of code. This makes it a reasonable benchmark for things like "how fast can a function be called", and also a good example of "something that takes a long time".

Re: Node-fib: Fast non-blocking fibonacci server

#102

Post by jrockway » Tue, Oct 04, 2011, 5:06 AM UTC

vogonj wrote: post #59

vogonj wrote: post #24

Earlier quoted context omitted.

you realize that you're just making Ted's point for him from the opposite direction, right? his point, when you look behind the trolling, is that node.js is not magical special sauce and that shitty coders who write poorly-scaling code will be shitty coders who write poorly-scaling code no matter what technology they use -- the "cancerous" properties of node arise simply because of the amount of groupthink that pitch…

to expand upon this, here are some other representative Ted Dziuba posts: http://teddziuba.com/2010/10/taco-bell-programming.html http://teddziuba.com/2011/02/the-case-against-queues.html http://teddziuba.com/2011/03/osx-unsuitable-web-development.... http://teddziuba.com/2008/09/a-web-os-are-you-dense.html if I had to sum up his philosophy in three sentences, here they are: your job is software engineering. every bi…

Yeah, some of those blog posts don't make much sense. The queues article, for example. RabitMQ and ActiveMQ are big Java things to keep your sysadmins up at night. ZeroMQ is just a networking library. Yes, they all end in "MQ", but at the end of the day, everything in computing as a message queue. If you don't like it, go back to typewriters :)

Re: Node-fib: Fast non-blocking fibonacci server

#103

Post by syaramak » Tue, Oct 04, 2011, 5:07 AM UTC

Peaker wrote: post #91

jerf wrote: post #17

Earlier quoted context omitted.

Yes, you too can by required by the compiler to implement cooperative multitasking by hand. In 2011. Yes. It is an answer to the criticism made, and I acknowledge that. But it is not a very good answer to the objection. The better answer is "don't do that in Node.js", which is still not all that great (it's really easy to accidentally write something that blocks badly), but is better.

Cooperative multitasking will always have the blocking problem, whether implemented manually or by the language. The manual callback chaining is tedious, though. Preemptive multitasking solves that problem, but if mixed with lots of shared mutable state, it reintroduces much worse problems of non-determinism and unreproducible bugs. The golden path involves preemptive multitasking with little-to-no shared state. That…

> The golden path involves preemptive multitasking with little-to-no shared state. Erlang (and probably some other languages) seems to have taken this approach.

Re: Node-fib: Fast non-blocking fibonacci server

#104

Post by SamReidHughes » Tue, Oct 04, 2011, 6:25 AM UTC

masklinn wrote: post #50

ovi256 wrote: post #10

I'd like to point out that this uses important improvements over the naive Ziuba's strawman version: memoization and callbacks using the event loop. The callbacks improve concurrency, allowing a single process/thread to multitask requests, and memoization reduces total time spent per request. Actually, if the async lib memoization facility shares values between requests, which seems quite sure to me, all requests but…

> I'd like to point out that this uses important improvements over the naive Ziuba's strawman version The Ziuba version was not "a strawman", it was an example used to trivially generate high in-request CPU load and demonstrate the misbehavior of evented system under this condition. If you want to compute fibonacci fast, just use Binet's Fibonacci formula, it runs in O(1), then your only issue is that you're going to…

Binet's formula doesn't run in O(1) if you want an exact answer. Using a + b * sqrt(5) representations or floating point with sufficient precision, you can get O(n log n 2^O(log* n)) time (quoting Wikipedia's Furer's algorithm page here). Which beats O(n log n log log n) time, if you were wondering. If something beats that for computing Fibonacci numbers, that'd be pretty cool.

Re: Node-fib: Fast non-blocking fibonacci server

#105

Post by rehashed » Tue, Oct 04, 2011, 6:50 AM UTC

jerf wrote: post #55

philjackson wrote: post #51

Earlier quoted context omitted.

But who deploys node in a single instance? There's documentation all over the place which tells you how to load balance over several instances - and it's easy to do so. This is my point, the node is cancer article was pure troll.

OK. Set up a load balanced infinite loop. Result: A load balanced infinite loop. This is not a win for Node. Load balancing across a number of hung processes buys you very little. (Not quite zero; you get a chance to detect the fact that it's hung and restart it, as long as these pathological requests aren't coming in fast enough. Hope the user who poked the bug doesn't hit refresh too many times!) I still think you…

How does this differ from MacClients in apache, or process limits on CGI? I agree with you, but don't see how this problem is specific to node...

Re: Node-fib: Fast non-blocking fibonacci server

#106

Post by willvarfar » Tue, Oct 04, 2011, 7:30 AM UTC

jerf wrote: post #17

glenjamin wrote: post #8

Author here, didn't really expect this to get picked up anywhere but since it has I'd like to point out the idea was to demonstrate that computationally expensive algorithms can be split across multiple iterations of the event loop to avoid blocking it. In this case concurrent requests take advantage of each others' memoisation, which would be somewhat trickier to do with threads as you'd probably need to worry about…

Yes, you too can by required by the compiler to implement cooperative multitasking by hand. In 2011. Yes. It is an answer to the criticism made, and I acknowledge that. But it is not a very good answer to the objection. The better answer is "don't do that in Node.js", which is still not all that great (it's really easy to accidentally write something that blocks badly), but is better.

Lets not forget that process-per-connection has a really bad performance rep.

These newfangled non-blocking designs are seemingly much better for everyday tasks.

And saying that an async IO server is a bad choice for computational things is, well, a well-known tradeoff that 99% of apps don't have to worry about.

When was the last time someone complained that their webservers were CPU bound? Its always the DB that is the bottleneck...

Re: Node-fib: Fast non-blocking fibonacci server

#107

Post by willvarfar » Tue, Oct 04, 2011, 7:31 AM UTC

syaramak wrote: post #103

Peaker wrote: post #91

Earlier quoted context omitted.

Cooperative multitasking will always have the blocking problem, whether implemented manually or by the language. The manual callback chaining is tedious, though. Preemptive multitasking solves that problem, but if mixed with lots of shared mutable state, it reintroduces much worse problems of non-determinism and unreproducible bugs. The golden path involves preemptive multitasking with little-to-no shared state. That…

> The golden path involves preemptive multitasking with little-to-no shared state. Erlang (and probably some other languages) seems to have taken this approach.

(go too)

Re: Node-fib: Fast non-blocking fibonacci server

#108

Post by prodigal_erik » Tue, Oct 04, 2011, 7:34 AM UTC

DrHankPym wrote: post #93

burgerbrain wrote: post #83

Earlier quoted context omitted.

A so called 'goroutine' locking up will not lock up the rest of that server. Other pages will still be served by that server. This has nothing to do with the efficiency of the underlying language, it has to do with Go doing cooperative multitasking transparently . It might as well be a separate process (in fact, for all you really know it could be). The code seen here does cooperative multitasking explicitly . It is…

Well, that just makes me more confused, because most languages I know handle multitasking explicitly , and they can all be dangerous when programmers exaggerate "cpu intensive" processes. I appreciate you trying to explain this guy's expectations, but I can't help but see this all as trolling FUD.

Many languages offer threads, which either the operating system or the runtime will preëmpt to ensure they all make progress in some vaguely fair way no matter how they behave. I haven't been required to write "I have more work to do, but this would be a good place to interrupt me" for fifteen years (when Win95 displaced Win3).

Re: Node-fib: Fast non-blocking fibonacci server

#109

Post by willvarfar » Tue, Oct 04, 2011, 7:36 AM UTC

jerf wrote: post #47

philjackson wrote: post #36

Earlier quoted context omitted.

"it's really easy to accidentally write something that blocks badly" What is this nonsense? Isn't it time we knock this one on the head? Let me let you into a secret: If you write CPU intensive enough code in any framework you can eventually block all further requests. This whole debate was based on FUD and a complete misunderstanding of what node is all about. Read the previous posts and don't post generic, bullshit…

"If you write CPU intensive enough code in any framework you can eventually block all further requests." "Intensive enough" is a vague and fuzzy term which you can hide too much behind. So let me put it this way: Go grab Yaws, the Erlang web framework. Write a web page that goes into an infinite loop. Write some other web pages that work normally. Observe that visiting the infinite-loop web page once does not cause t…

At some point the fair time given to all the various workers stuck in an infinite loop will starve legitimate low-work tasks

CPU is finite. RAM is finite. The kernel has limits on things like sockets.

(Erlang is super-neat, and Go goes a long way in the same direction. But I rather imagine the original poster meant that people should use CGI)

Re: Node-fib: Fast non-blocking fibonacci server

#110

Post by willvarfar » Tue, Oct 04, 2011, 7:40 AM UTC

fendrak wrote: post #29

Is it just me, or have all these implementations of fast Fibonacci servers missed the original intent of the 'Cancer' article? As I read it, it was more of a commentary on giving novice concurrent programmers enough rope to hang themselves than on the capabilities of Node itself.

Ted-gate was advocating a return to CGI instead...