Live data from Hacker News

PyPy 2.0 Released

morepypy.blogspot.com

21–30 of 77 posts

Re: PyPy 2.0 Released

#21
post #4

Congratulations! Looking forward to the day PyPy becomes the reference implementation.

I hope that that never happens. CPython is still pretty readable, and reference implementations should be simple and easy to learn from. Actually, I'd like it if somebody hacked up a very very simple and naive Python interpreter and nominated that for the reference implementation instead.

Are you saying PyPy is unreadable?

I have not read large amounts of it, but the interpreter is written in RPython. Surely it's easier to read than the CPython source?

Re: PyPy 2.0 Released

#22
post #6

Does anyone have any performance comparisons to Perl? I've used Perl for over a decade. Just started using Python on a project. I've got a lot to learn but Python makes you feel like you've got it down pretty quickly. One of the things that kept me on Perl was its great performance. http://benchmarksgame.alioth.debian.org/u64q/perl.php I'd like to go for the win, win. Is that 'FTWW?'

I haven't seen Perl vs. PyPy stats, but here is some CPython vs. PyPy benchmarks:

http://speed.pypy.org/

Re: PyPy 2.0 Released

#23
post #21

Earlier quoted context omitted.

I hope that that never happens. CPython is still pretty readable, and reference implementations should be simple and easy to learn from. Actually, I'd like it if somebody hacked up a very very simple and naive Python interpreter and nominated that for the reference implementation instead.

Are you saying PyPy is unreadable? I have not read large amounts of it, but the interpreter is written in RPython. Surely it's easier to read than the CPython source?

readability is probably not the right term, but I think he means easy to understand. Doesn't matter how elegant PyPy's code is, it'll surely be more complex than an straight forward interpreter.

Re: PyPy 2.0 Released

#24
post #21

Earlier quoted context omitted.

I hope that that never happens. CPython is still pretty readable, and reference implementations should be simple and easy to learn from. Actually, I'd like it if somebody hacked up a very very simple and naive Python interpreter and nominated that for the reference implementation instead.

Are you saying PyPy is unreadable? I have not read large amounts of it, but the interpreter is written in RPython. Surely it's easier to read than the CPython source?

No, it isn't. PyPy code is very poorly commented and documented, there's a lot going on inside the same codebase. So far, it feels like the only people who hack it are the ones who wrote it. This needs to be sorted out before we see mass adoption.

Re: PyPy 2.0 Released

#26
post #21

Earlier quoted context omitted.

Are you saying PyPy is unreadable? I have not read large amounts of it, but the interpreter is written in RPython. Surely it's easier to read than the CPython source?

readability is probably not the right term, but I think he means easy to understand. Doesn't matter how elegant PyPy's code is, it'll surely be more complex than an straight forward interpreter.

Actually if you read the PyPy interpreter's source, all you'll see is a straightforward interpreter.

Re: PyPy 2.0 Released

#27
post #8
post #5

Earlier quoted context omitted.

Cython is a compiler not an interpreter. Numba requires explicit hinting and can only optimize some undefined (?) subset of Python. PyPy on the other hand is simply a fast Python interpreter. Not sure what you mean regarding the type information gathered by the JIT.

For example does PyPy always warm up, or can it store "warmed up" version of some function (where type of objects is inferred)? I know that this is not in accordance with highly dynamic nature of Python, but not all functions are highly dynamic.

My understanding (from a previous HN discussion about javascript) is that since the output from a "just-in-time compiler" is actually machine code generated on the fly, it includes direct references to memory locations that are only valid for the lifetime of the process. So the output of a JIT is simply not in a format that can be saved and reloaded later.

Re: PyPy 2.0 Released

#28
post #21

Earlier quoted context omitted.

I hope that that never happens. CPython is still pretty readable, and reference implementations should be simple and easy to learn from. Actually, I'd like it if somebody hacked up a very very simple and naive Python interpreter and nominated that for the reference implementation instead.

Are you saying PyPy is unreadable? I have not read large amounts of it, but the interpreter is written in RPython. Surely it's easier to read than the CPython source?

I'm saying that it's big. Specialization requires special cases, which require more lines of code. One should be able to reason about the entirety of a Python implementation, and that's very difficult to do for PyPy.

Re: PyPy 2.0 Released

#29
post #6

Does anyone have any performance comparisons to Perl? I've used Perl for over a decade. Just started using Python on a project. I've got a lot to learn but Python makes you feel like you've got it down pretty quickly. One of the things that kept me on Perl was its great performance. http://benchmarksgame.alioth.debian.org/u64q/perl.php I'd like to go for the win, win. Is that 'FTWW?'

Interesting datum you used. That chart shows that, on those compilers, on those programs, with those test data, Perl and CPython are VERY similar in speed. If you compare your link (Perl / CPython) with the inverse (CPython / Perl), you almost can't tell the graphs apart.

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

So CPython is about the same speed as Perl. PyPy's speed comparison suggests that PyPy is 2-20x faster than CPython. What else do you want to know?

Perl, btw, is not noted for its "great performance" in any context I've ever heard of.

Re: PyPy 2.0 Released

#30
post #29
post #6

Does anyone have any performance comparisons to Perl? I've used Perl for over a decade. Just started using Python on a project. I've got a lot to learn but Python makes you feel like you've got it down pretty quickly. One of the things that kept me on Perl was its great performance. http://benchmarksgame.alioth.debian.org/u64q/perl.php I'd like to go for the win, win. Is that 'FTWW?'

Interesting datum you used. That chart shows that, on those compilers, on those programs, with those test data, Perl and CPython are VERY similar in speed. If you compare your link (Perl / CPython) with the inverse (CPython / Perl), you almost can't tell the graphs apart. http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... So CPython is about the same speed as Perl. PyPy's speed comparison suggests that P…

Perl is famous for it regex performance. For many years people have compared Python, Ruby, and Perl performance and it has usually been Perl as the fastest followed by Python then Ruby. I've seen many posts like this:

http://stackoverflow.com/questions/12793562/text-processing-...

These days, however, it appears that Python has really come into its own. I started using Sublime Text so that got me into trying out Python.

Post reply on HN