4 ms·

I beg to differ with node being the "best choice" for IO intensive ops. Java performance will be better on IO as well, as long as you're using NIO or something

I beg to differ with node being the "best choice" for IO intensive ops. Java performance will be better on IO as well, as long as you're using NIO or something like EPOLL native bindings in Netty, which is asynchronous like node but also multi threaded. The point is that node is not that fast. If performance is paramount don't use it. Node really shines when you need to use client side libraries on the server. The two best uses I've seen is server side rendering of pages and html5 canvas for browser based painting apps

klodolph 10y ago
This is a bit of a fine point to make here, but it's not necessary to use stuff like NIO or EPOLL for all IO intensive programs. It depends on the amount of time you expect the threads to be waiting. If the wait times are low, you can expect traditional IO and threads to be quite competitive. EPOLL / NIO is still great for stuff like HTTP front-ends.
- ec109685 10y ago
  Because of HTTP keep alives?
  - klodolph 10y ago
    Yes, that's exactly right. But there's also factors like the slow loris attack, where malicious clients hold a connection open and send a few bytes at a time, never completing the HTTP request. For these attacks, it makes sense for client connections to use the smallest amount of server resources feasible.
doctorpangloss 10y ago
In line with my experience as a Java 8 NIO and latest node user, node basically performs identically to the best Netty implementation in IO-bound tasks. That parity could be attributed to relentless optimization of a fundamentally pretty straightforward problem in V8 that finally made it to the latest node. My experience matches the TechEmpower benchmarks, which you should check out here: https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ . They didn't get much discussion when posted.
- nrjdhsbsid 10y ago
  Fortunes is not IO bound. Plaintext bench definitely is and node is around 8x slower than the fastest frameworks. Node is nowhere near raw netty performance in most situations and will never be. Js is single threaded, dynamically typed, and doesn't have low enough level access to the OS. Netty has a native network IO interface on linux. Node is pretty respectable but netty is basically the fastest thing there is unless you're doing C. It even uses native zero copy buffers with the ByteBuf implementation, something js doesn't (and cannot) do with its dynamic typing. The JVM has had a much longer period of relentless optimization and the language was designed to be well optimized. Js will never escape the performance penalty of dynamic typing and other decisions without a rewrite
blakecaldwell 10y ago
I spend most of my time in Go these days, and find that it's goroutine model is perfectly suited for both I/O and CPU-bound services. The runtime decides if a thread is needed, and will spawn one any time you're waiting on a syscall.
blakecaldwell 10y ago
I spend most of my time in Go these days, and find that it's goroutine model is perfectly suited for both I/O and CPU-bound services. The runtime decides if a thread is needed, and will spawn one any time you're waiting on a syscall.

klodolph 10y ago

This is a bit of a fine point to make here, but it's not necessary to use stuff like NIO or EPOLL for all IO intensive programs. It depends on the amount of time you expect the threads to be waiting. If the wait times are low, you can expect traditional IO and threads to be quite competitive. EPOLL / NIO is still great for stuff like HTTP front-ends.

ec109685 10y ago
Because of HTTP keep alives?
- klodolph 10y ago
  Yes, that's exactly right. But there's also factors like the slow loris attack, where malicious clients hold a connection open and send a few bytes at a time, never completing the HTTP request. For these attacks, it makes sense for client connections to use the smallest amount of server resources feasible.

doctorpangloss 10y ago

In line with my experience as a Java 8 NIO and latest node user, node basically performs identically to the best Netty implementation in IO-bound tasks. That parity could be attributed to relentless optimization of a fundamentally pretty straightforward problem in V8 that finally made it to the latest node. My experience matches the TechEmpower benchmarks, which you should check out here: https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ . They didn't get much discussion when posted.

nrjdhsbsid 10y ago
Fortunes is not IO bound. Plaintext bench definitely is and node is around 8x slower than the fastest frameworks. Node is nowhere near raw netty performance in most situations and will never be. Js is single threaded, dynamically typed, and doesn't have low enough level access to the OS. Netty has a native network IO interface on linux. Node is pretty respectable but netty is basically the fastest thing there is unless you're doing C. It even uses native zero copy buffers with the ByteBuf implementation, something js doesn't (and cannot) do with its dynamic typing. The JVM has had a much longer period of relentless optimization and the language was designed to be well optimized. Js will never escape the performance penalty of dynamic typing and other decisions without a rewrite

blakecaldwell 10y ago

I spend most of my time in Go these days, and find that it's goroutine model is perfectly suited for both I/O and CPU-bound services. The runtime decides if a thread is needed, and will spawn one any time you're waiting on a syscall.

blakecaldwell 10y ago