Codon Looks Very Promising For Super-Fast Python Code

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

  • blackshard
    replied
    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
    That's not the Python language to be blame itself, but perhaps the reference implementation interpreter (CPython) is. They are two separate things, but here in the forum and in the article they are referenced as the same thing, which is untrue.

    Python is slow? No, CPython interpreter is.
    Python has the GIL? No, CPython interpreter has the GIL.

    Said so, others are language-specific features (like late dynamic binding of functions) that prevent interpreter/compiler fine-tuning optimizations. But in general I see no reasons why an hypotetical full-featured Python compiler could not produce a machine-language binary which is in the same order of magnitude in terms of speed of C/C++

    Leave a comment:


  • evert_mouw
    replied
    But can it beat Julia?

    Leave a comment:


  • lowflyer
    replied
    Super fast Python ????

    sounds like polishing a turd.

    Leave a comment:


  • Ironmask
    replied
    I just hope it's actually sane to embed in programs. CPython is an absolute nightmare to embed for several reasons. Especially for Rust which doesn't really have any other decent scripting languages available, except maybe Lua (which I'm not a huge fan of). A huge problem is how the global lock is for the entire process, even other VM instances. The runtime is as insane and stupid as the language itself (but I'm not gonna lie, I don't know of a better scripting language, at least in terms of personal preference.)

    Probably just going to go with a strongly-typed minimal Scheme-like custom language for my project. But I would have used something a little more standard if it existed and wasn't implemented by a psychotic chimp.

    It's pretty insane how many dumb-as-bricks scripting languages exist that actually expect to be used independently and make embedding them a second thought, if not impossible. Like, what else is it gonna be used for?

    Leave a comment:


  • acobar
    replied
    I don't know why Python attracts so much negativity, after all, it plays an important role​ in CS: it is so sluggish when applied to trivial algorithms, that it forces its users to learn better and more complex methods to achieve minimally bearable performance for mundane activities.

    Leave a comment:


  • Brane215
    replied
    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.


    Leave a comment:


  • slalomsk8er
    replied
    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.

    Leave a comment:


  • bachchain
    replied
    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.

    Leave a comment:


  • uid313
    replied
    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.

    Leave a comment:


  • AlanTuring69
    replied
    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.

    Leave a comment:

Working...
X