

But the question is: will it recurse? Part 1: fibonacci(40) - titel
http://www.saltwaterc.eu/but-the-question-is-will-it-recurse-part-1-fibonacci40.html

======
Locke1689
Recur is to make a recursive call. Recurse is to curse again.

~~~
SaltwaterC
Thanks. Missed that one. My "3rd party" language support is not perfect.

------
maxs
Don't want to get into the language shootouts here. But this seems like a
horrible way to compare language performance.

There are many more interesting real-life programs tested on computer language
shootout website.

In particular, you can't compare C and JVM performance on programs that run
for such a short time. The JVM time will be dominated by the time to start up
the the JVM and to do the first JIT optimization. I think it is very likely
that for a larger fibonnaci number, the JVM performance will come
asymptotically close to optimized C's.

~~~
SaltwaterC
This may be the subject for a part 2. Aka more intensive testing for the
implementations that actually perform. And other recursive algorithms (such as
the classic factorial). I didn't test the language (implementation!)
performance, but the recursion and how the various implementations can
actually handle the bad recursion algo.

A proper testing suite that tests various aspects of a specific runtime takes
time. I am aware of that, but I am not aware of any test suite that does this.

------
colomon
Okay, I don't get this. I thought the original node.js article was using a
terrible implementation of Fibonacci precisely because it was stupidly slow.

Why are people writing articles looking at how fast different languages /
implementations are at running this terrible code? Does that give us any
useful information whatsoever?

~~~
SaltwaterC
There isn't an original article. In fact, my article isn't something to give
the node.js police ideas on how to "fix" various stuff. This is about how
various runtimes handle bad recursion. In fact, V8 isn't stupidly slow
compared to PHP, CPython, and the de facto Ruby implementation.

If you aren't writing recursive code, then the valuable information for you is
NULL. Otherwise, it may give you some food for though.

~~~
colomon
I do write recursive code. However, I certainly do my best not to write _bad_
recursive code...

~~~
SaltwaterC
In fact it is _good_ recursive code, mathematically speaking. It's just that
some compilers are _bad_ at it aka doing brute force instead of tail
recursion. The main selling point of these "interpreted" languages is the
programmer productivity. Now why the hell one would have to write more
complicated algorithms just to go around the compiler? C does this just fine.
The 0.6 seconds to 5 minutes difference for the same simple algorithm shows
that something is fundamentally broken.

------
Jabbles
Try using compiler optimisations...

~~~
SaltwaterC
Good catch.

fib|⇒ gcc -O4 fib.c -o fib fib|⇒ time ./fib ./fib 0.65s user 0.01s system 100%
cpu 0.657 total fib|⇒ gcc -O3 fib.c -o fib fib|⇒ time ./fib ./fib 0.66s user
0.00s system 100% cpu 0.657 total fib|⇒ gcc -O2 fib.c -o fib fib|⇒ time ./fib
./fib 1.54s user 0.00s system 100% cpu 1.535 total fib|⇒ gcc -O1 fib.c -o fib
fib|⇒ time ./fib ./fib 0.00s user 0.00s system 0% cpu 0.001 total

For some reason, it hates the O1 flag. Printing the result brings it close to
the result without the optimization.

~~~
aklein
O1 probably sees you don't use the result or have side effects in
fibonacci(40) and optimizes the call away...

~~~
SaltwaterC
One of the reasons I get why people advise against certain levels of
optimization without understanding its implications. As I write few lines of C
code, usually I don't bother with deep understanding of all the concepts of
compiler optimization.

------
throwaway1415
Wow meaningless article. Try tail recursion, and a functional language -
although that won't be able to help you with your terminal banality...

~~~
SaltwaterC
Can you post something that actually means something?

------
rauljara
"sucks" "suckier" sucks that hard " "makes me laugh so hard up to the point of
bursting into tears"

In these sorts of posts, I tend to find that flavor comments like the above:

a) add nothing of value to the post

b) are likely to provoke hostile responses (or turn people off from
responding), actively detracting value from the conversation surrounding the
post.

Thank you, though, for taking the time to write up your benchmarks.

~~~
SaltwaterC
Buzz marketing. These days nobody gives some attention to a purely technical
article without any incentives. Seriously, on HN usually it matters who wrote
the article, not the factual contents of it.

