Live data from Hacker News

PyPy 2.0 Released

morepypy.blogspot.com

61–70 of 77 posts

Re: PyPy 2.0 Released

#61
post #57
post #49

Earlier quoted context omitted.

The benchmarks are a little bit misleading for some types of code. They do not measure single run code well. In these cases pypy doesn't do as well as when the JIT has warmed up. The interpreter is slower than the CPython one. For code which doesn't JIT well, it will go slower with pypy. The firefox JS engine now has a fast interpreter, a quick JIT, and a more optimizing one. This means the baseline performance is be…

"The firefox JS engine now has a fast interpreter, a quick JIT, and a more optimizing one. This means the baseline performance is better in CPython" Huh?

From what I understand, there are three stages:

- interpreted

- If run 'enough' times, the code is JIT compiled (fast compilation)

- If run 'enough' times again, it is JIT compiled with the most optimizing compiler (slow compilation)

Re: PyPy 2.0 Released

#62
post #46

Whilst I applaud the efforts of PyPy, I've always been disappointed with the performance benefit it's given me with real world code. Specifically: * PyPy Dict performance is very slow (slower than Cpython). A lot of the code I need to write that is cpu-intensive python code processes data (from stuff like logs) into various data structures that use dicts. Pypy is rarely more than 10% faster and sometimes slower. * Th…

I have at least a 10 fold increase. In my project I have many lists of integer tuples and I need to do a lot of comparison/arithmetic on that.

Re: PyPy 2.0 Released

#63
post #46

Whilst I applaud the efforts of PyPy, I've always been disappointed with the performance benefit it's given me with real world code. Specifically: * PyPy Dict performance is very slow (slower than Cpython). A lot of the code I need to write that is cpu-intensive python code processes data (from stuff like logs) into various data structures that use dicts. Pypy is rarely more than 10% faster and sometimes slower. * Th…

I've had exactly the same problem. I have had tree-manipluation AI problems which run for > 30 minutes (seems like an ideal thing for pypy, before I rewrite them in C++). pypy is almost always slower, and never more than about 15% faster, whereas a simple line-by-line C++ rewrite can be 20x faster.

Python is a vast language. It's very hard to know upfront what sort of patterns people use - if you don't talk to us, don't post stuff on the bug tracker, don't do anything - it's your own fault. PyPy is known to speed up real world code to various degrees - sometimes 10x sometimes not at all, but it all really depends. We would be happy to help you with your problem, but if the only thing you do is to complain on hackernews, well, too bad, we can't help you.

Re: PyPy 2.0 Released

#64
post #48
post #35

Earlier quoted context omitted.

Exactly. Perl regexes have _poor_ performance in terms of running time, but good usability, including by squeezing non-regular features into their allegedly-regular expressions, and also things like numerous and flexible character classes, consistent behaviour for escapes, etc. I love vim, but jesus I can never remember which vim regex metacharacters need escaping to get their meta-meaning, and which need escaping to…

\v is your friend. http://vimdoc.sourceforge.net/htmldoc/pattern.html#/magic

I sort of prefer \V, but same difference

I dunno, I haven't used it in the past, because...

1) "It is recommended to always keep the 'magic' option at the default setting, which is 'magic'. This avoids portability problems."

2) Nor do I want to type two extra characters in every damn regex!

So, it only occurs to me right now, the right thing to do for me is this: the first instant I'm confused about whether \( means grouping or literal paren, I should immediately start my pattern with \v or \V. No unportability of plugins, no marginal cost on regexes that don't care, marginal benefit when it does matter.

Re: PyPy 2.0 Released

#67
post #3

Can someone knowledgeable compare PyPy, Numba and Cython? I mostly use Cython. Tried Numba also, it has very nice workflow when it works with autojit (when it doesn't error messages are pretty cryptic). With PyPy I don't understand why for example all that type information obtained from jit wouldn't be used to make something like Numba specialized functions or Cython modules (noob question but please answer).

Have you tried the cffi? I used to use cython, but since I found the cffi, I haven't looked back.

There are a lot of cffi c bindings. I used with success:

* https://github.com/amauryfa/lxml/tree/lxml-cffi

* https://github.com/chtd/psycopg2cffi

Re: PyPy 2.0 Released

#68
post #11
post #3

Can someone knowledgeable compare PyPy, Numba and Cython? I mostly use Cython. Tried Numba also, it has very nice workflow when it works with autojit (when it doesn't error messages are pretty cryptic). With PyPy I don't understand why for example all that type information obtained from jit wouldn't be used to make something like Numba specialized functions or Cython modules (noob question but please answer).

PyPy still doesn't work with Numpy, though they're working on it.

PyPy has it's own implementation of Numpy (called numpypy). It's not 100% complete but quiet functional.

http://morepypy.blogspot.com/search?q=numpypy

Re: PyPy 2.0 Released

#69
post #46

Whilst I applaud the efforts of PyPy, I've always been disappointed with the performance benefit it's given me with real world code. Specifically: * PyPy Dict performance is very slow (slower than Cpython). A lot of the code I need to write that is cpu-intensive python code processes data (from stuff like logs) into various data structures that use dicts. Pypy is rarely more than 10% faster and sometimes slower. * Th…

I've used PyPy in production with success. The task involved implementing a worker which needs to process Wikipedia data.

http://rz.scale-it.pl/2013/02/18/wikipedia_processing._PyPy_...

Also I'm using it with my web applications.

Re: PyPy 2.0 Released

#70
post #57

Earlier quoted context omitted.

"The firefox JS engine now has a fast interpreter, a quick JIT, and a more optimizing one. This means the baseline performance is better in CPython" Huh?

From what I understand, there are three stages: - interpreted - If run 'enough' times, the code is JIT compiled (fast compilation) - If run 'enough' times again, it is JIT compiled with the most optimizing compiler (slow compilation)

The question is what the firefox JS interpreter has to do with baseline performance in CPython.
Post reply on HN