Google V8 is certainly a brilliant piece of engineering, but by no means Method JIT ( V8 is based on ) has won or the best. Because the King, LuaJIT is based on Tracing JIT.
I have to wonder why Python as a communities have always have the interested to substantially speed up Python. While the Ruby Camp has always been about if you want more speed, do it in C. ( Best Tools for the Job manta? ) Although I hope Ruby MRI will one day get its own Google V8 / LuaJIT treatment.
"Write it in C if you need speed" is a mainstream, orthodox view in the Python community. Pypy is largely the result of hard work from a small number of people (same goes for Jython and IronPython).
Writing C extensions is a great optimization, but it is often a pain to have that platform specific code ported to another platforma (Windows/Linux/x86/x64..)
However, speeding up Python itself might lessen the need for 'monolithic' and platform specific extensions... Which is a very good thing.
Both V8 and LuaJIT are extremely impressive but I'm not sure either dominates the other, at least when I last benchmarked things <http://tratt.net/laurie/research/pubs/files/metatracing_vms/... (the benchmark suite is on github, so you can update/rerun). To cut a long story short, each has some benchmarks where it blows the other out of the water, but overall I'd say that, from a performance perspective, it seems to be a score draw.
I have to wonder why Python as a communities have always have the interested to substantially speed up Python. While the Ruby Camp has always been about if you want more speed, do it in C.
Not sure I agree with that - a big part of the excitement about 1.9 was how much faster it was, and stock Python isn't significantly faster than YARV. Didn't Python 3 actually come with a modest reduction in performance when it was released?
PyPy's certainly ahead quite a bit, but it still seems rather ignored by most.
I hope Ruby MRI will one day get its own Google V8 / LuaJIT treatment.
Rubinius is a JITing LLVM-based Ruby VM with accurate compacting generational GC and no global interpreter lock. And of course there's the similarly capable JRuby, which leverages the JVM JIT quite heavily.
The funny thing is that any module that needs to be "fast" is written in C, and uses cpython's C-python interface. So a JIT for python can only act on half the code, and not the part that might need to be really fast.
Hence PyPy people rewriting CPython's C extensions in Python to make them fast. For example, rewriting JSON encoding from C to Python resulted in a decent speedup.
To paint broad strokes, I think it's more accurate to say that the Ruby maintainers have generally prioritized user experience (where the user here is the programmer) over performance. I think the Python maintainers have maybe prioritized performance a bit higher than their Ruby counterparts, but there's definitely still a higher emphasis on ease of use. Given the goals of both languages and the need to make pragmatic choices, I think their priorities are well set. That said, I think a Java-fast Python or Ruby is an incredibly laudable goal, and I'm happy every time I see people working on it.
To use some other broad strokes.. Are there actually any large performance sensitive ruby projects? Python has quite a following in scientific computing and there are some people trying to do some large performance matters projects in python.
I can also tell you that the idea of simply using c for the slow parts is good but it's not too difficult to build a largish project in a dynamic language where that's very difficult. A high speed kernel with slow control plane can still be slow.
Pyston seems like it has some interesting goals and it might achieve them. There are some substantial ones they haven't addressed yet, cough Gil cough. If they are good, it'll just be a faster python, whereas pypy is very good and if the community embraces what they are doing, it's a new kid of thing.
Cython, Psycho, others that I'm forgetting, the "rewritten in C for speed" libraries in the std lib, the huge number of c-ext libs. Are all examples disproving your assumption that Python community doesn't champion "do it in c, for speed".
I know of just three Python (re)implementations attempted at least in part for speed, one abandoned (unladen swallow), one just starting(OP one), and one fairly far along but not yet complete (Pypy). All are niche and relatively small efforts compared to rest of Python communities "do it in C".
Because people good at writing Python/Ruby/whatever dynamic language might not be the best suited for writing C code (or because seen from a Python programmer's point of view, C definitely sucks).
Comments
Google V8 is certainly a brilliant piece of engineering, but by no means Method JIT ( V8 is based on ) has won or the best. Because the King, LuaJIT is based on Tracing JIT.
I have to wonder why Python as a communities have always have the interested to substantially speed up Python. While the Ruby Camp has always been about if you want more speed, do it in C. ( Best Tools for the Job manta? ) Although I hope Ruby MRI will one day get its own Google V8 / LuaJIT treatment.
"Write it in C if you need speed" is a mainstream, orthodox view in the Python community. Pypy is largely the result of hard work from a small number of people (same goes for Jython and IronPython).
Writing C extensions is a great optimization, but it is often a pain to have that platform specific code ported to another platforma (Windows/Linux/x86/x64..) However, speeding up Python itself might lessen the need for 'monolithic' and platform specific extensions... Which is a very good thing.
Both V8 and LuaJIT are extremely impressive but I'm not sure either dominates the other, at least when I last benchmarked things <http://tratt.net/laurie/research/pubs/files/metatracing_vms/... (the benchmark suite is on github, so you can update/rerun). To cut a long story short, each has some benchmarks where it blows the other out of the water, but overall I'd say that, from a performance perspective, it seems to be a score draw.
Not sure I agree with that - a big part of the excitement about 1.9 was how much faster it was, and stock Python isn't significantly faster than YARV. Didn't Python 3 actually come with a modest reduction in performance when it was released?
PyPy's certainly ahead quite a bit, but it still seems rather ignored by most.
Rubinius is a JITing LLVM-based Ruby VM with accurate compacting generational GC and no global interpreter lock. And of course there's the similarly capable JRuby, which leverages the JVM JIT quite heavily.
The funny thing is that any module that needs to be "fast" is written in C, and uses cpython's C-python interface. So a JIT for python can only act on half the code, and not the part that might need to be really fast.
Hence PyPy people rewriting CPython's C extensions in Python to make them fast. For example, rewriting JSON encoding from C to Python resulted in a decent speedup.
http://morepypy.blogspot.com/2011/10/speeding-up-json-encodi...
To paint broad strokes, I think it's more accurate to say that the Ruby maintainers have generally prioritized user experience (where the user here is the programmer) over performance. I think the Python maintainers have maybe prioritized performance a bit higher than their Ruby counterparts, but there's definitely still a higher emphasis on ease of use. Given the goals of both languages and the need to make pragmatic choices, I think their priorities are well set. That said, I think a Java-fast Python or Ruby is an incredibly laudable goal, and I'm happy every time I see people working on it.
To use some other broad strokes.. Are there actually any large performance sensitive ruby projects? Python has quite a following in scientific computing and there are some people trying to do some large performance matters projects in python.
I can also tell you that the idea of simply using c for the slow parts is good but it's not too difficult to build a largish project in a dynamic language where that's very difficult. A high speed kernel with slow control plane can still be slow.
Pyston seems like it has some interesting goals and it might achieve them. There are some substantial ones they haven't addressed yet, cough Gil cough. If they are good, it'll just be a faster python, whereas pypy is very good and if the community embraces what they are doing, it's a new kid of thing.
Cython, Psycho, others that I'm forgetting, the "rewritten in C for speed" libraries in the std lib, the huge number of c-ext libs. Are all examples disproving your assumption that Python community doesn't champion "do it in c, for speed".
I know of just three Python (re)implementations attempted at least in part for speed, one abandoned (unladen swallow), one just starting(OP one), and one fairly far along but not yet complete (Pypy). All are niche and relatively small efforts compared to rest of Python communities "do it in C".
Because people good at writing Python/Ruby/whatever dynamic language might not be the best suited for writing C code (or because seen from a Python programmer's point of view, C definitely sucks).
The faster the language, the more often you can afford to use it, the more you get to use it.
Projects like pypy lets me code thing in Python I would otherwise have had to do in C. How is that not an awesome thing?