3 ms·

> Seriously, we really need to ensure together that Node can competently handle concurrent multi-core HMAC on 4GB files, or it's pretty quickly going to fade in

> Seriously, we really need to ensure together that Node can competently handle concurrent multi-core HMAC on 4GB files, or it's pretty quickly going to fade into irrelevance. I am getting really tired of the tendency of engineers to do this: take an argument that "technology X should behave like Y", get some pushback/criticism about it, and then extremitize that argument to "if technology X does not support this one specific use case which requires it to behave like Y, technology X is completely useless". Like, I think I come down towards your side on making sensible heruistics for when to offload CPU-intensive work to other available hardware. I can see a lot of potential drawbacks (implementation-wise and operationally), but it would be a useful capability to have. But falling back to "Node will become irrelevant if you don't do this!" when people don't want to incorporate the library he built into core is both rude and not constructive.

kossae 9y ago
Seriously. Not all of your services have to be Node services either. If there is other computationally intensive work that needs to be done, it can always be handed off to a more performant process.
- jorangreef 9y ago
  Node is just C++ with a threadpool under the hood (think nginx). Fast multi-core crypto is not that hard and shouldn't need a separate service.
jorangreef 9y ago
I purposefully tried to make the comment constructive and inclusive, hence the "we" and "together". Hashing 4GB files may roll some eyes but I don't think it's helpful for Node to be shying away from it or dismissing it out of hand. I don't think that's a positive attitude for Node to have as a community going forward. Stress tests like this should only improve Node. What's there to lose? We should be saying "4GB, bring it on!" Positively speaking, there's so much more we could be doing that we're not. We should be pushing the multi-core data plane side of Node far more than we are. There's so much potential for SIMD etc. in many APIs. Node is C++ under the hood after all. Javascript is just the control plane, not the data plane. And I actually do think Node has been lagging slightly in the performance department, and I don't mind if people call that out. This issue in particular has been open since 2012 (going back to the archives). Lastly, my intention is definitely not to incorporate crypto-async into core. Core crypto has a completely different streaming crypto api. crypto-async was designed more as a stopgap for us at Ronomon in the meantime, but also as a proof-of-concept, to get the ball rolling and show people that the issue was worth pursuing. So I stand by the remark and hope the issue will be a catalyst and wake-up call. Node has had some spectacular success but there's alot of work still to be done.
- pvg 9y ago
  Hashing 4GB files may roll some eyes That sounds kind of unhealthy.
- synthmeat 9y ago
  A lot of pushback is just a kneejerk, but a lot of it is also by people who have a really good mental model how Node works. Changing models is hard and takes time. Personally, I'm all for "multi-core data plane", but done responsibly with future design in mind and over a longer period of time. Great that conversation is happening.
move-on-by 9y ago
> To be clear, I'm not saying that support for async crypto isn't worthwhile, but I'll strenuously object to making it the default without extensive evidence that it doesn't introduce performance regressions. Pretty basic requirement for making performances changes: provide the actual numbers, or GTFO. He was asked multiple times to provide some numbers, sometime indirectly, and then directly in the above quote. Each time he responded with speculation: > My bet would be the async crypto that's running on 8 cores. > what will the latency look like [...]? It's actually going to be through the roof. The op will have been waiting around for a few seconds and the op's latency will be incredible. Missed opportunity to back yourself up with facts, even if the situation is contrived to be the best-case scenario.
- jorangreef 9y ago
  The numbers are all here: https://github.com/ronomon/crypto-async#performance https://github.com/ronomon/crypto-async#performance

kossae 9y ago

Seriously. Not all of your services have to be Node services either. If there is other computationally intensive work that needs to be done, it can always be handed off to a more performant process.

jorangreef 9y ago
Node is just C++ with a threadpool under the hood (think nginx). Fast multi-core crypto is not that hard and shouldn't need a separate service.

jorangreef 9y ago

I purposefully tried to make the comment constructive and inclusive, hence the "we" and "together". Hashing 4GB files may roll some eyes but I don't think it's helpful for Node to be shying away from it or dismissing it out of hand. I don't think that's a positive attitude for Node to have as a community going forward. Stress tests like this should only improve Node. What's there to lose? We should be saying "4GB, bring it on!" Positively speaking, there's so much more we could be doing that we're not. We should be pushing the multi-core data plane side of Node far more than we are. There's so much potential for SIMD etc. in many APIs. Node is C++ under the hood after all. Javascript is just the control plane, not the data plane. And I actually do think Node has been lagging slightly in the performance department, and I don't mind if people call that out. This issue in particular has been open since 2012 (going back to the archives). Lastly, my intention is definitely not to incorporate crypto-async into core. Core crypto has a completely different streaming crypto api. crypto-async was designed more as a stopgap for us at Ronomon in the meantime, but also as a proof-of-concept, to get the ball rolling and show people that the issue was worth pursuing. So I stand by the remark and hope the issue will be a catalyst and wake-up call. Node has had some spectacular success but there's alot of work still to be done.

pvg 9y ago
Hashing 4GB files may roll some eyes That sounds kind of unhealthy.
synthmeat 9y ago
A lot of pushback is just a kneejerk, but a lot of it is also by people who have a really good mental model how Node works. Changing models is hard and takes time. Personally, I'm all for "multi-core data plane", but done responsibly with future design in mind and over a longer period of time. Great that conversation is happening.

move-on-by 9y ago

> To be clear, I'm not saying that support for async crypto isn't worthwhile, but I'll strenuously object to making it the default without extensive evidence that it doesn't introduce performance regressions. Pretty basic requirement for making performances changes: provide the actual numbers, or GTFO. He was asked multiple times to provide some numbers, sometime indirectly, and then directly in the above quote. Each time he responded with speculation: > My bet would be the async crypto that's running on 8 cores. > what will the latency look like [...]? It's actually going to be through the roof. The op will have been waiting around for a few seconds and the op's latency will be incredible. Missed opportunity to back yourself up with facts, even if the situation is contrived to be the best-case scenario.

jorangreef 9y ago
The numbers are all here: https://github.com/ronomon/crypto-async#performance https://github.com/ronomon/crypto-async#performance