I came here to leave this comment and found you. Thanks.

This is not a benchmark on any regard. I thought we were past the stage of optimizing to specific microbenchmarks and then showcasing those.

If you're not going to show me real performance, at least show me Octane https://chromium.github.io/octane/ or something similar.

Finbonacci is utterly meaningless. Here, my language does Fibonacci(45) in 0.001 seconds, it compiles any output to the python code `print 1134903170`.

I'd be particularly curious regarding what the optimized version yields for "fibonacci(78)" - plain JS will get this one wrong, as it runs out of mantissa bits and gives 14472334024676220 instead of the correct 14472334024676221.

Doing an asm.js-style transformation to use machine integers would offer some speedup, but the behavior would differ due to 64-bit integers vs 53-bit.

My production-ready PHP-to-JS compiler pragmatically optimises for highest efficiency in real-world synthetic benchmark scenarios by only being capable of compiling the factorial function.

Maybe they've never heard of the Community vs. Enterprise licensing schemes before.

Also, I find it amusing that they think compilation is an attractive feature to people on RasPis and smartphones, when those devices can already just directly run JS. If this worked (which I'm still not convinced of), it would really only be of use to high-performance server writers.

edit: also, iirc, Haskell can reduce out a fibonacci sequence if you pass it a constant

gcc already optimises away loops like for (i = 0; i < n; i++) s += i;

It wouldn't be too much of a stretch to detect and optimise away code that computes linearly recurrent sequences.

"Faster than C" will be bogus 99.9% of the time no matter how fake or stupid your "benchmark" is.

Yeah, it's hardly a benchmark. The information what kind of CPU they are using is also missing (why no -march=native?).

Despite how unbelievable it looks, I would love to see contents of the final binary to see what is really happening there. gcc code looks quite alright in this case: https://godbolt.org/g/R6iBup

Subscribe for debug build feature just for $99.99/month!

More importantly, that source-code isn't the compiler - it just makes calls to the server that runs the compiler: https://github.com/seraum/nectarjs/blob/master/nectar.js#L52....

We don't even get to see how the compiler works, much less use it to debug when things go wrong.

While I personally wouldn't buy it if I can help it, I don't see a problem with commercially offering compilers per se. The thing I'm having trouble with is potential injection of code (backdoors, etc.) and other security concerns, eg. if a customer of yours is having an imminent issue with your product, you're dependent on the third party tool provider.

  var hello = {foo: "Hello, world!"};
  console.log(hello["foo"]);

Turning the recursive formulation of the Fibonacci function into an iterative loop is not easy for a compiler (unless you just program that specific pattern into it).

However, this "benchmark" is totally dominated by function call overhead, and it's quite conceivable that you can engineer your compiler to optimise for that case at the expense of others. You could do it quickly enough by unrolling the recursion a few times. This can cause the code to balloon in size in the general case, but not for this simple case.

It's also not particularly impressive to optimise a Javascript program that does not exhibit any complex behaviour. Again, you can just write a compiler that detects whether the Javascript program is straightforward, and if so, turns it into C or whatnot. Without being able to see what the compiler is doing, there is no way to know.

Also, "Compiler as a Service" may be a good idea for some cases (like farming an aggressively optimising but very slow compiler off to the cloud), but as the default case? No way.