4 ms·

> get cross-module inlining, which is all you're really talking about here. Not at all. > There's no actual "specialization" in play, just basic inlining + de

by pron 8y ago

> get cross-module inlining, which is all you're really talking about here. Not at all. > There's no actual "specialization" in play, just basic inlining + dead branch elimination. Devirtualization + inlining + dead branch elimination is an instance of specialization, and an extremely effective one at that, but other forms of specializations apply. > Trivial to do this statically at build time instead. No. Some things are undecidable and/or would lead to code explosion. E.g., it's often hard to statically prove that a subroutine that takes an int would always receive the number 2, and specializing it for all ints would cause code explosion (again, contrived example but with real-world counterparts). > There's also no real reason you can't have zero-cost abstractions AND a JIT if you want. Hell, in theory this is what you get with C++ in a webasm environment. This are not exactly opposing technologies. Of course. But I was talking about two very different philosophies that greatly affect language design.

kllrnohj 8y ago
> Not at all. For your example? Yes, it was. > Devirtualization + inlining + dead branch elimination is an instance of specialization Your example did not involve any devirtualization. > No. Some things are undecidable and/or would lead to code explosion. E.g., it's often hard to statically prove that a subroutine that takes an int would always receive the number 2, and specializing it for all ints would cause code explosion (again, contrived example but with real-world counterparts). Again, your example did not have any such issues. And if it was hard to statically prove a subroutine that takes an int always receives 2 then guess what? A JIT wouldn't do it, either. They don't actually specialize that much for runtime information because gathering that information would destroy performance. Devirtualization? Sure, limited in scope, and huge payoffs to be had for doing it. All arguments analyzed & binned? Good god no. That'd be ludicrous in resource usage required, and the payoffs would be incredibly hard to quantify in any meaningful way. Take your example - all it would do is eliminate a single branch. If it was so common to take a single avenue that it could be eliminated, then pretty much every branch predictor would do it anyway. So... why specialize it?
- pron 8y ago
  > Take your example - all it would do is eliminate a single branch. If it was so common to take a single avenue that it could be eliminated, then pretty much every branch predictor would do it anyway. So... why specialize it? I don't think you've actually read the comment. The particular example is just a demonstration of a principle. Obviously that particular case is too simple to be interesting. > A JIT wouldn't do it, either. Again, you've completely missed the point (read the original comment, perhaps?). In any event, a JIT could and would do it in some cases; e.g.: https://gist.github.com/chrisseaton/4464807d93b972813e49 https://gist.github.com/chrisseaton/4464807d93b972813e49
  - kllrnohj 8y ago
    > In any event, a JIT could and would do it in some cases; e.g.: https://gist.github.com/chrisseaton/4464807d93b972813e49 https://gist.github.com/chrisseaton/4464807d93b972813e49 Uh, what? That's just a basic constant fold optimization that can be statically handled? It even has examples showing anything that would require runtime information (like mutable strings) don't get optimized.
    - pron 8y ago
      > That's just a basic constant fold optimization that can be statically handled Incorrect. No static analysis can establish the constant in some of those cases if only because they are not provably constant. If the situation changes at runtime, those routines would need to be deoptimized and recompiled. > It even has examples showing anything that would require runtime information (like mutable strings) don't get optimized. The example does not show that "anything that would require runtime information don't get optimized" just that that case doesn't. I don't know Ruby, but I can imagine why guarding the constness of a mutable array may not be advisable.
      - kllrnohj 8y ago
        > Incorrect. No static analysis can establish the constant in some of those cases if only because they are not provably constant. Which one of those is not probably constant? They all are literally hardcoded constants?

by pron 8y ago

kllrnohj 8y ago

> Not at all. For your example? Yes, it was. > Devirtualization + inlining + dead branch elimination is an instance of specialization Your example did not involve any devirtualization. > No. Some things are undecidable and/or would lead to code explosion. E.g., it's often hard to statically prove that a subroutine that takes an int would always receive the number 2, and specializing it for all ints would cause code explosion (again, contrived example but with real-world counterparts). Again, your example did not have any such issues. And if it was hard to statically prove a subroutine that takes an int always receives 2 then guess what? A JIT wouldn't do it, either. They don't actually specialize that much for runtime information because gathering that information would destroy performance. Devirtualization? Sure, limited in scope, and huge payoffs to be had for doing it. All arguments analyzed & binned? Good god no. That'd be ludicrous in resource usage required, and the payoffs would be incredibly hard to quantify in any meaningful way. Take your example - all it would do is eliminate a single branch. If it was so common to take a single avenue that it could be eliminated, then pretty much every branch predictor would do it anyway. So... why specialize it?

pron 8y ago
> Take your example - all it would do is eliminate a single branch. If it was so common to take a single avenue that it could be eliminated, then pretty much every branch predictor would do it anyway. So... why specialize it? I don't think you've actually read the comment. The particular example is just a demonstration of a principle. Obviously that particular case is too simple to be interesting. > A JIT wouldn't do it, either. Again, you've completely missed the point (read the original comment, perhaps?). In any event, a JIT could and would do it in some cases; e.g.: https://gist.github.com/chrisseaton/4464807d93b972813e49 https://gist.github.com/chrisseaton/4464807d93b972813e49
- kllrnohj 8y ago
  > In any event, a JIT could and would do it in some cases; e.g.: https://gist.github.com/chrisseaton/4464807d93b972813e49 https://gist.github.com/chrisseaton/4464807d93b972813e49 Uh, what? That's just a basic constant fold optimization that can be statically handled? It even has examples showing anything that would require runtime information (like mutable strings) don't get optimized.
  - pron 8y ago
    > That's just a basic constant fold optimization that can be statically handled Incorrect. No static analysis can establish the constant in some of those cases if only because they are not provably constant. If the situation changes at runtime, those routines would need to be deoptimized and recompiled. > It even has examples showing anything that would require runtime information (like mutable strings) don't get optimized. The example does not show that "anything that would require runtime information don't get optimized" just that that case doesn't. I don't know Ruby, but I can imagine why guarding the constness of a mutable array may not be advisable.
    - kllrnohj 8y ago
      > Incorrect. No static analysis can establish the constant in some of those cases if only because they are not provably constant. Which one of those is not probably constant? They all are literally hardcoded constants?