3 ms·

I thought it was a parsing issue in Python when doing "import taichi as ti" vs "import taichi". No it's just presenting Taichi, a Python package to do parallel

• rjh29 4y ago
  Me too - it wouldn't be unheard of in a language where referencing multiple.levels.of.variable in a loop is orders of magnitude slower than doing "a = multiple.levels.of.variable" outside the loop and referencing a inside of it. *may have been fixed in recent versions of Python - I heard of this many years ago!
  • stingraycharles 4y ago
    Isn’t that expected behaviour, as you’re only looking up “a” once when you do it outside the loop, while doing it every time when inside the loop? Because any reference in the whole hierarchy could change during the looping (e.g. one could say “multiple.levels = {}” at some point), the interpreter really would need to check it every time unless it can somehow “prove” that these changes will never happen / haven’t happened. Just keeping a reference to “a” is semantically very different, and I’d consider that a normal optimisation.
    • 20after4 4y ago
      The issue is just how slow python is, it takes a very long time to resolve those references. So it's expected that the multiple.levels.of.dereference would be slower but it's perhaps orders of magnitude slower where in another language it might be much less of a performance hit.
      • stingraycharles 4y ago
        Maybe, but then the loop has nothing to do with it, and the problem is rather the slow lookups.
  • nerdponx 4y ago
    Historically this was a legitimate performance micro-optimization in Python: def f(i): ... def g(): _f = f for i in range(100000): _f(i) because looking up a local variable was faster than looking up a global. I'm not sure if that's still true in newer versions.
    • nequo 4y ago
      Sounds like Lua. But I see no difference in execution time with Python 3.10.
• deleted 4y ago
  [deleted]