4 ms·

Hmmm... $ time curl localhost:3000/1000000 curl: (52) Empty reply from server real 1m0.392s user 0m0.006s sys 0m0.004s This actually cra

by bascule 15y ago

Hmmm... $ time curl localhost:3000/1000000 curl: (52) Empty reply from server real 1m0.392s user 0m0.006s sys 0m0.004s This actually crashes the server because it runs out of memory: $ node app.js FATAL ERROR: CALL_AND_RETRY_2 Allocation failed - process out of memory

flexd 15y ago
32bit or 62bit node? If 64bit did you specify it can use more ram than the 1.7GB that's the default setting? You can up the limit by starting node with --max-old-space-size=<size in MB>
- bascule 15y ago
  Fibonacci isn't a kind of problem that should be bounded on RAM though. Something is fundamentally broken with the way this is implemented.
  - jcdavis 15y ago
    Sure it is. Stack space isn't free
    - jamwt 15y ago
      It is with TCO.
      - jcdavis 15y ago
        How exactly is the particular implementation in question tail-call optimized? Honest question, not trying to be snarky. I'm well aware that fib can be done to use TCO, but this doesn't appear to do so
glenjamin 15y ago
You can probably get it work by asking it for increasingly large numbers to break up the calculation into stages. v8's current GC implementation has a hard memory limit of 1GB which is uppable to 1.7GB on 64bit systems. There's a new GC implementation in the works which is supposed to be able to beat this. The memory usage is due to the overhead of nextTick creating a new stack each time, and the interpreter keeping track of where the callbacks need to lead. Splitting the calculation up into batches could be incorporated into the algorithm quite simply by adding an additional task to async.series which called fib(i) for i to n with a step of 10 when n is > 100. Obviously there are much more efficient and effective ways of calculating the fibonacci sequence, but I quite like the recursive algorithm for its clearness and its amenability to memoisation.

by bascule 15y ago

flexd 15y ago

32bit or 62bit node? If 64bit did you specify it can use more ram than the 1.7GB that's the default setting? You can up the limit by starting node with --max-old-space-size=<size in MB>

bascule 15y ago
Fibonacci isn't a kind of problem that should be bounded on RAM though. Something is fundamentally broken with the way this is implemented.
- jcdavis 15y ago
  Sure it is. Stack space isn't free
  - jamwt 15y ago
    It is with TCO.
    - jcdavis 15y ago
      How exactly is the particular implementation in question tail-call optimized? Honest question, not trying to be snarky. I'm well aware that fib can be done to use TCO, but this doesn't appear to do so

glenjamin 15y ago

You can probably get it work by asking it for increasingly large numbers to break up the calculation into stages. v8's current GC implementation has a hard memory limit of 1GB which is uppable to 1.7GB on 64bit systems. There's a new GC implementation in the works which is supposed to be able to beat this. The memory usage is due to the overhead of nextTick creating a new stack each time, and the interpreter keeping track of where the callbacks need to lead. Splitting the calculation up into batches could be incorporated into the algorithm quite simply by adding an additional task to async.series which called fib(i) for i to n with a step of 10 when n is > 100. Obviously there are much more efficient and effective ways of calculating the fibonacci sequence, but I quite like the recursive algorithm for its clearness and its amenability to memoisation.