Pyevolve and pypy

[Mark Lefebvre]

I have been unable to duplicate any speed increase when using pypy, in fact, pypy makes things much slower.

I did notice that there were some recent changes to the build for 0.6rc1 to accommodate pypy, but I could not find proper instructions on how to activate pypy speedups.

Does anyone know how to speed up PyEvolve with pypy (or any other method)?

Are there tools that will speed up symbolic regression?

The eval function seems to take up all the time (not surprising) is there a way to make that faster?

Thanks

[Christian S. Perone]

Hello Mark, there are no PyPy Speedups, actually PyPy is expected to speed up things without changing code (this is true for pure Python module like Pyevolve), what I know is that PyPy works very well with the GA engine of Pyevolve, but for the GP it doesn't gives you a great performance boost. I know that someone was working on a new GP engine for Pyevolve (using visitor method of evaluation) that worked very well with PyPy, but I never received the pull request for this code.

--

---
You received this message because you are subscribed to the Google Groups "pyevolve" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyevolve+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Blog | Github | Twitter

"Forgive, O Lord, my little jokes on Thee, and I'll forgive Thy great big joke on me."

[Mark Lefebvre]

Ah, well, that explains why it is quite a bit slower using pypy.

Any suggestions for how to make the eval faster for the Symbolic Regression?

Perhaps some custom eval using LLVM for this specific case?
Any expectation that some other method would improve the speed?

[Mark Lefebvre]

So pypy is slower in DEAP too, however, someone came up with an interesting solution here:

http://multigrad.blogspot.ca/2014/06/fun-with-python-bytecode.html

Since DEAP also has multi-goal algorithms I may try that next.....
Something like a bytecode generation might work for Pyevolve as well, the claim is a 2x increase in speed!

Just in case this information is helpful for anyone else.

[Christian S. Perone]

Actually Pyevolve compiles [1] the expression of the individuals before executing them, so it is already a bytecode before the execution of the individuals per se. I have discussed on Reddit some alternatives to improve the speed, including a project that I started sometime ago, the discussion is here [2] if someone is interested. I also heard that a visitor pattern would also improve the performance on PyPy but I don't really know the internals of PyPy to be sure about that.

[1] https://github.com/perone/Pyevolve/blob/master/pyevolve/GTree.py#L521

[2] http://www.reddit.com/r/Python/comments/2bz01l/executing_x8664_opcodes_in_python_genetic/

[Mark Lefebvre]

Has anyone tested Pyevolve vs. DEAP for the same Symbolic Regression problem?

If not, I'll test this once I convert over. If I can get the DEAP patch to work, I'll test that too and we'll have some data points to compare.

[Mark Lefebvre]

So I did run a quick test, it might be wrong, since DEAP uses a very different programming methodology, but the answers are close enough that I think I have a one for one test.

The results are that DEAP is twice as fast as PyEvolve....disappointing!
I wasn't going strictly for speed, but that is a nice increase in speed...they also have NSGAII, which I wanted to experiment with.

Further, there is a way to use raw x86 bytecode to speed things up (apparently it is twice as fast) but that method is not complete, there are some GREAT blog articles about this here:

http://multigrad.blogspot.ca/2014/06/fun-with-python-bytecode.html

http://multigrad.blogspot.com/2014/07/low-level-frenzy.html

A similar approach would likely benefit PyEvolve as well.
I must say that the documentation and examples for PyEvolve were much more complete and easier to deal with than DEAP.  If the speed were comparable and we had SPEA and NSGAII, I'd likely not bother with DEAP at all.

Hope this is helpful to someone, would look forward to seeing an automated and more complete feature set in PyEvolve along with some of the optimizations (perhaps implemented more fully) in those blog articles.

Thanks

[Christian S. Perone]

Hello Mark, without the code is hard to tell what could be causing the performance difference between the two approaches. Also, since GAs/GPs are non-deterministic, this also can cause a lot of performance differences. Anyway, Pyevolve is always open for contributions, specially regarding NSGA-II.

[Mark Lefebvre]

Christian,

Thanks for the information.  I'm afraid that my math skills end at 'add and subtract', so I won't be able to implement NSGA-II for the project.
Interestingly (and I apologize, I haven't done the test with pyevolve yet) I've found that DEAP is slower when using gmpy2/mpir, I might try this with pyevolve eventually once I fix my testing harnass. I think that having some kind of universal reasonably complex benchmark would be helpful, I propose the reasonably complex http://www.intellovations.com/pyevolve/ (of course, I'm only concerned with symbolic regression as that is what I'm working on).

The areas which I ponder might be improved speed wise (for my project) are some kind of inner loop to speed up when using a time series look back (tapped delay or time delay).  Also, this idea of using actual assembly language trees that require no eval time is interesting (links in my previous post) to me, if it could be more generic, it seems like someone (not me, because I'm sure I don't have the skillset/knowledge) could create a quick python to asm math compiler (be even cooler if it used MPIR library) that could spit out the proper code to use in pyevolve.  Just a thought, big project, I'm sure, but it would make a huge difference to the type of symbolic regression that I'm doing, in terms of speed.

Thank you for the response.  I'll try to work on a clean testing harness to get some better and easier to compare results.

-Mark Lefebvre