I can't even begin to explain how wrong this benchmark and the author's conclusion is. I'd rather see a benchmark of apache vs a fibonacci function than read this nonsense.

I just ran it, fib is roughly six times faster

recursive fib, memoized fib, or O(1) fib?

Also, given that apache should run indefinitely, I would think the preferred result would be that fib is infinitely faster.

There is no O(1) fib.

Calculating that formula is not O(1), unless you have a way of calculating exponentiation, multiplication and subtraction all in O(1) time.

A closed form does not O(1) make

It contains n-th power. So it is O(logN).

In fact, since the fibonacci sequence grows as O(phi^n), we need O(n) digits to hold the n'th fibonacci number, so the fastest possible algorithm to compute the n'th fibonacci number must run in time Omega(n).

Not necessarily if you can parallelize computing the digits. Your average Pentium processor can compute a floating-point number with a mantissa of 16 decimal or 52 binary digits in one clock cycle, not 16 or 52. It does so by using enough silicon to compute them all in parallel.

That's only a constant factor improvement. What if you want to calculate 104 binary digits?

I couldn't determine which was the best, so I just calculated by hand instead

Andy Wingo knows quite well what he's doing. It's just a fun post. Read his 2/3 previous posts if you want more serious stuff on V8.

This is a banal point. Yes, separate compilation hurts performance. But that's what link-time optimization is for. GCC and LLVM alike can both do link-time optimization.

You might as well say "gcc with -O0 is slower than V8, therefore V8 is faster than gcc".

Link-time optimization is almost never useful.

How about trying a benchmark that mimics an actual program that someone would use.

Obscure? It's interesting but I can't see a case where I'd be recompiling C code every time I want to run something. On the other hand, we can't just go AOT compile using V8 (AFAIK) so let's call V8 always slower?

> I can't see a case where I'd be recompiling C code every time I want to run something.

How about when you're writing a program in C?

Fair enough, though I'm rarely obsessed with the absolute speed of code while developing. Tools like clang have brought this experience a long way as well.

In my mind, the value of this benchmark isn't to prove that V8 is absolutely faster than C but that there is intrinsic value in doing runtime compilation instead of / on top of compile-time optimizations.

It's a demonstration of why run time optimizing compilers/runtimes may one day become faster than compile time optimizing compilers.

Yay! Another useless benchmark!

No kidding.