Announcement

Collapse
No announcement yet.

Codon Looks Very Promising For Super-Fast Python Code

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by bachchain View Post

    The best compiler in the world can't make up for how Python completely destroys caches and prefetchers by indirecting literally everything
    The article mentions that Codon does not support all dynamic features of Python. This likely means that it omits features that disallow optimizing out these indirections.

    Comment


    • #12
      Originally posted by Vorpal View Post
      Never heard of that license before. Is it open source? Can't find it on https://opensource.org/licenses/... Suspicious...
      Business Source License is proprietary until 3 years have passed since a given commit. This means that old versions will eventually be open source, but not right now: https://github.com/exaloop/codon/blo...ICENSE#L33-L37

      Comment


      • #13
        I wanted to check out how a reference implementation of a thing in Python would stack up against my reimplementation of that thing in C++ when I run it through Codon

        Code:
        naval:2:8-16: error: no module named 'argparse'
        naval:5:6-20: error: no module named 'naval.validate'
        naval:11:22-45: error: cannot import name 'path' from 'os.__init__'
        naval:12:13-24: error: no module named 'ext'
        naval:23:14-109: error: no module named 'argparse'
        naval:25:5-137: error: no module named 'parser'
        naval:26:5-172: error: no module named 'parser'
        naval:27:5-176: error: no module named 'parser'
        naval:28:5-181: error: no module named 'parser'
        naval:30:12-31: error: no module named 'parser'
        naval:31:5-9: error: name 'main' is not defined​
        Not exactly impressed...

        Comment


        • #14
          Originally posted by uid313 View Post
          [*]Functions are declared using the def
          So? It's just a different word; hardly an issue.
          [*]It has the weird "walrus operator" which no other language have and is highly unfamiliar to most people.
          I myself am not a fan of unnecessary syntax; I dislike decorators for the same reason. For a language like Python, the walrus operator is counter-productive. However... it is actually kinda useful.
          I pretty much agree with the rest, but in a few of those cases, it's like using a pipewrench to hammer a nail. Yeah, it'll work, but it's not the right tool for the job.
          Last edited by schmidtbag; 17 March 2023, 09:12 AM.

          Comment


          • #15
            Cython but with PEP 484 type hints, therefore closer-to-real-Python syntax?


            Cython's main advantage is that it lets you selectively optimize routines that don't need to call into CPython's (or PyPy's) dynamic stuff, while also going back into the interpreter for code that either can't be statically compiled or isn't performance-sensitive do begin with. Can Codon do that?

            Edit: also, Cython is already Apache License 2.0 and you don't have to wait until 2025 for it. Not a fan of Codon's licensing... can it still be competitive and seriously taken under consideration during its non-OSI state? Oh well, neat project nonetheless.
            Last edited by chocolate; 17 March 2023, 09:09 AM.

            Comment


            • #16
              Originally posted by uid313 View Post
              Python 3.11 already got much faster, and Python 3.12 is likely to further bring some performance improvements.

              Python has its strengths and maybe it doesn't need to be so fast, it is still valuable for other reasons.

              Python also has its weaknesses:
              • Functions are declared using the def keyword instead of fn, fun, func or function.
              • There is no static keyword, so static class variables have an implicit semantics that isn't obvious and can be rather confusing.
              • It has the weird "walrus operator" which no other language have and is highly unfamiliar to most people.
              • It has its own vanity license.
              • It is difficult to embed into another application.
                • If executing Python code from within a Python application that code will have complete access to all of the application.
                • It is not possible to limit things such as file system access, network access, etc.
              I only rarely use Python professionally but even in my hobbyist usage a lot there isn't really a weakness so much as a difference.
              • Functions are declared using the def keyword instead of fn, fun, func or function. - So? Most of the time functions are not declared with any of those and instead use type, and languages without strict typing use any number of keywords. The same problem with fun vs fn exists for def vs fn.
              • There is no static keyword, so static class variables have an implicit semantics that isn't obvious and can be rather confusing. - Sure.
              • It has the weird "walrus operator" which no other language have and is highly unfamiliar to most people. - I have never seen it used and have never had to use it, but you only need to learn an operator once. It is still way less bad than seeing operators be effectively implemented with macros e.g. C. so not sure how much of a weakness this is. You just Google what it does?
              • It has its own vanity license. - Historical reasons that don't impact current state and functionally makes no difference.
              • It is difficult to embed into another application. - Not really
                • If executing Python code from within a Python application that code will have complete access to all of the application. - Sure.
                • It is not possible to limit things such as file system access, network access, etc. - Sure, but restricting access like that has very limited use-cases that require a disproportionate investment to make it possible since Python is not as simple as it once was. Something like Lua or some DSL would be better for a domain-specific use-case, e.g. game logic and I don't think this is something Python is intended for.
              ​

              Comment


              • #17
                Originally posted by schmidtbag View Post
                So? It's just a different word; hardly an issue.

                I myself am not a fan of unnecessary syntax; I dislike decorators for the same reason. For a language like Python, the walrus operator is counter-productive. However... it is actually kinda useful.
                I pretty much agree with the rest, but in a few of those cases, it's like using a pipewrench to hammer a nail. Yeah, it'll work, but it's not the right tool for the job.
                Yeah, it's just a different word, not a big deal, just one minor point of many little things.

                I like decorators, they are incredible useful in web application frameworks for things like routing, model validation, etc and decorators is common in other languages too so you learn that and apply that knowledge elsewhere, or come from elsewhere and know how they work, I am much more skeptic against language-specific constructs such as the walrus operator.

                Comment


                • #18
                  Originally posted by uid313 View Post
                  It has the weird "walrus operator" which no other language have and is highly unfamiliar to most people.
                  The concept does exist in other languages. Python's implementation is just so bafflingly terrible that it's barely recognizable.

                  Comment


                  • #19
                    Originally posted by sabian2008 View Post

                    Will the compilation myth ever die?

                    Python IS compiled. Look in your execution folder for .pyc files (usually under __pycache__). Those are python bytecode files, the result of a IR compilation of previous runs.

                    Compare the execution of .pyc files with a similar algorithm running through the JVM of Java. The difference can be easily one or two orders of magnitude.

                    The real difference between AOT compilation and JIT compilation is usually O(1), as numerous languages implementation have proven. Python is slow because even adding two ints requires a fairly complex call stack.

                    Lots of optimizarions can be done to CPython because performance was never a priority goal. However, at the end of the day, there is not enough information to map scripts to efficient Assembly instructions.
                    There is a difference between byte code an machine code. Codone compiles to machine code.

                    Comment


                    • #20
                      Not seeing significance of all this.
                      Py'thon is one-off duck-tape tool to quickly cobble nice script to do some offhand job.

                      Morons have mad4e it methastaise all over the place.

                      If you need ultimate speed, use proper tool for the job.
                      C,C++ or even better Rust. OR even assembly for some specific and/or hand-tuned bits.


                      Comment

                      Working...
                      X