3 ms·

The thing that trips me out is I kept seeing opposite claims in R&D: undefined behavior can improve performance a lot; using type-directed compilation can impro

The thing that trips me out is I kept seeing opposite claims in R&D: undefined behavior can improve performance a lot; using type-directed compilation can improve performance a lot. Most compilers rely on undefined behavior for aggressive optimizations. I wonder what the cutting-edge is on opposite end for type-safe languages and type-directed optimizations. FLINT for SML is the first one I saw like that: http://flint.cs.yale.edu/flint/publications/tcps.html http://flint.cs.yale.edu/flint/publications/tcps.html

erlehmann_ 10y ago
To me, undefined behaviour analysis and typing analysis seem very similar: Both allow a compiler to infer things that can help improve performance … So why do you see the claims that both can help performance as “opposite”?
- nickpsecurity 10y ago
  One claims to be undefined. One claims to use typed things to produce other typed things. I could see them doing similar or dissimilar things. Undefined vs specific types just seemed opposite to me.
  - fasquoika 10y ago
    The thing about undefined behavior is that it means the compiler can do whatever it wants. Most of the time, since the compiler wants to create efficient code, it can just assume that invalid values won't occur the same way a type system can allow a compiler to know that invalid values can't occur. EDIT: More information here http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
    - nickpsecurity 10y ago
      Appreciate the link.
- saurik 10y ago
  The type system proves things about my program that must be true and disallows invalid programs. The undefined behavior system decides things about my program that may or may not be true and just breaks my program when one of us is wrong (and I don't even care who: whether it is the compiler that came up with something insane or me trying to do the impossible <- I honestly don't care).
  - erlehmann_ 10y ago
    I think when undefined behaviour is used for optimizations the programmer does not want it is more of a misunderstanding than one party (programmer or compiler) necessarily being “wrong”, as a compiler assumes that a program should make sense (i.e. is not undefined) and infers things from that. To clarify, would you say that assumption is problematic?
dbaupp 10y ago
They're not at all opposite: one can think of reasoning about types as reasoning about UB. For instance, if a value is of type `int`, it's undefined behaviour for it to be of type `float`, and so the compiler can optimise based on this fact (there's just the added bonus that the compiler also checks this UB "perfectly": code won't violate the rules). Essentially, undefined behaviour exposed to the user is an extra layer of "types"/rules on top of the underlying type system, both of which the compiler can use for optimisation purposes (but only one of which the compiler checks for the programmer). More and more advanced type systems can push more of the former into the latter (e.g. for index-out-of-bounds, in the limit, dependent typing can allow one to statically ensure that all integers are in range of the arrays they index).
mnarayan01 10y ago
Most of the complaints about UB-based optimization that I've seen are from when the compiler uses UB to assume some type restraint that the programmer wishes it did not. E.g.: int v = *p; if (p == NULL) { /* ... */ } The compiler uses UB to annotate the type information on p to indicate it's non-null, and then performs type-directed optimization.
- posterboy 10y ago
  > then performs type-directed optimization. which can mean erasure of the if block, to be perfectly clear here. edit: any good compiler will warn about the assignment or throw an error, though, using the right compiler options.

erlehmann_ 10y ago

To me, undefined behaviour analysis and typing analysis seem very similar: Both allow a compiler to infer things that can help improve performance … So why do you see the claims that both can help performance as “opposite”?

nickpsecurity 10y ago
One claims to be undefined. One claims to use typed things to produce other typed things. I could see them doing similar or dissimilar things. Undefined vs specific types just seemed opposite to me.
- fasquoika 10y ago
  The thing about undefined behavior is that it means the compiler can do whatever it wants. Most of the time, since the compiler wants to create efficient code, it can just assume that invalid values won't occur the same way a type system can allow a compiler to know that invalid values can't occur. EDIT: More information here http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
  - nickpsecurity 10y ago
    Appreciate the link.
saurik 10y ago
The type system proves things about my program that must be true and disallows invalid programs. The undefined behavior system decides things about my program that may or may not be true and just breaks my program when one of us is wrong (and I don't even care who: whether it is the compiler that came up with something insane or me trying to do the impossible <- I honestly don't care).
- erlehmann_ 10y ago
  I think when undefined behaviour is used for optimizations the programmer does not want it is more of a misunderstanding than one party (programmer or compiler) necessarily being “wrong”, as a compiler assumes that a program should make sense (i.e. is not undefined) and infers things from that. To clarify, would you say that assumption is problematic?

dbaupp 10y ago

They're not at all opposite: one can think of reasoning about types as reasoning about UB. For instance, if a value is of type `int`, it's undefined behaviour for it to be of type `float`, and so the compiler can optimise based on this fact (there's just the added bonus that the compiler also checks this UB "perfectly": code won't violate the rules). Essentially, undefined behaviour exposed to the user is an extra layer of "types"/rules on top of the underlying type system, both of which the compiler can use for optimisation purposes (but only one of which the compiler checks for the programmer). More and more advanced type systems can push more of the former into the latter (e.g. for index-out-of-bounds, in the limit, dependent typing can allow one to statically ensure that all integers are in range of the arrays they index).

mnarayan01 10y ago

Most of the complaints about UB-based optimization that I've seen are from when the compiler uses UB to assume some type restraint that the programmer wishes it did not. E.g.: int v = *p; if (p == NULL) { /* ... */ } The compiler uses UB to annotate the type information on p to indicate it's non-null, and then performs type-directed optimization.

posterboy 10y ago
> then performs type-directed optimization. which can mean erasure of the if block, to be perfectly clear here. edit: any good compiler will warn about the assignment or throw an error, though, using the right compiler options.