Pyston 0.2 Is A Heck Of A Lot Better At Running Python Programs

[phoronix]

Phoronix: Pyston 0.2 Is A Heck Of A Lot Better At Running Python Programs

Earlier this year cloud storage provider Dropbox open-sourced their own high-performance Python implementation, Pyston. Pyston is a JIT-based Python implementation built atop the LLVM compiler stack. The initial Pyston release was a bit basic but now after months of work, Dropbox is announcing the second version of Pyston...

http://www.phoronix.com/vr.php?view=MTc4ODQ

[jagoly]

Benchmarks

Any plans to test this out for us? I'd sure be interested in seeing what it was capable of

[Michael]

Any plans to test this out for us? I'd sure be interested in seeing what it was capable of

Only if anyone contributes some interesting Python-based test cases to the PhoronixTestSuite/OpenBenchmarking.org... Right now there's very few Python tests in there.

[coder111]

Programming language performance- Python is slow

Stock Python interpreter is very slow. Jython is slow, PyPy is a bit better. I never tried .NET based IronPython as I'm on Linux. I've seen fist-hand Python performance is ~10x-30x slower than same thing done Java. Debian language shootout reports ~60x slower than C performance.

http://benchmarksgame.alioth.debian.org/

It's a bit curious how nice new "sexy" languages like Python or Ruby perform so bad with stock VMs/interpreters.

I know C, C++, Java and C# are close to top in terms of performance. I was very surprised to see Scala perform that well- I think it's probably the fastest of the "scripting" langages where you don't need to precompile things to run them- only ~3x slower than C. I guess it uses JIT capabilities of Java VM effectively.

Of course standard disclaimers apply- it depends on the implementation of the algorithm, you should not optimize your code until you know where the bottlenecks are, premature optimization is the root of all evil, picking the right algorithm is more important than pure language speed, yada yada. Oh, and I'm not affiliated with Debian language shootout, I just think they did a good enough job at a tricky and controveresial task.

[coder111]

Language performance tests would be nice to have.

I would love to see performance of several different languages doing several different algorithms (integers, strings, floating point, IO, network?) on several different CPUs/Platforms (different ARMs, AMD, Intel, MIPS?) and operating systems (Windows, different versions of Linux, BSD). I wish I had time to help add that to your test suite, but I don't...

Only if anyone contributes some interesting Python-based test cases to the PhoronixTestSuite/OpenBenchmarking.org... Right now there's very few Python tests in there.

[AnonymousCoward]

Only if anyone contributes some interesting Python-based test cases to the PhoronixTestSuite/OpenBenchmarking.org... Right now there's very few Python tests in there.

A comparison of JITed language implementations would be awesome.

[nanonyme]

Stock Python interpreter is very slow. Jython is slow, PyPy is a bit better. I never tried .NET based IronPython as I'm on Linux. I've seen fist-hand Python performance is ~10x-30x slower than same thing done Java. Debian language shootout reports ~60x slower than C performance.

http://benchmarksgame.alioth.debian.org/

I know C, C++, Java and C# are close to top in terms of performance. I was very surprised to see Scala perform that well- I think it's probably the fastest of the "scripting" langages where you don't need to precompile things to run them- only ~3x slower than C. I guess it uses JIT capabilities of Java VM effectively.
.

Reference implementations aren't often the most awesome ones. That's essentially what CPython is, a reference implementation. PyPy implements Python as well but I many ways better

[snadrus]

Events vs language.

As for language speed:
Managing asynchronous processing is far more important for most workloads that wait on network, pipe, or disk.

Asynchronous-first languages like Javscript or Google Go have the benefit of a majority of libraries being asynchronous-safe, while languages where this is tacked-on (C#, C++, etc) have the additional risk of library review to determine if it is as asynchronous as your code.