3 ms·

> 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/44

> 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 7y 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 7y 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?
  - pron 7y ago
    The methods are not constant: def foo Array.send(:define_method, :sort) do; [100, 200]; end end puts eval([1, 2, 3].inspect).sort[1] * 2 foo puts eval([1, 2, 3].inspect).sort[1] * 2 But, anyway, my points isn't about partial-evaluation of values specifically (although JITs can and do do that); instead of int and 2 you can consider a type with 4 billion subtypes. JITs do specializations that an AOT simply cannot possibly do (not without code explosion). Now, as I wrote in the original comment, I'm definitely not saying that JIT compilation is "better" than AOT. I am saying that the "zero-cost abstraction" philosophy of C++/Rust and the "zero-cost use" philosophy of JITs are two extremes that are each perfectly suited to two very different software domains.

pron 7y 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 7y 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?
- pron 7y ago
  The methods are not constant: def foo Array.send(:define_method, :sort) do; [100, 200]; end end puts eval([1, 2, 3].inspect).sort[1] * 2 foo puts eval([1, 2, 3].inspect).sort[1] * 2 But, anyway, my points isn't about partial-evaluation of values specifically (although JITs can and do do that); instead of int and 2 you can consider a type with 4 billion subtypes. JITs do specializations that an AOT simply cannot possibly do (not without code explosion). Now, as I wrote in the original comment, I'm definitely not saying that JIT compilation is "better" than AOT. I am saying that the "zero-cost abstraction" philosophy of C++/Rust and the "zero-cost use" philosophy of JITs are two extremes that are each perfectly suited to two very different software domains.