4 ms·

Mmm, "faster than node.js" isn't a great benchmark out in the wide world. Although node.js being as fast as it is remains an astonishing thing.

by mathw 10y ago

quotemstr 10y ago
Who cares about the speed of the interpreter? The interpreter's job is to orchestrate high-performance components written in some high-performance language. If your interpreter is dominating execution time, you should move some of your logic to native code.
- pjmlp 10y ago
  Better not use an interpreter in first place, rather a language with REPL that allows compilation straight to native code.
  - quotemstr 10y ago
    Why? Native code is costly: machine code generally has a much bigger footprint than interpreter bytecode. In some cases, interpreted code can be faster due to cache effects and reduced IO load making it faster to be smaller.
    - pjmlp 10y ago
      I am yet to see such benefits in action. The fact that Google has started this project to migrate away from Python to an AOT compiled language, shows where the performance wins are.
      - scriptkiddy 10y ago
        >I am yet to see such benefits in action. Here you go: https://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-again-string.html https://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-... https://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-carefully-crafted.html https://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-... For more examples, just search "pypy faster than c". Also, here is an article from the Python wiki about why speed doesn't really matter a lot of the time: https://wiki.python.org/moin/PythonSpeed https://wiki.python.org/moin/PythonSpeed And, my own two cents: Speed is relative. Does every piece of code need to be as performant as possible? No. I would argue that, in most cases, speed of development is far more important than speed of execution. This is, of course, not true for things like drivers or statistical analysis. Writing a web application? Speed isn't that important as the whole process is i/o bound anyways. Writing a machine learning algorithm? Depends. Web scraping? I/O bound, speed not really important. Image processing? Speed matters at least a little bit. Writing networking glue for distributed systems? Speed probably doesn't matter. It's all relative. If it needs to be fast, it needs to be fast. Most things don't really need to be fast. For the things that don't need to be fast, why build them with C/C++/Rust/Go when you could spend half the time building them in Python/Ruby/js/etc?
        pjmlp 10y ago
        PyPy isn't an interpreter, you are just validating my assertion about JIT/AOT compilers. I usually ignore it when talking about Python, because that is what the community does, by gathering around CPython. > For the things that don't need to be fast, why build them with C/C++/Rust/Go when you could spend half the time building them in Python/Ruby/js/etc? Because one can use languages like OCaml, Haskell, Lisp, Scheme, Racket, F#, C#,... thus having both the productivity of a REPL environment and the execution speed of native code.
        scriptkiddy 10y ago
        >PyPy isn't an interpreter, you are just validating my assertion about JIT/AOT compilers. I thought we were talking about Python implementations exclusively. My mistake. >OCaml I have no experience with OCaml, so I won't make any comments regarding it's efficacy.' >Haskell Well thought out language. I like the purity, but it's too academic for real world use outside of scientific computing. FP isn't for everyone, and my personally belief regarding it is that it is better used as a tool alongside other paradigms than all by itself as the only paradigm. >Lisp Lisp is useful for a lot of things. It's also not very popular for new projects as far as I've seen. There are also a ton of different versions, so I don't know if "Lisp" is really a good descriptor. >Scheme As far as I know Scheme is the defacto teaching language for most compSci programs.Or, at least it was for a long time. Once again, FP is not for everyone. A lot of people also dislike Lisp style syntax, myself included. >Racket Same issues as Scheme. >F# F# is a fantastic language. There's not really a whole heck of a lot to complain about other than the .NET implications. The only detriment relative to Python is F#'s much smaller ecosystem and community. >C# Once again, some people just don't like .NET stuff. A lot of people also see static typing to be a detriment in many use cases. Relative to Python, these languages also share several other problems when it comes to real world application: lack of competent developers, stagnating ecosystems, lack of third party libraries, ecosystem lock in, and cross-platform comparability issues. In the case of languages like Haskell, they could even be considered "esoteric". I'll give you that many of these languages are more "pure" or "logical" than Python. I'll even give you that most of them are designed much better than Python. None of that changes the fact that Python is overall easier to read, easier to learn, easier to write, has a better ecosystem, is platform and file system agnostic, has a very non-restrictive license, and is, overall, very pleasant to work with.
      - statsmatscats 10y ago
        Actually, they said they would keep programming in python.
- mathw 10y ago
  Well... yes. That's basically my point. Comparing speed to node.js is pretty much useless because if you really care about speed you're not using node in the first place.

Mmm, "faster than node.js" isn't a great benchmark out in the wide world. Although node.js being as fast as it is remains an astonishing thing.

by mathw 10y ago

Mmm, "faster than node.js" isn't a great benchmark out in the wide world. Although node.js being as fast as it is remains an astonishing thing.

quotemstr 10y ago

Who cares about the speed of the interpreter? The interpreter's job is to orchestrate high-performance components written in some high-performance language. If your interpreter is dominating execution time, you should move some of your logic to native code.

pjmlp 10y ago
Better not use an interpreter in first place, rather a language with REPL that allows compilation straight to native code.
- quotemstr 10y ago
  Why? Native code is costly: machine code generally has a much bigger footprint than interpreter bytecode. In some cases, interpreted code can be faster due to cache effects and reduced IO load making it faster to be smaller.
  - pjmlp 10y ago
    I am yet to see such benefits in action. The fact that Google has started this project to migrate away from Python to an AOT compiled language, shows where the performance wins are.
    - scriptkiddy 10y ago
      >I am yet to see such benefits in action. Here you go: https://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-again-string.html https://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-... https://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-carefully-crafted.html https://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-... For more examples, just search "pypy faster than c". Also, here is an article from the Python wiki about why speed doesn't really matter a lot of the time: https://wiki.python.org/moin/PythonSpeed https://wiki.python.org/moin/PythonSpeed And, my own two cents: Speed is relative. Does every piece of code need to be as performant as possible? No. I would argue that, in most cases, speed of development is far more important than speed of execution. This is, of course, not true for things like drivers or statistical analysis. Writing a web application? Speed isn't that important as the whole process is i/o bound anyways. Writing a machine learning algorithm? Depends. Web scraping? I/O bound, speed not really important. Image processing? Speed matters at least a little bit. Writing networking glue for distributed systems? Speed probably doesn't matter. It's all relative. If it needs to be fast, it needs to be fast. Most things don't really need to be fast. For the things that don't need to be fast, why build them with C/C++/Rust/Go when you could spend half the time building them in Python/Ruby/js/etc?
      - pjmlp 10y ago
        PyPy isn't an interpreter, you are just validating my assertion about JIT/AOT compilers. I usually ignore it when talking about Python, because that is what the community does, by gathering around CPython. > For the things that don't need to be fast, why build them with C/C++/Rust/Go when you could spend half the time building them in Python/Ruby/js/etc? Because one can use languages like OCaml, Haskell, Lisp, Scheme, Racket, F#, C#,... thus having both the productivity of a REPL environment and the execution speed of native code.
        scriptkiddy 10y ago
        >PyPy isn't an interpreter, you are just validating my assertion about JIT/AOT compilers. I thought we were talking about Python implementations exclusively. My mistake. >OCaml I have no experience with OCaml, so I won't make any comments regarding it's efficacy.' >Haskell Well thought out language. I like the purity, but it's too academic for real world use outside of scientific computing. FP isn't for everyone, and my personally belief regarding it is that it is better used as a tool alongside other paradigms than all by itself as the only paradigm. >Lisp Lisp is useful for a lot of things. It's also not very popular for new projects as far as I've seen. There are also a ton of different versions, so I don't know if "Lisp" is really a good descriptor. >Scheme As far as I know Scheme is the defacto teaching language for most compSci programs.Or, at least it was for a long time. Once again, FP is not for everyone. A lot of people also dislike Lisp style syntax, myself included. >Racket Same issues as Scheme. >F# F# is a fantastic language. There's not really a whole heck of a lot to complain about other than the .NET implications. The only detriment relative to Python is F#'s much smaller ecosystem and community. >C# Once again, some people just don't like .NET stuff. A lot of people also see static typing to be a detriment in many use cases. Relative to Python, these languages also share several other problems when it comes to real world application: lack of competent developers, stagnating ecosystems, lack of third party libraries, ecosystem lock in, and cross-platform comparability issues. In the case of languages like Haskell, they could even be considered "esoteric". I'll give you that many of these languages are more "pure" or "logical" than Python. I'll even give you that most of them are designed much better than Python. None of that changes the fact that Python is overall easier to read, easier to learn, easier to write, has a better ecosystem, is platform and file system agnostic, has a very non-restrictive license, and is, overall, very pleasant to work with.
    - statsmatscats 10y ago
      Actually, they said they would keep programming in python.
mathw 10y ago
Well... yes. That's basically my point. Comparing speed to node.js is pretty much useless because if you really care about speed you're not using node in the first place.