3 ms·

I would like to understand the implications. Does this improve performance? Or does it just allow coding in C++. Please help. (Sorry, noob here.)

rmgraham 15y ago
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.
deleted 15y ago
[deleted]
exDM69 15y ago
> 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.
- johnx123-up 15y ago
  (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 http://rajeshanbiah.blogspot.in/2012/01/nodec-la-nodejs.html
  - alexchamberlain 15y ago
    A properly coded C++ app should run as fast as C; it can be faster...
    - lmm 15y ago
      Not while C++ doesn't have restrict pointers
      - alexchamberlain 15y ago
        Yeah, all performance benefits of C come from a single under used feature. </sarcasm>
      - padenot 15y ago
        While the standard does not specify a restrict keyword, it is practically available in quite a lot of compiler.
    - timdot 15y ago
      Whilst C++ can be as fast, or faster, than C - it's usually not because it's "properly coded". Many of the abstractions that C++ provides are what hit performance and it's usually by avoiding these that you can match performance with C. http://unthought.net/c++/c_vs_c++.html http://unthought.net/c++/c_vs_c++.html
  - cube13 15y ago
    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.
- Animus7 15y ago
  To clarify, node already has parallelized I/O threads. The only thing that isn't parallelized is the JS-land code.
  - exDM69 15y ago
    > 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".
    - mnutt 15y ago
      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.
      - chapel 15y ago
        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/zLzuo292hX0 https://groups.google.com/forum/?fromgroups#!topic/nodejs/zL...
deleted 15y ago
[deleted]

rmgraham 15y ago

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.

deleted 15y ago

[deleted]

exDM69 15y ago

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

johnx123-up 15y ago
(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 http://rajeshanbiah.blogspot.in/2012/01/nodec-la-nodejs.html
- alexchamberlain 15y ago
  A properly coded C++ app should run as fast as C; it can be faster...
  - lmm 15y ago
    Not while C++ doesn't have restrict pointers
    - alexchamberlain 15y ago
      Yeah, all performance benefits of C come from a single under used feature. </sarcasm>
    - padenot 15y ago
      While the standard does not specify a restrict keyword, it is practically available in quite a lot of compiler.
  - timdot 15y ago
    Whilst C++ can be as fast, or faster, than C - it's usually not because it's "properly coded". Many of the abstractions that C++ provides are what hit performance and it's usually by avoiding these that you can match performance with C. http://unthought.net/c++/c_vs_c++.html http://unthought.net/c++/c_vs_c++.html
- cube13 15y ago
  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.
Animus7 15y ago
To clarify, node already has parallelized I/O threads. The only thing that isn't parallelized is the JS-land code.
- exDM69 15y ago
  > 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".
  - mnutt 15y ago
    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.
    - chapel 15y ago
      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/zLzuo292hX0 https://groups.google.com/forum/?fromgroups#!topic/nodejs/zL...

deleted 15y ago

[deleted]