> 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.
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.
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.
> 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.
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.
Something that scares me here--where is the awareness of emergent security errors arising from multi-threaded cryptography?
As an example, consider a multithreaded streaming crypto API which consumes a symmetrically-encrypted data stream with an HMAC at the end. If multiple threads are simultaneously decrypting this stream, then how do they synchronize and verify their respective HMACs (let alone one shared one)? Frequently, in my experience, the answer is never--they just pass results blindly to an application thread which then operates on this data. By the time some last thread has belatedly realized that the entire stream was forged,the attacker has already been able to force the application to run malicious code.
Everything in the comment chain from the node core devs seemed very reasonable. Add async crypto support as an option, investigate further whether async crypto should be the default by looking at performance numbers from real-world apps that are using it.
Not exactly sure what the issue is beyond that progress is going pretty slow, but no one has actually submitted a PR for it yet so you'd be arguing for priorities instead of whether they want to support it at all.
"While crypto-async is a fraction slower per call than crypto (possibly because of the overhead of interacting with the threadpool), for buffers larger than 1024 bytes it shines and provides N-cores more throughput. crypto-async achieves up to 3x more throughput."
I doubt we could benefit much from that. That approach would significantly increase latency because of PCI overhead. As mentioned in the OP, most crypto operations are small chunks of data.
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.