Hacker News Reader

Comment by paramaggarwal | Hacker News Reader

I would like to understand the implications. Does this improve performance? Or does it just allow coding in C++.

Please help. (Sorry, noob here.)

> I would like to understand the implications. Does this improve performance? Or does it just allow coding in C++.

This is practically a C++ wrapper for libuv, the backend of node.js. It allows you to write code similar to node.js in C++ without using JavaScript and the V8 JavaScript environment. Does it improve performance? In theory, yes. In practice, maybe.

The biggest potential win here is that you could run many threads that can run I/O in parallel. In Node.js/V8 you only have one native OS thread while in C++ you can put many native threads to serve the I/O sockets. It's quite a lot cheaper to change from one thread to another than it is to change from one process to another (if you have many node.js processes running) so there is potential for performance increases if you have some CPU-heavy stuff in your code. Or you have more sockets/requests to serve than a single CPU is capable of.

This is assuming that libuv and node.native don't have anything that would inhibit running in multiple threads. The system calls running underneath (read, write, epoll/kqueue) are thread safe, but libuv/node.native may have something that isn't. I didn't double-check.

(I submitted the link, but...) Do you think a C port will improve performance over C++? Google only returns wishlist something like this http://rajeshanbiah.blogspot.in/2012/01/nodec-la-nodejs.html

A properly coded C++ app should run as fast as C; it can be faster...

Not while C++ doesn't have restrict pointers

Yeah, all performance benefits of C come from a single under used feature. </sarcasm>

While the standard does not specify a restrict keyword, it is practically available in quite a lot of compiler.

In all honesty, probably not. Node.js is too thin to really make a C port all that worthwhile.

Unless the dispatcher is extraordinary slow, the major performance issues are going to be in the userland code more than the actual Node code.

To clarify, node already has parallelized I/O threads. The only thing that isn't parallelized is the JS-land code.

> To clarify, node already has parallelized I/O threads. The only thing that isn't parallelized is the JS-land code.

But Node.js runs only in a single native thread, right? So it's single threaded I/O multiplexing using epoll/kqueue and the thread calls JS callbacks when some I/O takes place. In C or C++ you could run n native threads serving m sockets using a single "reactor".

Node.js only has a single thread for the event loop. (where the user's javascript is run) Internally it uses a thread pool.

You could certainly do what you describe and it would be very similar to node's Cluster module, which uses multiple processes. In fact, I believe in the next release they're giving you the option to replace processes with threads under the hood.

That actually isn't the case anymore. It has been removed for various reasons, a major one is stability. While the promise of isolates was nice, I think the choice to remove them was a good one considering the tradeoffs.

More info: https://groups.google.com/forum/?fromgroups#!topic/nodejs/zL...

It allows coding in C++ in a fashion similar to Node by taking advantage of the lambda syntax added in C++11.

It also makes use of libuv and http-parser, which are used in Node, to offer some of the same out-of-the-box functionality.

Reply on news.ycombinator.com