
Compiled JavaScript with NectarJS can be faster than Node.js and C - seraum
http://blog.seraum.com/compiled-javascript-with-nectarjs-can-be-faster-than-nodejs-and-c
======
CJefferson
gcc should just add a 'remove fibonnaci' optimisation pass, that just
optimises this away entirely, and stop people using this benchmark.

This is one of the stupidest things I've ever heard of -- I'm going to be
really mean now. They want me to use a compiler remotely, every time I want to
recompile? So if their servers go down, or my internet connection goes down, I
can't even run my compiler? And they have all the source code I've ever
compiled?

And their evidence for their amazing super-awesome compiler is... optimising
fibonnaci? Which their compiler (any compiler) could easily be detecting and
special-casing? (I'm surprised more don't actually).

~~~
fdej
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.

~~~
mbel
gcc removes recursion in that case:
[https://godbolt.org/g/R6iBup](https://godbolt.org/g/R6iBup)

------
lorenzhs
That the C code is compiled with "gcc -O7" tells me just about everything I
need to know about the soundness of these experiments. "-O3" and "-Ofast" are
the highest optimisation levels, where "-Ofast" includes optimisations that
break some standard-compliant programs (mostly -ffast-math).

Not to mention that comparing running times for a single run on an unspecified
machine isn't "benchmarking".

~~~
mbel
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](https://godbolt.org/g/R6iBup)

~~~
gus_massa
My totally unsupported guess is that they detect pure functions and add
implicit memoization. It is relative easy to implement, has good benchmark
times if N is big enough but not too big to make the trick obvious, but under
the hood it use more memory than you expected.

------
philplckthun
"Compiler as a Service"

I think that says enough about this project unfortunately. Why would I want to
compile aanything, specifically JavaScript, "in the cloud"?!

Also, "Tail recursion optimisation as a service"?

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

------
yamafaktory
Everything looks like a scam, see that one, for example,
[https://github.com/seraum/nectarjs/issues/1](https://github.com/seraum/nectarjs/issues/1)
... and it's getting worse if you dive deep in the source code...

~~~
slang800
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...](https://github.com/seraum/nectarjs/blob/master/nectar.js#L521).

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

------
tannhaeuser
Compiler-as-a-service is certainly disappointing.

He should benchmark vs the nexe [1] and (commercial) EncloseJS [2] JavaScript
compilers (both grabbing V8's untraced/unoptimized initial translation to
x86_64 as I understand).

[1]: [https://github.com/nexe/nexe](https://github.com/nexe/nexe)

[2]: [http://enclosejs.com/](http://enclosejs.com/)

------
quickben
The only thing that can be concluded with absolute certanity, is that they
want $30k.

------
feduzi
Srsly fellas, do not back this shit! It is not a joke!

Idea (to have a compiler that compiles JS to a "native" binary) is good, but
this "give me your money" and "cloud" stuff should be annihilated.

IMHO Fibonacci benchmarks are doodoo.

~~~
tannhaeuser
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.

~~~
feduzi
I agree that "tool" (in this case compiler) as a service is OK. You're also
correct about "trust" aspect (that's what I've meant by "cloud" stuff).

Also In the FAQ on Kickstarter page it says that you'll be able to have your
own "Nectar" server, so you don't depend on "Nectar" cloud.

But look at it seriously... 32k USD for a thing that will be probably faced
with an open-source (and possibly free) solution.

The amount of "pay me money" features and bullshit:

* ecological

* pay to vote

* Fibonacci benchmark claiming to be faster than C

* claiming to work but actually fails to compile this JS code (as mentioned by johhny in the comments to the article [http://blog.seraum.com/compiled-javascript-with-nectarjs-can...](http://blog.seraum.com/compiled-javascript-with-nectarjs-can-be-faster-than-nodejs-and-c#comment-3219075399)):
    
    
      var hello = {foo: "Hello, world!"};
      console.log(hello["foo"]);

------
smarx007
So, it's just caching the return values of the method calls? I thought
applying dynamic programming to fibonacci numbers was algo 101?

And what is -O7 level? Or, better, O7 lvl? :) Dynamic version of 45th
fibonacci number (see [http://www.geeksforgeeks.org/program-for-nth-fibonacci-
numbe...](http://www.geeksforgeeks.org/program-for-nth-fibonacci-number/)) has
the following runtime:

    
    
        ᐅ gcc -O2 fib.c -o fib && time ./fib
        1134903170
        ./fib  0.00s user 0.00s system 49% cpu 0.005 total

------
doubleplusgood
Feels like a premature April 1st launch

------
easytiger
Or, the code gets tail recursion optimized, turned into an iterative solution
whilst the c code is recursive? If it was doing the same thing its unlikely to
be faster.

~~~
Athas
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.

------
staticelf
A compiler is software that IMHO really should not be SAAS. I don't want to
pay monthly for everything in my life. Honestly, I want to pay a monthly fee
for as little as possible. The worst part of it all is what happens if you go
out of business and I've build an entire product with "NectarJS"? Can't I even
compile the code then?

NodeJS already is fast, and if one really needs something faster maybe use
something else than javascript?

------
hoodoof
Can be faster than assembler!

------
ht85
You had me at "faster than C"

