Will vert.x pose a threat to node.js?

[Node42]

<a href="http://vertxproject.wordpress.com/2012/05/09/vert-x-vs-node-js-simple-http-benchmarks/">Benchmark </a>

<a href="http://news.ycombinator.com/item?id=3948727">Hacker News Discussion</a>

<a href="http://news.ycombinator.com/item?id=3927891">Hacker News Discussion 2</a>

<a href="http://vertx.io/">Vert.x</a>

<a href="http://www.infoq.com/news/2012/05/vertx">InforQ article</a>

<a href="http://fbflex.wordpress.com/2012/05/02/running-vert-x-applications-on-heroku/">Running Vert.x Applications on Heroku</a>

[Matt]

No.

Though I imagine Isaacs is wondering where the file read performance difference is. My gut feeling is that Java maybe uses mmap under the hood, or some other performance trick. It would be much more obvious if there were strace output. There's also other probable wins, like using a newer V8 that optimises non-VM functions (see recent thread about threads-a-gogo being faster even with just one thread).

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Bradley Meck]

Vert.x is interesting. I am not sure about all the verticals and state management from what I have read, it looks quite similar to hook.io in some ways. Still, it is nice to see node bringing about some influence in other places that have generally been somewhat awkward to work evented workflows in. I am curious about threads in vert.x and how using libraries that expect threads will work.

[Marak Squires]

Yes, particularly the built-in event bus that works in the browser.

--

Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--

-- 

Marak Squires

Co-founder and Chief Evangelist

Nodejitsu, Inc.

marak....@gmail.com

[dhruvbird]

Why not have a benchmark that doesn't read from the file, but instead
writes out the contents of a static string.

On May 9, 9:56 pm, Matt <hel...@gmail.com> wrote:
> No.
>
> Though I imagine Isaacs is wondering where the file read performance
> difference is. My gut feeling is that Java maybe uses mmap under the hood,
> or some other performance trick. It would be much more obvious if there
> were strace output. There's also other probable wins, like using a newer V8
> that optimises non-VM functions (see recent thread about threads-a-gogo
> being faster even with just one thread).
>
>
>
>
>
>
>

> On Wed, May 9, 2012 at 9:32 PM, Node42 <liu.ke...@gmail.com> wrote:
> > <a href="
> >http://vertxproject.wordpress.com/2012/05/09/vert-x-vs-node-js-simple...">Benchmark

> > </a>
>
> > <a href="http://news.ycombinator.com/item?id=3948727">Hacker News
> > Discussion</a>
>
> > <a href="http://news.ycombinator.com/item?id=3927891">Hacker News
> > Discussion 2</a>
>
> > <a href="http://vertx.io/">Vert.x</a>
>
> > <a href="http://www.infoq.com/news/2012/05/vertx">InforQ article</a>
>
> > <a href="

> >http://fbflex.wordpress.com/2012/05/02/running-vert-x-applications-on...">Running

[Ege Özcan]

I wouldn't see it as a "threat". node doesn't spend too much time running the Javascript code. A framework written on C++ can be much more optimized than anything which runs on the JVM, as far as I can tell. If there is anything they do which brings a huge performance advantage, then I guess node can learn from them. However, I really do like the whole application working as really separated modules with Verte.x. If they make this more developer friendly (a target from which they are not far away), then it could get interesting. 

[Erik Dubbelboer]

They actually use Rhino instead of V8.

No.

nodejs+unsubscribe@googlegroups.com

[Koichi Kobayashi]

Hi,

Node (libeio) has only 4 [1] background threads (per process)
for file I/O, but Vert.x has 20 [2] (per instance).

[1] https://github.com/joyent/node/blob/v0.6.17/deps/uv/src/unix/eio/eio.c#L389
[2] https://github.com/purplefox/vert.x/blob/v1.0.0.final/src/main/java/org/vertx/java/core/impl/DefaultVertx.java#L66

[Jeff Barczewski]

I think it is too early to tell.

The joy of developing in Node.js is way different from developing and deploying for the JVM (even if you are using dynamic languages) IMHO.

Most JVM code/libraries have been written in the synchronous mindset, so the more you try to leverage those existing libraries, the more threads one will be end up using under the covers with Vert.x which could affect ultimate scalability as compared with a fully asynchronous Node.js world. But who knows, maybe the mix would work reasonably well for some cases.

What would be interesting is if they were to create a set of core API's that mirror Node.js such that we could deploy our code in either environment without changes. Then one could develop once and choose to deploy in the environment that worked best for any particular requirements.

I guess only time will tell whether vert.x has the staying power to compete.

[Tim Fox]

Here's my take on this:

I wouldn't think of it in terms of a "threat". I'd think of it as spreading the async word further into the JVM world. That's a good thing for everyone.

Vert.x is broader than node, but Node is clearly a source of inspiration for Vert.x. It wouldn't exist if I didn't like node.

I don't think droves of node users will come over to Vert.x overnight. It's more likely that we'll get most of our users from current JVM users. But if a few node users find Vert.x suits their needs better than node, that's not a bad thing either.

In terms of competition I see Vert.x competing more with the likes of Play/Akka.

[dhruvbird]

I was wondering - how tightly coupled is node to v8 actually? I mean I
have heard that mozilla is making their runtime API compatible with
that of the v8 API, so is it possible to just plug it in instead of
v8? I remember seeing a project called SpiderNode doing so a while
ago.

Regards,
-Dhruv.

On May 10, 7:51 am, Erik Dubbelboer <e...@dubbelboer.com> wrote:
> They actually use Rhino <http://www.mozilla.org/rhino/doc.html> instead of

> V8.
>
>
>
>
>
>
>
> On Thursday, May 10, 2012 3:56:26 AM UTC+2, Matt Sergeant wrote:
>
> > No.
>
> > Though I imagine Isaacs is wondering where the file read performance
> > difference is. My gut feeling is that Java maybe uses mmap under the hood,
> > or some other performance trick. It would be much more obvious if there
> > were strace output. There's also other probable wins, like using a newer V8
> > that optimises non-VM functions (see recent thread about threads-a-gogo
> > being faster even with just one thread).
>

> > On Wed, May 9, 2012 at 9:32 PM, Node42 <liu.ke...@gmail.com> wrote:
>
> >> <a href="

> >>http://vertxproject.wordpress.com/2012/05/09/vert-x-vs-node-js-simple...">Benchmark

> >> </a>
>
> >> <a href="http://news.ycombinator.com/item?id=3948727">Hacker News
> >> Discussion</a>
>
> >> <a href="http://news.ycombinator.com/item?id=3927891">Hacker News
> >> Discussion 2</a>
>
> >> <a href="http://vertx.io/">Vert.x</a>
>
> >> <a href="http://www.infoq.com/news/2012/05/vertx">InforQ article</a>
>
> >> <a href="

> >>http://fbflex.wordpress.com/2012/05/02/running-vert-x-applications-on...">Running

> >> Vert.x Applications on Heroku</a>
>
> >> --
> >> Job Board:http://jobs.nodejs.org/
> >> Posting guidelines:
> >>https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> >> You received this message because you are subscribed to the Google
> >> Groups "nodejs" group.
> >> To post to this group, send email to nod...@googlegroups.com
> >> To unsubscribe from this group, send email to

> >> nodejs+un...@googlegroups.com

[Ben Noordhuis]

On Fri, May 11, 2012 at 7:00 AM, dhruvbird <dhru...@gmail.com> wrote:
> I was wondering - how tightly coupled is node to v8 actually? I mean I
> have heard that mozilla is making their runtime API compatible with
> that of the v8 API, so is it possible to just plug it in instead of
> v8? I remember seeing a project called SpiderNode doing so a while
> ago.

SpiderNode is dead but me and some others are doing a tech demo[1]
that's essentially node / libuv + smjs.

[1] https://github.com/creationix/luvmonkey

[alessioalex]

With a fair benchmark, Node is 50% faster than Vert.x. By fair benchmark I mean: both using a single core and both caching the file (so both are now using the same logic).

https://gist.github.com/2652991

[Tim Fox]

On Friday, May 11, 2012 7:59:29 AM UTC+1, alessioalex wrote:

With a fair benchmark, Node is 50% faster than Vert.x. By fair benchmark I mean: both using a single core and both caching the file (so both are now using the same logic).

https://gist.github.com/2652991

Incorrect. Vert.x does not cache the file. All this benchmark has done is disable the thing that was slowing Node down the most in the benchmark (the file system access). This is not a valid change to the benchmark - a real web server would not cache the file like this - if the file changes on the underlying OS the server should serve the updated file, not the old one.

Secondly - this is doing a benchmark using a single core VM on EC2? WTF? No-one in their right mind is going to run a single core EC2 and expect any kind of performance.

Thirdly - this is testing the Vert.x JS server only. Try running the the other languages too, Java is significantly faster.

If you perform the benchmark as it should be performed and not fine-tuned to make Node.js look good, you'll find that Vert.x seriously outperforms.

[Richard Marr]

Definitely agree that its unwise to think in terms of a threat. Node isn't a country that's being invaded. It's a tool that people here find useful. Having more choice in tools is a good thing. Thanks Tim.

--

Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--
Richard Marr

[Ben Noordhuis]

On Fri, May 11, 2012 at 12:40 PM, Tim Fox <timv...@gmail.com> wrote:
> On Friday, May 11, 2012 7:59:29 AM UTC+1, alessioalex wrote:
>>
>> With a fair benchmark, Node is 50% faster than Vert.x. By fair benchmark I
>> mean: both using a single core and both caching the file (so both are now
>> using the same logic).
>>
>> https://gist.github.com/2652991
>
>
> Incorrect. Vert.x does not cache the file. All this benchmark has done is

Have you checked with a tool like truss or strace if it's really
rereading the file? Isaac remarked that he didn't see any file I/O
syscalls after start-up.

I haven't verified it myself (vert.x seems to require Java 1.7, you
should advertise that a little better) but I've seen similar behavior
with other Java apps.

[Stewart Mckinney]

1) Pretty tight. The abstraction layer between v8 and node isn't thick enough or generalized enough, from what I can tell. To be fair, writing an abstraction layer between multiple JS engines is very difficult (I am doing such now for a different project, non-web related). JSC and v8, for instance, have *very* different ideas of how to do things. From what I understand, as well, SpiderMonkey has really limited support for passing arbitrary information (void *) in callback functions, which is part of the magic of v8.

2) Wondering what "runtime API" compatibility means. If it means "SpiderMonkey will have a similar class structure to v8, with a very similar callback pattern, then abstraction layers for node are possible and you could run it off SpiderMonkey. But looking at SpiderMonkey's API, thats doubtful. If it means "SpiderMonkey's JS environment will have a completely congruous API to the v8 JS environment", then that doesn't really make it easier to run node on SpiderMonkey, because a significant abstraction layer would need to be built and some re-organization done before it node's Buffer/Parser classes could work through the layer on both engines, both of which are pretty key to node. However, restructuring for SpiderMonkey would probably make building on top of JSC pretty easy, as its kind of "in the middle" between SM and v8.

[Tim Caswell]

On Fri, May 11, 2012 at 11:23 AM, Stewart Mckinney <lord...@gmail.com> wrote:

1) Pretty tight. The abstraction layer between v8 and node isn't thick enough or generalized enough, from what I can tell. To be fair, writing an abstraction layer between multiple JS engines is very difficult (I am doing such now for a different project, non-web related). JSC and v8, for instance, have *very* different ideas of how to do things. From what I understand, as well, SpiderMonkey has really limited support for passing arbitrary information (void *) in callback functions, which is part of the magic of v8.

Indeed, the SpiderNode project was trying to solve this by adding the V8 API to SpiderMonkey so it could be used as a drop-in replacement.  Also binary node addons use V8 APIs directly.
 

2) Wondering what "runtime API" compatibility means. If it means "SpiderMonkey will have a similar class structure to v8, with a very similar callback pattern, then abstraction layers for node are possible and you could run it off SpiderMonkey. But looking at SpiderMonkey's API, thats doubtful. If it means "SpiderMonkey's JS environment will have a completely congruous API to the v8 JS environment", then that doesn't really make it easier to run node on SpiderMonkey, because a significant abstraction layer would need to be built and some re-organization done before it node's Buffer/Parser classes could work through the layer on both engines, both of which are pretty key to node. However, restructuring for SpiderMonkey would probably make building on top of JSC pretty easy, as its kind of "in the middle" between SM and v8.

I'm working on re-implementing node using libuv + spidermonkey using the native smjs APIs (github.com/creationix/luvmonkey).  As far as I can tell, this will be possible, but most the C++ in node will have to be re-written.  I should be able to reuse a good bit of the js though.  Node has a non-trivial amount of it's standard library written as js modules.  LuvMonkey is still quite early, but the end goal is to be API compatable.  Meaning anything using node public JS APIs will be able to run in LuvMonkey too.  Binary addons won't be portable since they include v8.h and I don't care to bridge that.
 

[Ralphtheninja (Magnus Skog)]

This could very well explain the factor of 5 between the green and purple bar in:

http://vertxproject.files.wordpress.com/2012/05/chart_1.png

> > nodejs+unsubscribe@googlegroups.com

> > For more options, visit this group at
> > http://groups.google.com/group/nodejs?hl=en?hl=en
> >
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to

> nodejs+unsubscribe@googlegroups.com

[Florin Jurcovici]

My take: node'sand vert.x's goals are different. Vert.x aims to make the async programming model available and convenient on the JVM, node's initial goal was to make it easy to develop network networked apps using http.

Node's target aren't highly scalable apps (like for example Google's search request handling), it's something for building a remote control with a web interface for your AVR, automating testing for a web service, mocking out a web server for integration tests of a client application or similar tasks.

Vert.x wants to be serious competition for Akka and a serious alternative to servlet containers for developing network applications, allowing developers to build highly scalable apps, reachable over http but not necessarily tied to the http protocol, easy to deploy, take down, distribute, reconfigure and whatnot.

One is lightweight and focussed on ease of configuration, deployment and development, the other one is heavyweight and focussed on performance. You can't really compare the two unless you plan to use one of them in a context it's not intended for, IMO. I will for sure not give up on either of them, in spite of the performance differences.

[Alex Kocharin]

 

31.10.2013, 23:38, "Florin Jurcovici" <florin.j...@3pillarglobal.com>:

My take: node'sand vert.x's goals are different. Vert.x aims to make the async programming model available and convenient on the JVM, node's initial goal was to make it easy to develop network networked apps using http.

 

Oh come on, it's a java. It has only one advantage, because if you run it on your servers, you can say for sure who ate all the memory without even logging in.

 

 

Node's target aren't highly scalable apps (like for example Google's search request handling),

 

Very wrong. Do you know what "node" name stands for? :)

 

 

it's something for building a remote control with a web interface for your AVR, automating testing for a web service, mocking out a web server for integration tests of a client application or similar tasks.

Vert.x wants to be serious competition for Akka and a serious alternative to servlet containers for developing network applications, allowing developers to build highly scalable apps, reachable over http but not necessarily tied to the http protocol, easy to deploy, take down, distribute, reconfigure and whatnot.

One is lightweight and focussed on ease of configuration, deployment and development, the other one is heavyweight and focussed on performance. You can't really compare the two unless you plan to use one of them in a context it's not intended for, IMO. I will for sure not give up on either of them, in spite of the performance differences.

 

--

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
 

---

You received this message because you are subscribed to the Google Groups "nodejs" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Charlie McConnell]

Philosophical questions:

How does one find year-old node mailing list threads?

Why would one resurrect a year-old node mailing list thread?

This happens with some regularity.  I've got no idea why.

--

Charlie McConnell

[Alex Kocharin]

 

You're replying to the wrong message. I have the same questions though.

 

 

 

01.11.2013, 00:35, "Charlie McConnell" <cha...@charlieistheman.com>:

[Mark Hahn]

> How does one find year-old node mailing list threads?

Easy.  Just google anything and find old threads.

[obastemur]

Although this thread is almost 1 year old, http://nodejx.com/nodejx-vs-vert-x-vs-node-js-cluster/ is another benchmark from today.

Vert.X has its own performance issues with running JS. Indeed node is faster in case the server side JS is doing something!

Personally I wouldn't say something is threat to another because of a simple benchmark result (even including the latest one I just shared). Node has a great performance with JavaScript and it is getting even better!