7 ms·

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 expensi

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 locking.

ovi256 15y ago
I think it'a a valuable tutorial to show node.js idioms. It's pretty easy to read, but I for one would struggle to write it as concisely.
- apgwoz 15y ago
  Oh god, I hope you're joking.
  - ovi256 15y ago
    I have to agree with you, I guess it only shows how little I know node.js
jerf 15y ago
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.
- philjackson 15y ago
  "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 comments like "which is still not all that great".
  - jerf 15y ago
    "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 the rest of the web server to stop serving. Yaws may time it out eventually, too, not clear from a quick look at the docs. In fact it will only marginally decrease performance, even on single core machines. Yes, if you bash on that page often enough you will eventually degrade service to an unacceptable level. But you will not bring down the whole server, or even that OS process, and it will take substantially more than one hit per process or one hit per core. Now, go grab Node, and write a web page that goes into an infinite loop. You just brought that OS process down, from the user's point of view. Node is qualitatively much easier to lock up an OS process with than Erlang. Or Haskell, or Go, or anything else with a modern task scheduler, which is an ever-increasing number of language platforms.
    - philjackson 15y ago
      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.
      - jerf 15y ago
        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 may not understand what modern schedulers end up doing here.
        rehashed 15y ago
- tomjen3 15y ago
  I am not quite sure what it is you are trying to say. Node does (in this case) require a bit more hands on approach than most other languages but that is because of a subtile but important difference. Node uses corporative concurrency whereas threads are not corporative. This is both a disadvantage (you are required to do more work and cannot take proper advantage of multiple CPUs) and a huge advantage (no locking is needed and you can share the results between different execution points). Of course the real issue is that you should choose a better implementation of the algorithm.
- glenjamin 15y ago
  Well the other option for computationally expensive code is to use some sort of worker that runs a sufficiently fast language. JavaScript on v8 is actually one of the fastest interpreted languages available, so unless you really need to drop down into C or similar, splitting across the event loop or using another node child process is not an unreasonable way to approach CPU heavy calculations.
  - masklinn 15y ago
    > Well the other option for computationally expensive code is to use some sort of worker that runs a sufficiently fast language. Which only helps if you know your code is going to be slow. If you somehow implemented an algorithm with a quadratic complexity and did not test for sufficiently large input, you might not realize what's going to happen before it hits production. > JavaScript on v8 is actually one of the fastest interpreted languages available 1. Nobody is denying that. 2. The issue is with the behavior of evented systems in general and node in particular in case of in-request CPU-bound code paths, namely that the whole server blocks killing concurrency and basically DOSing the instance.
    - glenjamin 15y ago
      I can't disagree with any of these points. NodeJS is no magic bullet, those who treat it as such should be extremely wary. It is, however, rather nice to work with.
- marshray 15y ago
  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.
  - jrockway 15y ago
    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".
- Peaker 15y ago
  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 way you get to have your cake (determinism) and eat it too (no blocking problems/starvation).
  - syaramak 15y ago
    > The golden path involves preemptive multitasking with little-to-no shared state. Erlang (and probably some other languages) seems to have taken this approach.
    - willvarfar 15y ago
      (go too)
- willvarfar 15y ago
  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...
vogonj 15y ago
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 pitches the Next Big Thing as intrinsically better than everything that came before it.
- InclinedPlane 15y ago
  Personally I've never seen node.js pitched as a solution for newbies or sub-par coders toiling away in the enterprise trenches. I've always seen it marketed as a useful tool for people who know WTF they're doing.
  - vogonj 15y ago
    buzz is omnidirectional -- when people start talking about a technology, platform, or stack, people of all shapes and colors will show up and use it. and when your product pitches itself as having super amazing performance due to this programming paradigm omg!, you are responsible for making its limitations known to all and sundry who use it, rather than assuming prior knowledge. also, the joyent node.js homepage itself claims, as a business advantage: "• Huge JavaScript developer pool at the ready for faster development" implying that any Javascript developer can just dig their hands right into server code and get working.
    - InclinedPlane 15y ago
      Right, let's just stop talking about cool new technologies since some people might misuse them. Does anyone want to help me debug my webapp? It's written in C.
      - vogonj 15y ago
        nice strawman. my point isn't that you shouldn't build up buzz. it's that, when buzz exists around something, your job as a platform implementor includes making people aware of the things your product can't do well, and pitfalls the end-user might run into. saying "well, it's their own fault for not being clueful enough to know what they were doing wrong, this technology is for pro hackers only!" is developer-hostile.
bascule 15y ago
If I try to ask for a large number (say 1 million) I run out of RAM: $ node app.js FATAL ERROR: CALL_AND_RETRY_2 Allocation failed - process out of memory Somehow you're using O(n) RAM to do the calculation. Seems bad bro. This code is the epitome of roflscale
- Wilfred 15y ago
  That's a consequence of memoisation. It scales better than the original code though. Still, the original point (node is cooperatively multitasked) was clear. Anything beyond that and I just want to reach for better Fibonacci algorithms.
  - logancapaldo 15y ago
    And this is why, any cache without an eviction policy and/or size limitation is bad (and memoization _is_ a cache). I shudder every time I see a "magical" memoization function whose interface is just memo function-to-memoize
- rubyinghana 15y ago
  If you had brain, you would know that JavaScript only has 52 bits of integer precision. Anything bigger than Fib(~83) is not accurate number and waste of time in JS.
deleted 15y ago
[deleted]

ovi256 15y ago

I think it'a a valuable tutorial to show node.js idioms. It's pretty easy to read, but I for one would struggle to write it as concisely.

apgwoz 15y ago
Oh god, I hope you're joking.
- ovi256 15y ago
  I have to agree with you, I guess it only shows how little I know node.js

jerf 15y ago

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.

philjackson 15y ago
"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 comments like "which is still not all that great".
- jerf 15y ago
  "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 the rest of the web server to stop serving. Yaws may time it out eventually, too, not clear from a quick look at the docs. In fact it will only marginally decrease performance, even on single core machines. Yes, if you bash on that page often enough you will eventually degrade service to an unacceptable level. But you will not bring down the whole server, or even that OS process, and it will take substantially more than one hit per process or one hit per core. Now, go grab Node, and write a web page that goes into an infinite loop. You just brought that OS process down, from the user's point of view. Node is qualitatively much easier to lock up an OS process with than Erlang. Or Haskell, or Go, or anything else with a modern task scheduler, which is an ever-increasing number of language platforms.
  - philjackson 15y ago
    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.
    - jerf 15y ago
      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 may not understand what modern schedulers end up doing here.
      - rehashed 15y ago
tomjen3 15y ago
I am not quite sure what it is you are trying to say. Node does (in this case) require a bit more hands on approach than most other languages but that is because of a subtile but important difference. Node uses corporative concurrency whereas threads are not corporative. This is both a disadvantage (you are required to do more work and cannot take proper advantage of multiple CPUs) and a huge advantage (no locking is needed and you can share the results between different execution points). Of course the real issue is that you should choose a better implementation of the algorithm.
glenjamin 15y ago
Well the other option for computationally expensive code is to use some sort of worker that runs a sufficiently fast language. JavaScript on v8 is actually one of the fastest interpreted languages available, so unless you really need to drop down into C or similar, splitting across the event loop or using another node child process is not an unreasonable way to approach CPU heavy calculations.
- masklinn 15y ago
  > Well the other option for computationally expensive code is to use some sort of worker that runs a sufficiently fast language. Which only helps if you know your code is going to be slow. If you somehow implemented an algorithm with a quadratic complexity and did not test for sufficiently large input, you might not realize what's going to happen before it hits production. > JavaScript on v8 is actually one of the fastest interpreted languages available 1. Nobody is denying that. 2. The issue is with the behavior of evented systems in general and node in particular in case of in-request CPU-bound code paths, namely that the whole server blocks killing concurrency and basically DOSing the instance.
  - glenjamin 15y ago
    I can't disagree with any of these points. NodeJS is no magic bullet, those who treat it as such should be extremely wary. It is, however, rather nice to work with.
marshray 15y ago
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.
- jrockway 15y ago
  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".
Peaker 15y ago
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 way you get to have your cake (determinism) and eat it too (no blocking problems/starvation).
- syaramak 15y ago
  > The golden path involves preemptive multitasking with little-to-no shared state. Erlang (and probably some other languages) seems to have taken this approach.
  - willvarfar 15y ago
    (go too)
willvarfar 15y ago
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...

vogonj 15y ago

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 pitches the Next Big Thing as intrinsically better than everything that came before it.

InclinedPlane 15y ago
Personally I've never seen node.js pitched as a solution for newbies or sub-par coders toiling away in the enterprise trenches. I've always seen it marketed as a useful tool for people who know WTF they're doing.
- vogonj 15y ago
  buzz is omnidirectional -- when people start talking about a technology, platform, or stack, people of all shapes and colors will show up and use it. and when your product pitches itself as having super amazing performance due to this programming paradigm omg!, you are responsible for making its limitations known to all and sundry who use it, rather than assuming prior knowledge. also, the joyent node.js homepage itself claims, as a business advantage: "• Huge JavaScript developer pool at the ready for faster development" implying that any Javascript developer can just dig their hands right into server code and get working.
  - InclinedPlane 15y ago
    Right, let's just stop talking about cool new technologies since some people might misuse them. Does anyone want to help me debug my webapp? It's written in C.
    - vogonj 15y ago
      nice strawman. my point isn't that you shouldn't build up buzz. it's that, when buzz exists around something, your job as a platform implementor includes making people aware of the things your product can't do well, and pitfalls the end-user might run into. saying "well, it's their own fault for not being clueful enough to know what they were doing wrong, this technology is for pro hackers only!" is developer-hostile.

bascule 15y ago

If I try to ask for a large number (say 1 million) I run out of RAM: $ node app.js FATAL ERROR: CALL_AND_RETRY_2 Allocation failed - process out of memory Somehow you're using O(n) RAM to do the calculation. Seems bad bro. This code is the epitome of roflscale

Wilfred 15y ago
That's a consequence of memoisation. It scales better than the original code though. Still, the original point (node is cooperatively multitasked) was clear. Anything beyond that and I just want to reach for better Fibonacci algorithms.
- logancapaldo 15y ago
  And this is why, any cache without an eviction policy and/or size limitation is bad (and memoization _is_ a cache). I shudder every time I see a "magical" memoization function whose interface is just memo function-to-memoize
rubyinghana 15y ago
If you had brain, you would know that JavaScript only has 52 bits of integer precision. Anything bigger than Fib(~83) is not accurate number and waste of time in JS.

deleted 15y ago

[deleted]