3 ms·

Pypy isn't very fast, but i guess that plus calling out to the Fortran numpy libraries should be fine for numerical work, but now you have to worry about a JIT,

Pypy isn't very fast, but i guess that plus calling out to the Fortran numpy libraries should be fine for numerical work, but now you have to worry about a JIT, big library, runtime...etc. With something like Crystal, Nim, or Red you get a single small binary at the end of the day and nothing else. I guess to each his own, but I honestly feel like we've overcomplicated things.

joshuamorton 10y ago
Pypy is as fast as or faster than c/c++ in some applications/benchmarks. And with python (or interpreted langs in general) you gain a repl, a shorter write -> compile -> test loop, and generally speaking a higher rate of development. I'd agree though, I do want some way to deploy a "python binary" that isn't essentially a virtualenv.
- throwaway7645 10y ago
  Oh yea I know all about the power of a REPL. My friends with their massively bloated IDEs can't understand my desire for a simple read-eval-print-loop. I gain simplicity and instant satisfaction. Some languages like F# heavily promote both. I didn't think PyPy could be that fast. How on earth could it ever compete with C?
  - joshuamorton 10y ago
    Jits are magic man. Like I said, it depends on the application. For numerical-heavy code, where you're going to be using numpy hooking into MPI or LAPACK, C or similar code will win, it takes more advantage of things. For more complex code, say a webserver, pypy can compete and win, because pypy gets the advantage of, after the jit warms up, essentially profile guided optimization, which means that pypy can, assuming there's some kind of loop (there always is), optimize the hot code paths, and the surrounding code to abuse hot code paths, and it can optimize the hot code paths really really well, better than gcc could normally, because it has additional information (pypy knows how the code is being used at runtime, whereas gcc only knows what information is available to the compiler: types and directives really).

joshuamorton 10y ago

Pypy is as fast as or faster than c/c++ in some applications/benchmarks. And with python (or interpreted langs in general) you gain a repl, a shorter write -> compile -> test loop, and generally speaking a higher rate of development. I'd agree though, I do want some way to deploy a "python binary" that isn't essentially a virtualenv.

throwaway7645 10y ago
Oh yea I know all about the power of a REPL. My friends with their massively bloated IDEs can't understand my desire for a simple read-eval-print-loop. I gain simplicity and instant satisfaction. Some languages like F# heavily promote both. I didn't think PyPy could be that fast. How on earth could it ever compete with C?
- joshuamorton 10y ago
  Jits are magic man. Like I said, it depends on the application. For numerical-heavy code, where you're going to be using numpy hooking into MPI or LAPACK, C or similar code will win, it takes more advantage of things. For more complex code, say a webserver, pypy can compete and win, because pypy gets the advantage of, after the jit warms up, essentially profile guided optimization, which means that pypy can, assuming there's some kind of loop (there always is), optimize the hot code paths, and the surrounding code to abuse hot code paths, and it can optimize the hot code paths really really well, better than gcc could normally, because it has additional information (pypy knows how the code is being used at runtime, whereas gcc only knows what information is available to the compiler: types and directives really).