5 ms·

I/O is not going to be any faster by having more threads. More threads are not gonna give you more RAM either. And CPU-bound tasks are only faster if the OS you

I/O is not going to be any faster by having more threads. More threads are not gonna give you more RAM either. And CPU-bound tasks are only faster if the OS you are running in exposes multiple CPUs. With VMs and containers with focus on horizontal scaling (many relatively small machines) that is not the case either. Effectively the message-passing communication between threads still exists, but has moved outside the service: done by a load-balancing HTTP router and/or a message broker like RabbitMQ. Another example is when using out-of-process persistence like with Redis.

fundabulousrIII 9y ago
Your paradigm is showing.
- coldtea 9y ago
  Notice how this doesn't even mean anything.
  - fundabulousrIII 9y ago
    Sure it does. Ask a direct question get a direct answer. Backend and file systems, network and systems middleware do not need the abstraction model and overhead of a language designed to add dynamic content to fucking WEBPAGES because it can and it seems easy.
    - atoko 9y ago
      Why not? Performance critical parts can be compiled down, which i'm sure most data store libraries already are
      - fundabulousrIII 9y ago
        My sides.
    - coldtea 9y ago
      >Backend and file systems, network and systems middleware do not need the abstraction model and overhead of a language designed to add dynamic content to fucking WEBPAGES because it can and it seems easy. Well, file systems nobody writes in JS, so that's irrelevant. As for "network and systems middleware" depending on what it does it can be a great fit for JS and especially Node, which is a lightweight logic layer on top of libuv.
      - fundabulousrIII 9y ago
        Too literal. It's the file system syscalls translated into node which are the problem. Anytime you have the potential to block you lose the relatively clean event loop and enter libuv which is a thread provider. 'Lightweight logic layer on top of libuv': well if I can design, predicate and tout my language on 'event' orientation but then when it needs to do something else it becomes a thin logic layer over the hosts threading model: that's just a win!
vardump 9y ago
> I/O is not going to be any faster by having more threads. That's not true on NUMA systems with multiple CPU sockets. You should have at least one thread per NUMA region for optimal results. Critical for example for running multiple 40 or 100 Gbit ethernet adapters. Then again, you probably aren't going to run Node.js on those systems, at least not for handling heavy I/O.
- jononor 9y ago
  As far as I can tell, Node.JS actually does use multiple threads for I/O, both for for networking and filesystem operations. But this implementation detail is not something programmers using it needs to think about.
jcelerier 9y ago
> I/O is not going to be any faster by having more threads. the world doesn't revolve around making HTTP servers. Maybe you aren't writing apps that do parallelizable serial computations but please don't generalize.

fundabulousrIII 9y ago

Your paradigm is showing.

coldtea 9y ago
Notice how this doesn't even mean anything.
- fundabulousrIII 9y ago
  Sure it does. Ask a direct question get a direct answer. Backend and file systems, network and systems middleware do not need the abstraction model and overhead of a language designed to add dynamic content to fucking WEBPAGES because it can and it seems easy.
  - atoko 9y ago
    Why not? Performance critical parts can be compiled down, which i'm sure most data store libraries already are
    - fundabulousrIII 9y ago
      My sides.
  - coldtea 9y ago
    >Backend and file systems, network and systems middleware do not need the abstraction model and overhead of a language designed to add dynamic content to fucking WEBPAGES because it can and it seems easy. Well, file systems nobody writes in JS, so that's irrelevant. As for "network and systems middleware" depending on what it does it can be a great fit for JS and especially Node, which is a lightweight logic layer on top of libuv.
    - fundabulousrIII 9y ago
      Too literal. It's the file system syscalls translated into node which are the problem. Anytime you have the potential to block you lose the relatively clean event loop and enter libuv which is a thread provider. 'Lightweight logic layer on top of libuv': well if I can design, predicate and tout my language on 'event' orientation but then when it needs to do something else it becomes a thin logic layer over the hosts threading model: that's just a win!

vardump 9y ago

> I/O is not going to be any faster by having more threads. That's not true on NUMA systems with multiple CPU sockets. You should have at least one thread per NUMA region for optimal results. Critical for example for running multiple 40 or 100 Gbit ethernet adapters. Then again, you probably aren't going to run Node.js on those systems, at least not for handling heavy I/O.

jononor 9y ago
As far as I can tell, Node.JS actually does use multiple threads for I/O, both for for networking and filesystem operations. But this implementation detail is not something programmers using it needs to think about.

jcelerier 9y ago

> I/O is not going to be any faster by having more threads. the world doesn't revolve around making HTTP servers. Maybe you aren't writing apps that do parallelizable serial computations but please don't generalize.