4 ms·
In the >12 years your code has been around, Moore's law suggests that it would have got 2^8 = 256 times faster. Even though that law has slowed, there is signif
by Jabbles 8y ago
In the >12 years your code has been around, Moore's law suggests that it would have got 2^8 = 256 times faster. Even though that law has slowed, there is significantly more processing power available now than when you started. Are you sure the requirements for your service being "fast" are as critical as you think?
- pjc50 8y agoOnly if the hardware is updated. I maintain an old MFC codebase that has to run on 15 year old 400MHz MIPS systems that don't belong to us.
- pjmlp 8y agoYou're keeping a Windows NT alive?!
- pjc50 8y agoWindows CE (various extremely obsolete versions). The GUI side is quite convenient, since you can cross-develop from a normal desktop. The systems side is more of a problem, since the user community is almost non-existant.
- pjmlp 8y agoOh I completely forgot there was a MFC variant for CE, hence my NT remark.
- scottlamb 8y agoIn short, yes: * CPU time per request: we do more work than we used to on average. For example, we do more asymmetric cryptographic operations now, and since introducing those operations we've increased the lengths of the keys. CPU time per request contributes not only to cost but to user-facing latency. * overall request rate: we handle >256X as many requests as we did 12 years ago. Those reasons are particular to my service, but I'd say the continued usage of C++ is convincing proof that plenty of people are willing to go to considerable effort to improve latency and efficiency. It'd be a lot easier to write things in a higher-level, GCed language otherwise.
- jnbiche 8y ago> we do more asymmetric cryptographic operations now Could you use session keys to take some of the load off, exchanged using asymmetric crypto, or are you already doing that? Also, cool thing about Rust is that you can start writing parts of a C or C++ code base in Rust, and slowly switch over. This is exactly what Firefox is doing with their browser. Could you convince your company to let you try to rewrite a small part in Rust?
- scottlamb 8y agoWe've already picked the low-hanging fruit in terms of our protocol and implementation. And no matter how much I'd love to, rewriting in Rust at work is not gonna happen any time soon. There's tons of support built up for the major languages in terms of build tools, IDEs, code cross-referencing, automated refactoring, style guides, libraries, etc. It's understandably a difficult process to get a language added to that list. Besides, my team struggles to find time to just modernize our C++. I wouldn't want to start converting to another language until I find time/staffing to actually commit to carrying through. And I know from trying it at home that rewriting a project in Rust takes me longer than expected and bindgen's C++ compatibility is less than perfect. So I get my Rust fix with personal projects instead (when I can find time).
- blake_himself 8y agoclang modernize? It'll do the small-scale fixes for you. But, though this was a while ago, it messed up the text when I used it. You could tell what it was /supposed/ to be, though, and wouldn't compile. But it may be better, now.
- snaky 8y agoThis might be interesting then > We introduce a new approach for implementing cryptographic arithmetic in short high-level code with machine-checked proofs of functional correctness. We further demonstrate that simple partial evaluation is sufficient to transform into the fastest-known C code, breaking the decades-old pattern that the only fast implementations are those whose instruction-level steps were written out by hand. > These techniques were used to build an elliptic-curve library that achieves competitive performance for 80 prime fields and multiple CPU architectures, showing that implementation and proof effort scales with the number and complexity of conceptually different algorithms, not their use cases. As one outcome, we present the first verified high-performance implementation of P-256, the most widely used elliptic curve. Implementations from our library were included in BoringSSL to replace existing specialized code, for inclusion in several large deployments for Chrome, Android, and CloudFlare. http://adam.chlipala.net/papers/FiatCryptoSP19/ http://adam.chlipala.net/papers/FiatCryptoSP19/