4 ms·

Node has threads in C++ for that sort of thing. Async programming is a big deal for performance. That's essentially the main reason Node is any faster than Pyth

by jrs95 9y ago

Node has threads in C++ for that sort of thing. Async programming is a big deal for performance. That's essentially the main reason Node is any faster than Python. If you use fully async Python on uvloop, you can get comparable performance.

balfirevic 9y ago
It is ultimately a failure of language and runtime that programmer has to manually specify where he wants to make asynchronous vs. synchronous functions to get the optimal performance. This blog posts elaborates on that better then I could do here, so I'm just going to link to it: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
- jcelerier 9y ago
  > that programmer has to manually specify where he wants to make asynchronous vs. synchronous functions to get the optimal performance. programs aren't just pure computations. There are plenty of times when you want a specific event to happen at a specific time (as in, wall-clock), and plenty of times when you don't care when something computes as long as you end up getting a result at some point.
  - throwasehasdwi 9y ago
    You don't get reliable wall clock time unless you're working in RTOS. In a threaded OS everything in userland is async to an extent. In this school of thought, having to specify that something should be async manually could be seen as a failure of the language.
    - jcelerier 9y ago
      on recent good hardware there is no problem being around 1ms accuracy.
  - balfirevic 9y ago
    Yes, but that should be call-time distinction, not a function declaration distinction. This is briefly mentioned at the end of the linked article. Edit: as other poster mentioned, async/await and promises also don't help with precise wall-clock time but that is entirely different matter.
coldtea 9y ago
>That's essentially the main reason Node is any faster than Python. v8's JIT is many times faster than Python in CPU bound tasks without any asynchronicity involved.
flamedoge 9y ago
Python also has async/await

by jrs95 9y ago

balfirevic 9y ago

It is ultimately a failure of language and runtime that programmer has to manually specify where he wants to make asynchronous vs. synchronous functions to get the optimal performance. This blog posts elaborates on that better then I could do here, so I'm just going to link to it: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

jcelerier 9y ago
> that programmer has to manually specify where he wants to make asynchronous vs. synchronous functions to get the optimal performance. programs aren't just pure computations. There are plenty of times when you want a specific event to happen at a specific time (as in, wall-clock), and plenty of times when you don't care when something computes as long as you end up getting a result at some point.
- throwasehasdwi 9y ago
  You don't get reliable wall clock time unless you're working in RTOS. In a threaded OS everything in userland is async to an extent. In this school of thought, having to specify that something should be async manually could be seen as a failure of the language.
  - jcelerier 9y ago
    on recent good hardware there is no problem being around 1ms accuracy.
- balfirevic 9y ago
  Yes, but that should be call-time distinction, not a function declaration distinction. This is briefly mentioned at the end of the linked article. Edit: as other poster mentioned, async/await and promises also don't help with precise wall-clock time but that is entirely different matter.

coldtea 9y ago

>That's essentially the main reason Node is any faster than Python. v8's JIT is many times faster than Python in CPU bound tasks without any asynchronicity involved.

flamedoge 9y ago

Python also has async/await