4 ms·

We pay a very heavy price for the complexity of modern compilers: slow compilation times even on crazy fast hardware, real-world bugs from undefined behavior pr

We pay a very heavy price for the complexity of modern compilers: slow compilation times even on crazy fast hardware, real-world bugs from undefined behavior propagation, and now here, leaking cryptographic secrets unless heroic engineering efforts are made to prevent it. What we get in return for all that pain is slightly faster execution — in theory. A recent post on HN actually showed that at least in some cases, modern LLVM compiles to code that actually runs 1-2% slower than an ancient LLVM version. Shouldn’t we conclude from all this that what we need is a movement to go back to simple, deterministic and fast compilers?

flerchin 5y ago
> What we get in return for all that pain is slightly faster execution We also get protections against whole classes of security bugs, ala Spectre and other vulns. Some of those protections make speed tradeoffs.
- codeflo 5y ago
  I don’t agree that exploit mitigation is where the bulk of the complexity in the compiler comes from. And if anything, with all the UB inference going on, modern compilers might be more likely to compile exploitable bugs into your code than old ones were. Several well-known examples of this happening exist. (To explain: A decade ago, if there was a code path where you dereference null, you would get a clean crash. Not pretty, and potentially a denial of service, but usually not further exploitable. Nowadays, the compiler will infer that this path is not taken, eliminate the if, potentially eliminate other checks as well because they are then reasoned to be redundant, and then randomly execute something. This is practically more dangerous in a lot more situations than Spectre ever was.)
  - flerchin 5y ago
    It's pretty easy to disable the spectre mitigations, and pretty easy to measure the performance impact (~10% in some workloads).
bastawhiz 5y ago
It would seem to me that your comment only really applies to C or C++ or other similar languages. Modern JavaScript compilers can compile and run code orders of magnitude faster than what was possible fifteen years ago. Many languages have seen dramatic compiler improvements. Maybe the problem is that making big improvements to a compiler for a fifty year old language that sits pretty close to the metal is getting increasingly difficult because the people writing the compilers are running out of clever tricks.
- codeflo 5y ago
  With all respect, we're discussing an article about the difficulty of balancing performance and security in modern compilers in the context of implementing cryptographic primitives. You might use those primitives from JavaScript (Node.js links OpenSSL, for example), not typically implement them in JavaScript.
  - bastawhiz 5y ago
    One of the two compilers discussed in the article is Turbofan because the code in question is being invoked from JavaScript, so I'm not sure how you think JavaScript isn't relevant. We live in an age where not everything, including cryptography, needs to traverse C or C++ to reach machine code (see: Java, Go, etc). Plenty of JavaScript and WASM exists for cryptography purposes, for what it's worth, because Node isn't the only runtime and "native" code isn't easily portable.

flerchin 5y ago

> What we get in return for all that pain is slightly faster execution We also get protections against whole classes of security bugs, ala Spectre and other vulns. Some of those protections make speed tradeoffs.

codeflo 5y ago
I don’t agree that exploit mitigation is where the bulk of the complexity in the compiler comes from. And if anything, with all the UB inference going on, modern compilers might be more likely to compile exploitable bugs into your code than old ones were. Several well-known examples of this happening exist. (To explain: A decade ago, if there was a code path where you dereference null, you would get a clean crash. Not pretty, and potentially a denial of service, but usually not further exploitable. Nowadays, the compiler will infer that this path is not taken, eliminate the if, potentially eliminate other checks as well because they are then reasoned to be redundant, and then randomly execute something. This is practically more dangerous in a lot more situations than Spectre ever was.)
- flerchin 5y ago
  It's pretty easy to disable the spectre mitigations, and pretty easy to measure the performance impact (~10% in some workloads).

bastawhiz 5y ago

It would seem to me that your comment only really applies to C or C++ or other similar languages. Modern JavaScript compilers can compile and run code orders of magnitude faster than what was possible fifteen years ago. Many languages have seen dramatic compiler improvements. Maybe the problem is that making big improvements to a compiler for a fifty year old language that sits pretty close to the metal is getting increasingly difficult because the people writing the compilers are running out of clever tricks.

codeflo 5y ago
With all respect, we're discussing an article about the difficulty of balancing performance and security in modern compilers in the context of implementing cryptographic primitives. You might use those primitives from JavaScript (Node.js links OpenSSL, for example), not typically implement them in JavaScript.
- bastawhiz 5y ago
  One of the two compilers discussed in the article is Turbofan because the code in question is being invoked from JavaScript, so I'm not sure how you think JavaScript isn't relevant. We live in an age where not everything, including cryptography, needs to traverse C or C++ to reach machine code (see: Java, Go, etc). Plenty of JavaScript and WASM exists for cryptography purposes, for what it's worth, because Node isn't the only runtime and "native" code isn't easily portable.