[jbellis]

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]

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]

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]

> 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?

[Tuna-Fish]

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.

[j_baker]

Right, but those extra cycles tend to be a one-time thing. In a program that runs in a short amount of time, then the amount of time it takes to compile this might negate any speed gains. In a longer-lived application (like a web app), this can make a bigger difference.

[xtho]

The jit has more information about runtime behaviour. The question is though whether haskell's or similar slightly more advanced type systems aren't able to compensate for that.

[jasonwatkinspdx]

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.

[j_baker]

> Also, would this situation change given the fact that they're switching to LLVM?

LLVM can both use a JIT and compile to native code. From what I've seen, ghc doesn't seem to be doing much different, so I'd assume they're compiling to native code still.

[japherwocky]

This is a pretty awesome example of how to use Python for it's quick development times to get a system in place, then go in later and write those bits with a faster/compiled language when growth overtakes you.