• vrighter@discuss.tchncs.de
    link
    fedilink
    arrow-up
    9
    arrow-down
    1
    ·
    22 hours ago

    python is a language explicitly designed to resist any form of proper optimization. It just can’t be made fast

    • Corbin@programming.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      6 hours ago

      This is a common misconception! It is true that, of the Smalltalk descendants, Python was not designed for speed like Self or Java; but it was not designed to be slow or difficult to compile. The main technique required to implement a Python JIT is virtualizable objects, which allows the JIT to temporarily desynchronize the contents of registers from the contents of the heap; it’s not obvious and wasn’t in the first few iterations of PyPy. Additionally, it turns out that tracing the meta-level (see docs or the paper) is a key trick: instead of JIT’ing the Python program, the JIT operates on the interpreter, on the Python VM itself!

      • FizzyOrange@programming.dev
        link
        fedilink
        arrow-up
        2
        arrow-down
        1
        ·
        20 hours ago

        That ignores just how slow it is. It’s on the order of 100x slower than “fast” languages like Rust and Go, so doubling in speed… while nice for Python Devs doesn’t really make it fast on an absolute scale. They need to double it’s speed a few more times at least.

  • Lemminary@lemmy.world
    link
    fedilink
    arrow-up
    6
    arrow-down
    7
    ·
    22 hours ago

    Please don’t show a close-up image of a snake, or at least add a spoiler! It’s irrelevant to the topic, and it just sets some of us on edge for no good reason. If it’s small, it’s fine, but this… holy shit, now I have a headache. It’s one of the reasons I stopped coding in Python altogether.

  • Narann@jlai.lu
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    1
    ·
    2 days ago

    Python typing system is the reason of its huge flexibility, but as many other scripting language, it’s also what makes it so hard to optimize.

    I have no idea how you can change that without bringing some “JIT-oriented” features inside the Python language itself.

    I still hope for the best, but I’m unsure we will be able to see an efficient JIT system inside CPython soon.

    PyPy had to rewrite the whole Python implementation in a JIT focused way, and even with that, they are (not uncommon) cases when PyPy is slower.

    • Corbin@programming.dev
      link
      fedilink
      English
      arrow-up
      3
      ·
      22 hours ago

      I gather that you don’t actually use PyPy much. On average, I expect PyPy to deliver over a 3x speedup. The main issue is that people have built upon slow libraries like Numpy that only seem fast because CPython is even slower.

      The reason that CPython cannot have a JIT added on is architectural and political. The CPython core team refuses to learn lessons from PyPy.

      • logging_strict@programming.dev
        link
        fedilink
        arrow-up
        1
        arrow-down
        3
        ·
        edit-2
        1 day ago

        i’m a fan of ladies with complete test coverage

        but i’m ok with those who are a fan of type inference.

        More ladies for me

  • henfredemars@infosec.pub
    link
    fedilink
    English
    arrow-up
    16
    ·
    edit-2
    2 days ago

    This is not entirely fair because the comparison point has changed. CPython is getting much faster, too, thanks to the optimizations stages before the JIT runs.

  • 🇨🇦 tunetardis@piefed.ca
    link
    fedilink
    English
    arrow-up
    5
    ·
    2 days ago

    Microsoft cancelled its support for the Faster CPython project in May this year, as part of a round of layoffs

    wtf did they actually axe Guido? I thought he was heavily involved in that.