
JXcore – A Node.js Distribution with Multi-threading - remotesynth
http://flippinawesome.org/2014/03/03/jxcore-a-node-js-distribution-with-multi-threading/
======
aegiso
This thing is dead on arrival. Unless I'm mistaken it's not open source, so
the main draw of node (unrestrained hackability -- see npm) goes out the
window.

The touted benefit is marginally increased parallel performance, but even if
you buy this (I don't), the best case scenario is this buys you a slightly
decreased server bill for the price of closedness, lock-in, and compatibility
headaches. If your code shards horizontally like this then you can already
trivially parallelize and shard across servers with first-class node core
clustering.

I spend most of my waking hours writing all sorts of crazy things in node, and
I still can't think of any scenario in which using this makes sense.

~~~
obastemur
I would like to remind some things here;

> Maybe you don't have a case but there are many scenarios can benefit from
> multithreading including web hosting.

> The goal is to have a zero compatibility issue and we are almost there with
> the next beta.

> I believe that the node developers would enjoy benefiting from load aware
> instance monitored processes instead a trivial multi processing. BTW, still
> you can combine multithreading with multiple processes in case you want to
> keep process is active during v8 is GC'ing on one of the threads.

------
akbar501
Am I correct in understanding that the __main __benefit is that JXCore allows
you to run x number of tasks in parallel where x is the number of CPUs?

The problem is solved by running multiple node processes, which is standard
deployment for node (i.e. if a machine has 8 cores then 8 node processes are
started).

One issue with running multiple threads is that many developers use fail fast
as a best practice when building node applications. In other words, uncaught
exceptions cause the node process to fail, die and restart. So, it's perfectly
acceptable practice to write your application to be written to accept failure
as a given (similar to how Netflix uses Simian Army).

That said, how well is each thread isolated from everything else. Does an
uncaught exception kill just the thread and its state, or does it kill the
process? More specifically, when is the main process killed and what is
contained within the thread?

~~~
obastemur
Thanks for the comments. >JXCore allows you to run x number of tasks in
parallel where x is the number of CPUs?

You may have a 8 cores but configure JXcore to use 64 threads.

> The problem is solved by running multiple node processes, which is standard
> deployment for node

You can still run multiple node process but 2 threads per each. This will
improve the responsiveness of each process by balancing the load exactly on
the native side. That means, if anything happens on one of the V8 threads (GC
etc). the other one will be handling the load.

> That said, how well is each thread isolated from everything else.

Totally isolated. We already started to update native c,c++ modules for
isolated multithreading.

>Does an uncaught exception kill just the thread and its state, or does it
kill the process?

On this very beta release, it throws into main thread (when it's uncaught by
thread) but coming beta (internal monitoring is implemented) will be
optionally resetting the sub thread itself.

You may simply consider each thread as a separate node.js host.

~~~
akbar501
Thanks for the detailed reply.

A small diagram on the home page showing x cores * y threads would be
interesting / helpful. Such a diagram would also highlight that this adds to
the multi-process approach (i.e. I don't have to give up my multi-process
approach, but get to add multiple threads to it).

Anyway, the solution sounds interesting.

------
NeonMaster
I fail to see the advantage that this would give over node-cluster for
scaling, as that can scale across multiple processes as well, while still
using the regular NodeJS.

------
tete
Either I am just paranoid or something seems wrong. The oldest blog entry is
"January 10, 2014" and a whois says it was resisted "05-feb-2014". They
mention have Nubisa Inc. copyright, which doesn't seem to be nubis.com (whois
again).

Other than that they have huge claims about optimizations that the whole
node.js community didn't come up with yet and there are just binaries
available.

~~~
itsdrewmiller
Haha yeah something is fishy alright. The part where they reimplemented JS in
llvm and it's already 25% faster than v8? Just a side project. No big deal.

~~~
STRML
I agree - there's no way anyone is going to beat V8 at its own game in a "side
project" that was done over a weekend. However, the benchmarks they are
showing are primitive types only; it's not hard to believe that perhaps they
managed to optimize the hell out of that in order to produce a better result.
For now. On an incomplete engine. Seems highly, highly unlikely that the full
engine will be anywhere near able to compete with V8.

The multithreaded performance optimizations are really interesting, however -
but I'd be much more interested in this making it into mainline Node, rather
than using this crazy closed-source fork. You're not going to find me using
anything closed-source on my servers if I can help it, least of all something
like Node which is hackable to its core.

If the performance improvements really mean something, and mean something
outside of contrived for() and fib() loops, I hope the Node core teams have a
serious talk with these guys about a merge. Node's cluster module is
definitely not the final solution for properly utilizing a server's full
capacity, and the team knows it; that module has been at level 1
(experimental) for a long time.

~~~
moisy
Clearly, you don't know what you are talking about. LLVM can beat V8. As far
as I understand, he put LLVM frontend intogether to see the results and it's
not the part of the project yet.

~~~
STRML
I'm not doubting that it can beat V8, in a mature project with very
significant programmer time behind it. But I find it very hard to believe that
one weekend of fiddling with an LLVM javascript engine is enough to produce
results better than V8, which has had the benefit of years of work from some
of the smartest minds in the industry.

~~~
obastemur
At what part I said that Its all done over a weekend?

from the post "..Last weekend I could finish the prototype and measure the
initial performance of the solution.."

If you still understand that it's all finished over a weekend. No way.. I
don't think it is easy to develop a LLVM frontend with those features over a
weekend.

If you could have some details on LLVM, you wouldn't accuse me on something
you miss read.

Because;

There is no such an LLVM JS engine. LLVM has its own IR and that prototype
turns the JS codes into a wrapped LLVM IR.. As a result the final code
functions at native level, so it is already fast.

For this reason, 20% or more performance difference because of LLVM actually
shows how V8 is fast! It doesn't show the prototype is over a weekend or
anything else..

------
outside1234
...meanwhile, everyone writing npm packages assumes a single thread.

~~~
obastemur
It doesn't change anything for javascript modules. On the other hand, we
already embedded most popular c,c++ modules internally (with multithreading in
mind) (coming with next beta) Besides, making a native c,c++ module
multithread compatible will be mostly changing couple of lines of code. We
were working on a wrapper and it will be part of beta 2 also.

------
uniclaude
That's quite interesting. I'd love to have a look at the source! I don't think
I'm going to deploy it to production anytime soon though, as I have no idea
how secure this is.

Here is where you can download the executable if you want to try it (I found
it weird that no link was given in the post):
[http://jxcore.com/downloads/](http://jxcore.com/downloads/)

~~~
remotesynth
Great point. I added a link to the project page at the beginning of the
article and a link to the downloads at the end.

------
filipedeschamps
Great job guys!

But I fail to understand what's the difference between JXcore and native Node
clusters. Can you develop this a little bit more?

------
ilaksh
In case people aren't aware there is webworker-threads although this doesn't
really solve the same problem.

------
mmcclure
This looks really cool, but 99% of the time I can get by with something
simpler like PM2
([https://github.com/Unitech/pm2](https://github.com/Unitech/pm2)) and
continue business as usual.

------
microcolonel
Well, I'm just not going to use it.

I don't know about you guys, but I can't rely on some proprietary blob, if not
for the security concerns, because doesn't even have an ARM binary, or even an
IA32 binary for RedHat derivatives.

------
camus2
So it's basically a closed source and commercial fork of nodejs ?

~~~
obastemur
it's not a commercial fork. "For now" it's closed source.

~~~
voltaire99
So it will be open-source at some point?

------
9876543210
I thought node's non-blocking I/O implied that threads were unnecessary?

What's the core mechanism that permits node's implicit concurrency?

~~~
Cthulhu_
It is, but that also means a Node application will not use all four cores of a
quadcore efficiently by default. I think the usual approach in that case is to
just rev up four node processes with a load balancer of sorts in front of it.

------
RyanZAG
If you want an OSS alternative, you can check out
[http://nodyn.io/](http://nodyn.io/)

~~~
camus2
not you need the jvm to run that.And frankly nodyn doesnt run anything yet.

------
iambrandonn
Some performance comparisons would be useful... especially since the point of
the project is to increase performance.

------
api
Threads in JavaScript?

Nope.

