5 ms·

(Seems like an "embarrassingly serial" problem -- a smarter lua could turn it into a single "set c = 1e9" instruction.)

• vidarh 11y ago
  It could, but then we're getting into hairy language definition issues: Does Lua specify at what point updates need to hit memory? And this example is perfect example of why a language ought to be explicit about such guarantees - in this case such a change would have observable effects. Changing observable effects in optimizations is dangerous territory even when it's well defined.
  • Dylan16807 11y ago
    What's memory? Lua's much more high level than that, and it makes no promises about timing at all.
    • josefx 11y ago
      That has nothing to do with high level, C++ for example also had no built-in guarantees for a long time. Making no promises about timing simply means that threading is either a non concept in the language (see C++ before 11) or the language declares everything to do with threading unspecified or undefined.
      • Dylan16807 11y ago
        C++ has volatile.
    • vidarh 11y ago
      That's all nice when you don't need to know the effects of your code. It breaks apart the moment you want to interface with a system (like Snabbswitch) that uses memory as an IO mechanism, at which point if you can't depend on language guarantees, you need to depend on implementation guarantees - the same point stands.
      • Dylan16807 11y ago
        There's not really any downside to wrapping that interface in function calls, and then you don't have to worry about optimization.
        • vidarh 11y ago
          There's a very real downside: Massive (relative to just adjusting a value in memory) overhead.
          • Dylan16807 11y ago
            We're talking about Lua. Either the whole thing is interpreted or the memory access is trivially inlined. Neither gives you noticeable overhead.
            • vidarh 11y ago
              > Either the whole thing is interpreted or the memory access is trivially inlined. In the context of a discussion about the extent of optimization which can be done, if it is inlined, then we're back to square one and do have to worry about optimization. Your argument is circular.
              • Dylan16807 11y ago
                I mean inlining it opaquely. The optimizer won't alter the injected machine code. (Either because it already ran, or because it manipulates something other than machine code, or because the injected opcodes are marked as untouchable.) Treating things as a function call when optimizing is actually a really good way to preserve volatile memory accesses even in something as complex as a C compiler.
                • vidarh 11y ago
                  Inlining a function opaquely is a very weird thing for an optimizer to do without special annotation as it looses a substantial proportion of the benefit of inlining. And it would certainly be a weird thing to do for a hypothetical optimizer as aggressive as what was the starting point for this thread - namely one willing to e.g. partially evaluate even loop contents during compilation. In any case this again goes back to my original point: The importance for a language of defining the semantics of when updates hits memory. So we're back to the starting point.