graal + node.js: how does it work?
thomas.wuerthinger at oracle.com
Sun Dec 24 11:06:00 UTC 2017
Yes, it supports native node.js modules and is 100% compatible with the V8-based node.js. So it can run all node.js modules. It would indeed be interesting to run Graal in the context of vert.x. We will check the benchmarks after the holidays.
> On 24 Dec 2017, at 01:17, Grant Haywood <mrgranthaywood at gmail.com> wrote:
> Am I mistaken but isint the point of graal/node to be able to access c++
> based node modules?
> Fwiw id love to see support for native node modules in vert.x through
> On Dec 23, 2017 9:21 PM, "Adam McMahon" <adam at cs.miami.edu> wrote:
> Jaroslav and group,
> I had a chance to run some tests running node.js on the JVM using the
> Vert.x library. I call this project node.v (node running on vert.x).
> Included are some benchmarks of my approach vs graal-node and native node.
> * node.v*
> Project is found at https://github.com/AdamMcM/node.v (the readme has setup
> instructions if anyone is interested).
> Vert.x is a polyglot inspired node library for the JVM that has many
> most of the functionality in Node, One can implement node.js by writing a
> small wrapper that calls down to the JS Vert.x API. For example, Vert.x
> already has a method called readFile which is very similar to node’s
> fs.readFile: https://github.com/AdamMcM/node.v/blob/master/fs.js
> * Performance*
> Take this all with a grain of salt :)
> In the two examples I ran, Node.v is almost as performant as native
> node.js, and it is significantly faster than graal’s node implementation.
> In fact, graal-node runs so much slower than native node that I am
> wondering if I have a setup issue. Based on Devoxx presentations, I was
> expecting it to be near native node performance.
> Here are some benchmarks.
> *[2a] HelloWorld. *
> 10 concurrent clients, Node.v is the fastest, with graal-native the
> slowest. *Node.v x3* indictes that 3 instnces of vert.x were used. This is
> similar to node’s cluster module, but does not require any change to the
> script, just adding “-–instances 3” to the command line, it will
> automatically scale to 3 event loops. No other code changes are necessary.
> numbers are in requests per second
> node.v x3: 14182 (long jvm warmup: 100k requests)
> node.v : 10103 (long jvm warmup)
> node9: 8172
> node-graal-jvm: 5065 (long jvm warmup)
> node-graal-native: 4101
> [2a] FileTest https://github.com/AdamMcM/node.v/blob/master/fileTest.js
> Read a small file, 36 bytes, and send it back to the client 10 times using
> chunked encoding.
> Node9 3593
> node.v x3: 3354 (after long warm up)
> node.v : 1900 (after long warm up)
> node-graal-native: 228
> node-graal-jvm: 228
> * Discussion*
> Node.v is a small proof of concept that node.js can be relatively easily
> implemented onto the JVM using the Vert.x library. To do so, one can create
> setup issue, node.v is significantly faster than node-graal in these
> examples. Node.v uses Nashorn, perhaps it could be improved even more by
> using graal.js instead.
> This was just a proof of concept project for me to learn more about node.js
> on the JVM, I will likely add a few more examples and flush out a few more
> features, but I do not intend (at this time) to implement the entire
> node.js API (as my day job keeps me pretty busy).
> Best and Happy Holidays,
> On Wed, Dec 20, 2017 at 3:40 AM, Jaroslav Tulach <jaroslav.tulach at oracle.com
>> Hello Adam,
>> a small note on performance:
>> On úterý 19. prosince 2017 22:14:35 CET Adam McMahon wrote:
>>> But in terms of
>>> performance, my approach runs about the same as vert.x (if you are
>>> with that performance), as mine is just a thin call down to vert.x from
>> This would be the kind of reply I'd use before joining the Graal team.
>> now I have to ask:
>> - what does a "thin call from JS" mean?
>> - how fast the JS implementation is?
>> Graal.js is comparable in terms of speed with V8. All other ones are
>> significantly slower. Secondly, the "thin call from JS" may require
>> mangling and possibly also inlining boundary. Again, this is something
>> Graal +
>> Graal.js can eliminate and make the execution faster.
>>> ... share my code on github once I get an example together a half-decent
>>> example that works well on all 3 systems (node.js, graal+node, node
>> Of course, the performance depends on the actual usage. Once your example
>> works, it would be nice to turn it into a benchmark and measure the # of
>> operations per second each version can handle.
>> Good luck.
More information about the graal-dev