5 ms·

The work sounds very cool (and they are hiring), but (only) a factor of 4 speedup over Python is (to repeat a phrase from elsewhere today) like boasting that yo

The work sounds very cool (and they are hiring), but (only) a factor of 4 speedup over Python is (to repeat a phrase from elsewhere today) like boasting that you're the tallest midget ;o)

jamwt 16y ago
Hi, article author here. It's important to note that this particular job is largely bound on a.) I/O and b.) format serialization tasks. Both Python's BSON and JSON libraries are mature and have their critical sections written in C, so a speedup of 4x is still noteworthy. The Haskell version, on the other hand, is pure Haskell.
- andrewcooke 16y ago
  Neat - thanks.
- deleted 16y ago
  [deleted]
jbellis 16y ago
Agreed. Even where you can optimize the hot code in C, Python is no speed demon. Cassandra's java stress test can push out about 10x as many ops/s as the python one, even though Thrift C extension for Python is quite good. /still a Python fan
- jamwt 16y ago
  Yeah, Haskell is roughly as fast as Java. I imagine, with the tuning I allude to in the blog post, we could restore about a 10x improvement, even on a single core. After all, 10x was about what we had with raw Redis ops/s before the serialization libraries got involved. /also still a python fan :-)
  - j_baker 16y ago
    I think it's difficult to compare Java to Haskell. Java is JIT compiled and trades startup time for optimized performance. Haskell is compiled to native code and has a much faster startup time, but the optimizer doesn't have as good information because it runs when the code is compiled rather than at runtime. In general, Java tends to be better for a long-running process while Haskell might be better for a one-off job (not to say that one couldn't do the other without problem though).
    - orblivion 16y ago
      > Haskell is compiled to native code and has a much faster startup time, but the optimizer doesn't have as good information because it runs when the code is compiled rather than at runtime. I'm not that familiar with JIT, but wouldn't compiling everything to native code ahead of time be at least as good as compiling parts that turn out to be slow, just in time? Is it about what sorts of optimizations to use, which you don't know until runtime? Also, would this situation change given the fact that they're switching to LLVM?
      - jasonwatkinspdx 16y ago
        There are many in-lining opportunities that depend on knowing what branches are followed in the program at run time. A JIT has better access to this information, and so can be more aggressive in leveraging it. I'm not familiar with how common these techniques are in production JVM's, but as they're becoming common in javascript implementations I'd assume it's equally common.
      - Tuna-Fish 16y ago
        JIT has strictly more information than an ahead-of-time compiler running without good profiling data (that should be based on the real workload, not a dev test). JITs can notice things like paths never taken and compile the code into a set of sanity checks and a single completely inlined tight codepath for the common case, and when sanity checks fail, fall back to normal code. JIT does, however, use cycles at runtime to do the actual compile. While I have seen benchmarks where JIT wins over AoT, I'd still bet that the balance favors traditional compilers.

The work sounds very cool (and they are hiring), but (only) a factor of 4 speedup over Python is (to repeat a phrase from elsewhere today) like boasting that you're the tallest midget ;o)

jamwt 16y ago

Hi, article author here. It's important to note that this particular job is largely bound on a.) I/O and b.) format serialization tasks. Both Python's BSON and JSON libraries are mature and have their critical sections written in C, so a speedup of 4x is still noteworthy. The Haskell version, on the other hand, is pure Haskell.

andrewcooke 16y ago
Neat - thanks.
deleted 16y ago
[deleted]

jbellis 16y ago

Agreed. Even where you can optimize the hot code in C, Python is no speed demon. Cassandra's java stress test can push out about 10x as many ops/s as the python one, even though Thrift C extension for Python is quite good. /still a Python fan

jamwt 16y ago
Yeah, Haskell is roughly as fast as Java. I imagine, with the tuning I allude to in the blog post, we could restore about a 10x improvement, even on a single core. After all, 10x was about what we had with raw Redis ops/s before the serialization libraries got involved. /also still a python fan :-)
- j_baker 16y ago
  I think it's difficult to compare Java to Haskell. Java is JIT compiled and trades startup time for optimized performance. Haskell is compiled to native code and has a much faster startup time, but the optimizer doesn't have as good information because it runs when the code is compiled rather than at runtime. In general, Java tends to be better for a long-running process while Haskell might be better for a one-off job (not to say that one couldn't do the other without problem though).
  - orblivion 16y ago
    > Haskell is compiled to native code and has a much faster startup time, but the optimizer doesn't have as good information because it runs when the code is compiled rather than at runtime. I'm not that familiar with JIT, but wouldn't compiling everything to native code ahead of time be at least as good as compiling parts that turn out to be slow, just in time? Is it about what sorts of optimizations to use, which you don't know until runtime? Also, would this situation change given the fact that they're switching to LLVM?
    - jasonwatkinspdx 16y ago
      There are many in-lining opportunities that depend on knowing what branches are followed in the program at run time. A JIT has better access to this information, and so can be more aggressive in leveraging it. I'm not familiar with how common these techniques are in production JVM's, but as they're becoming common in javascript implementations I'd assume it's equally common.
    - Tuna-Fish 16y ago
      JIT has strictly more information than an ahead-of-time compiler running without good profiling data (that should be based on the real workload, not a dev test). JITs can notice things like paths never taken and compile the code into a set of sanity checks and a single completely inlined tight codepath for the common case, and when sanity checks fail, fall back to normal code. JIT does, however, use cycles at runtime to do the actual compile. While I have seen benchmarks where JIT wins over AoT, I'd still bet that the balance favors traditional compilers.