Announcement

Collapse
No announcement yet.

Codon Looks Very Promising For Super-Fast Python Code

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

  • #31
    Originally posted by slalomsk8er View Post

    Some are using python for rapid prototyping and rewrite in C/C++ later with great success.
    Yeah, that is totally valid. I'm just lamenting the amount of over-engineering that goes into a lot of languages that think they are going to take on C in performance, while simultaneously dumbing down the language and "auto optimizing" performance.

    Comment


    • #32
      Originally posted by Barnacle View Post

      Yeah, that is totally valid. I'm just lamenting the amount of over-engineering that goes into a lot of languages that think they are going to take on C in performance, while simultaneously dumbing down the language and "auto optimizing" performance.
      Most languages, specially a Python-derived one, do not have any goals or intentions of targeting C-level performance. C-level performance is something you consider at the very beginning stage of engineering a language and it's runtime. This is just trying to get Python to go as fast as it can possibly go, which will never match C, but it can definitely be improved from the abysmal design of CPython.

      But also, C itself can be optimized a lot. What do you think an optimizing C compiler is? It has to use human intuition to find common patterns in code and rewrite them into a more optimized version. Yeah, if you're a genius or a savant you can do that manually, but most people write inefficient C code and let the compiler try (and sometimes fail and introduce bugs) to optimize it. There are countless computer science theories and experiments for making good programming languages that optimize themselves instead of trying to make a bloated compiler trying to mimic human intuition. Rust for example lets the compiler know a lot of extra things about a program as a fact, instead of trying to "guess" what a C program is trying to do, due to lifetime annotations.

      I don't know if you think like this or not, but just an aside, I find it so disappointing this cult of "C is performance incarnate, no other language can compare" is so prevalent. People need to realize C isn't a magic spell, it compiles to machine code like any other language. All optimizations are how well the tools are made and how smart the tool user is. Tools can always be improved, it's literally cult behavior to imply they can't. C is not the Messiah, it's a tool that can, should, and will be replaced by a better one, because we are human beings and we evolve.

      Comment


      • #33
        Originally posted by Ironmask View Post
        But also, C itself can be optimized a lot. What do you think an optimizing C compiler is? It has to use human intuition to find common patterns in code and rewrite them into a more optimized version.
        This is far from the whole story. CPUs themselves are optimized for C code, down to the ISA. Your favorite vector instruction is probably designed to accelerate a particular function in the C standard library.

        Originally posted by Ironmask View Post
        Yeah, if you're a genius or a savant you can do that manually, but most people write inefficient C code and let the compiler try (and sometimes fail and introduce bugs) to optimize it.
        The people who are not a "genius or savant" should probably just stick to Javascript. It's not some inherent gift to be able to optimize C code properly, but it requires putting forth the effort to attain a base knowledge of how CPU, memory and OS work. If we stop asking developers to know these things, it's just going to result in worse developers who think optimizing their own code is the compiler developer's job. Those same lazy people won't be able to figure out how to properly use C very robust and mature tools for debugging, optimizing and profiling code anyway, so they should just stay away from C, because they won't have a good time with it.

        Originally posted by Ironmask View Post
        There are countless computer science theories and experiments for making good programming languages that optimize themselves instead of trying to make a bloated compiler trying to mimic human intuition. Rust for example lets the compiler know a lot of extra things about a program as a fact, instead of trying to "guess" what a C program is trying to do, due to lifetime annotations.
        Academics gonna academic... Meanwhile, in the real world...

        Originally posted by Ironmask View Post
        I don't know if you think like this or not, but just an aside, I find it so disappointing this cult of "C is performance incarnate, no other language can compare" is so prevalent. People need to realize C isn't a magic spell, it compiles to machine code like any other language. All optimizations are how well the tools are made and how smart the tool user is. Tools can always be improved, it's literally cult behavior to imply they can't. C is not the Messiah, it's a tool that can, should, and will be replaced by a better one, because we are human beings and we evolve.
        What C has going for it is that the core language is extremely low level and properly separates any interaction with the OS kernel from the core language. I would be open to an "improved, modern" replacement for C, but only if it keeps everything that is good about C, and maintains excellent compatibility with C, since the OS is written in C and even POSIX standard states the OS is to be written in C. Thus far, every language attempting to replace C has failed at this, and AFAICT the language designers never even figured out the reasons why, because they didn't properly understand the thing they were attempting to improve upon.

        Golang was pretty close to being a decent language, but they messed up by having horrible interop with C, and the lack of separation between the OS kernel and the core language. Thus Golang became a niche language for web services, and not something that could ever take on C as the language that makes the computing world go round. Rust had even wackier ideas and went full-C++ right from the start, and has yet to really find a niche in anything 14 years later other than "Pacman, but written in Rust!" Github projects.

        Comment


        • #34
          Originally posted by Barnacle View Post
          What C has going for it is that the core language is extremely low level and properly separates any interaction with the OS kernel from the core language. I would be open to an "improved, modern" replacement for C, but only if it keeps everything that is good about C, and maintains excellent compatibility with C, since the OS is written in C and even POSIX standard states the OS is to be written in C. Thus far, every language attempting to replace C has failed at this, and AFAICT the language designers never even figured out the reasons why, because they didn't properly understand the thing they were attempting to improve upon.
          It's largely because of the ABI. C's ABI is painfully simplistic, but also universal. Other languages don't even bother defining an ABI because that pretty much means your language is now completely cemented and can't really be changed anymore, which pretty much flies in the face of the very concept of linguistics, a field that tracks an ever-evolving concept. That's why so many alternatives to C pop up, because people's ideas and values change, and C does not. The only problem with that is then you get runaway amalgamations with no standard ABI like C++.
          There are attempts to make new, stronger universal ABIs for languages to adhere to, but it's kind of under the radar. Most people are just focusing on tools that translate C APIs to other languages, and thats primarily where efforts are headed.

          I've written it in another post in some other thread, but the reason nobody replaced C yet is because every language sucked. C++ sucks (just read Torvalds' rants on it), and no other language is even meant to be low-level, all requiring some huge runtime or GC or exceptions or other silly things. Rust is, somehow, the first unique low-level language to finally fit a gap that hasn't been filled in the last 50 years. It's why you now see it being included in nearly every major C/C++ codebase where no other language has ever done that.

          Originally posted by Barnacle View Post
          Rust had even wackier ideas and went full-C++ right from the start, and has yet to really find a niche in anything 14 years later other than "Pacman, but written in Rust!" Github projects.


          I'm guessing you haven't been on this website in the last 4 or so years, Rust is already in Linux and several companies have rewritten their Go code in Rust.
          It's not reached it's full potential yet, but it's largely replaced Go as an optimized server component, so it's at least already taken over that field, and it's on it's way to becoming the definitive new way to write device drivers. It's certainly showing no sign of slowing down.

          Not to mention how dismissive that "14 year" statement is. It was nothing more than an obscure experiment for the first ten. People only really started to take note of it about 4 years ago (which is around when it hit 1.0), so thats actually some pretty explosive growth.
          Last edited by Ironmask; 26 March 2023, 11:13 PM.

          Comment


          • #35
            Originally posted by Ironmask View Post
            I'm guessing you haven't been on this website in the last 4 or so years, Rust is already in Linux
            I guarantee you that zero lines of Rust code are executing on the Linux kernel system I am posting this from, and I'll even guarantee that none are running on yours. But good to know that you are all in on participation trophies.

            Originally posted by Ironmask View Post
            ...and several companies have rewritten their Go code in Rust.

            It's not reached it's full potential yet, but it's largely replaced Go as an optimized server component, so it's at least already taken over that field, and it's on it's way to becoming the definitive new way to write device drivers. It's certainly showing no sign of slowing down.
            Tell me all about what got replaced, because I am willing to bet it's almost nothing of significance. The biggest "win" to date was NPM server components getting re-written in Rust from Node.js, but I expected nothing less from the people who thought using Javascript as a back-end language was a good idea.

            Originally posted by Ironmask View Post
            Not to mention how dismissive that "14 year" statement is. It was nothing more than an obscure experiment for the first ten. People only really started to take note of it about 4 years ago (which is around when it hit 1.0), so thats actually some pretty explosive growth.
            Nope. The history of Rust is getting invented by Mozilla and used in Firefox, which it pretty much tanked Firefox. Firefox got slower and less featureful when Rust was introduced ("Quantum" update), and they called it progress. Then the Ruby community jumped in circa 10 years ago and brought all of their wacky ideas about programming, more proof that reasonable people shouldn't use it. Then the rest of the history is Rust fanboys, mostly former Ruby fanboys who should be banned from programming, running all over the internet demanding that everything be re-written in Rust.

            Comment

            Working...
            X