Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PyPy 1.6 Released - Full Python 2.7.1 Implementation

morepypy.blogspot.com

Post reply on HN
Print view View original

21–30 of 57 posts

Re: PyPy 1.6 Released - Full Python 2.7.1 Implementation

#21

Post by irahul »

stephenjudkins wrote: post #18
irahul wrote: post #9

Earlier quoted context omitted.

> but PyPy is one of the few things I envy Python developers for. Depending on your needs, there are others - numpy, scipy, matplotlib, nltk, gevent. > I wish something similar could be developed for Ruby. Isn't http://rubini.us/ supposed to be the PyPy for Ruby? It's not complete, but then neither is PyPy.

Rubinius and PyPy take quite different approaches to solving the same general problem. It's inaccurate to analogize them. Rubinius specifies a bytecode (see http://rubini.us/doc/en/virtual-machine/instructions/ ) and implements a VM that executes this bytecode. The VM is written in C++. The main difference between Rubinius and other Ruby implementations is that nearly everything else is written in Ruby. The lexer, pa…

> Rubinius and PyPy take quite different approaches to solving the same general problem.

> However, it's not breaking new ground like PyPy is.

I know about the differences. My response was to the parent post "if there is something like PyPy for Ruby".

Rubinius doesn't need to break new grounds, nor provide a toolset for implementing interpreters. All it needs to do is to provide a decent JIT with reasonable speed and low memory consumption, with the added benefit of large parts of it in Ruby, so that the contribution ecosystem is more active. That will be pretty much analogous(and all analogies, by definition, are inexact. Or else they won't be called ananlogy) to what PyPy is for Pythonistas.

Re: PyPy 1.6 Released - Full Python 2.7.1 Implementation

#22

Post by Freaky »

kristofferR wrote: post #4

In general I'm very happy with my choice of Ruby/Rails instead of Python/Django, but PyPy is one of the few things I envy Python developers for. I wish something similar could be developed for Ruby.

If it's mainly the performance you're after, have a look at JRuby. It's already a decent chunk faster than MRI/YARV, and with Java 7 and invokedynamic there's a lot more to look forward to and play with now.

Last week one of the JRuby core devs tweeted: "Ok, another set of tweaks in JRuby and fib(35) is another 10% faster (and only about 10% slower than Java. Do I stop now?"

Re: PyPy 1.6 Released - Full Python 2.7.1 Implementation

#23

Post by wynand »

alphakappa wrote: post #10
irahul wrote: post #9

Earlier quoted context omitted.

> but PyPy is one of the few things I envy Python developers for. Depending on your needs, there are others - numpy, scipy, matplotlib, nltk, gevent. > I wish something similar could be developed for Ruby. Isn't http://rubini.us/ supposed to be the PyPy for Ruby? It's not complete, but then neither is PyPy.

matplotlib and numpy make Python really awesome. If only there was a way to get matplotlib to work on Lion.

I'm using the Scipy superpack (http://stronginference.com/scipy-superpack/) on Lion and Matplotlib has given me no trouble so far.

Re: PyPy 1.6 Released - Full Python 2.7.1 Implementation

#24

Post by nickik »

stephenjudkins wrote: post #18
irahul wrote: post #9

Earlier quoted context omitted.

> but PyPy is one of the few things I envy Python developers for. Depending on your needs, there are others - numpy, scipy, matplotlib, nltk, gevent. > I wish something similar could be developed for Ruby. Isn't http://rubini.us/ supposed to be the PyPy for Ruby? It's not complete, but then neither is PyPy.

Rubinius and PyPy take quite different approaches to solving the same general problem. It's inaccurate to analogize them. Rubinius specifies a bytecode (see http://rubini.us/doc/en/virtual-machine/instructions/ ) and implements a VM that executes this bytecode. The VM is written in C++. The main difference between Rubinius and other Ruby implementations is that nearly everything else is written in Ruby. The lexer, pa…

If I would want to speed up ruby I would probebly just implment a ruby interpreter with RPython. They could probebly get up to speed with pypy with much less work. The semantics of the two langauges are not that diffrent.

Re: PyPy 1.6 Released - Full Python 2.7.1 Implementation

#25

Post by lliiffee »

Can I take advantage of this thread to ask the HN crowd a technical question? Some time ago, I implemented an automatic differentiation tool. Using operator overloading on a special "autodouble" type the tool would trace the execution of a block of numerical code. Then, some calculus would automatically happen, and it would output and compile fast c-code that would compute the original function and derivatives in pure c. This was great, except the c-code that was output was freaking gigantic (like hundreds or thousands of megabytes) albeit very simple, and so the c compiler would take forever to run. Sigh.

My question is: could I leverage pypy somehow to avoid this? Can I output RPython? Can I output whatever RPython is compiled down to instead? Can I do this with no more than, say, a 3x penalty compared to c?

(I apologize for asking a question only marginally related to the particular article here...)

Re: PyPy 1.6 Released - Full Python 2.7.1 Implementation

#26

Post by carterschonwald »

lliiffee wrote: post #25

Can I take advantage of this thread to ask the HN crowd a technical question? Some time ago, I implemented an automatic differentiation tool. Using operator overloading on a special "autodouble" type the tool would trace the execution of a block of numerical code. Then, some calculus would automatically happen, and it would output and compile fast c-code that would compute the original function and derivatives in pur…

Off hand and guessing about the problem:

You might want to look at approaches that use dual numbers. Likewise, in instead of inlining the procedures, generate a differentiated version of each procedure with a new name. If those don't cover your problems, perhaps look at how other autodiff tools for C do it?

Re: PyPy 1.6 Released - Full Python 2.7.1 Implementation

#27

Post by [deleted] »

lliiffee wrote: post #25

Can I take advantage of this thread to ask the HN crowd a technical question? Some time ago, I implemented an automatic differentiation tool. Using operator overloading on a special "autodouble" type the tool would trace the execution of a block of numerical code. Then, some calculus would automatically happen, and it would output and compile fast c-code that would compute the original function and derivatives in pur…

[deleted]

Re: PyPy 1.6 Released - Full Python 2.7.1 Implementation

#28

Post by sjs »

lliiffee wrote: post #25

Can I take advantage of this thread to ask the HN crowd a technical question? Some time ago, I implemented an automatic differentiation tool. Using operator overloading on a special "autodouble" type the tool would trace the execution of a block of numerical code. Then, some calculus would automatically happen, and it would output and compile fast c-code that would compute the original function and derivatives in pur…

LLVM? I don't have much experience with runtime code generation but you might find it useful.

Re: PyPy 1.6 Released - Full Python 2.7.1 Implementation

#29

Post by lliiffee »

carterschonwald wrote: post #26
lliiffee wrote: post #25

Can I take advantage of this thread to ask the HN crowd a technical question? Some time ago, I implemented an automatic differentiation tool. Using operator overloading on a special "autodouble" type the tool would trace the execution of a block of numerical code. Then, some calculus would automatically happen, and it would output and compile fast c-code that would compute the original function and derivatives in pur…

Off hand and guessing about the problem: You might want to look at approaches that use dual numbers. Likewise, in instead of inlining the procedures, generate a differentiated version of each procedure with a new name. If those don't cover your problems, perhaps look at how other autodiff tools for C do it?

For being offhand, those are very good guesses! Dual numbers won't be efficient, as I want reverse-mode autodiff.

As to the multiple procedures: Well, as I was doing it, even a single procedure can be many hundreds of megabytes large. Even for very very simple code, however, I noticed that GCC was superlinear in code size. I suppose I could somewhat arbitrarily break up the code into arbitrary functions. I wonder if that would speed things up?

Other autodiff tools: Well, they basically trace execution, but then run an interpreter instead of trying to actual generate compiled code. I wanted to both be faster than that and have the wonderful experience of writing pure python...

Re: PyPy 1.6 Released - Full Python 2.7.1 Implementation

#30

Post by lliiffee »

sjs wrote: post #28
lliiffee wrote: post #25

Can I take advantage of this thread to ask the HN crowd a technical question? Some time ago, I implemented an automatic differentiation tool. Using operator overloading on a special "autodouble" type the tool would trace the execution of a block of numerical code. Then, some calculus would automatically happen, and it would output and compile fast c-code that would compute the original function and derivatives in pur…

LLVM? I don't have much experience with runtime code generation but you might find it useful.

LLVM would seem to (maybe? possibly!?) be a good solution, but I was never able to convincingly determine if it was likely to solve my problems, and the documentation seemed to be quite sparse for doing what I wanted to do. (This was a couple years ago, however, and I've love to be proven wrong.)
Post reply on HN