[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [creduce-dev] [RFC] Switching from Perl to Python

Hi Moritz, this is cool. I've thought about the Perl vs Python issue a number of times and basically I just do not love Python no matter how many times I start writing it. On the other hand I can probably get over this.

My guess is that the speedup you're seeing is mostly due to running fewer passes, since in general CPython is pretty suckily slow compared to Perl. Probably not a big issue for C-Reduce, however, which is almost always bottlenecked by interestingness tests.

I do feel strongly that the abstraction boundary between the core and the passes and the interestingness tests should be a strong one, probably a process by default.

Anyway I need to think about it more and no doubt the other C-Reduce people will have opinions. I'm open to moving to a different implementation of the C-Reduce core, but not until the replacement is feature complete (and I'm probably not going to have a lot of time to work on it myself, but I'm happy to do code reviews).

Keep in mind that the C-Reduce passes are not all equally useful and some merging and removing of functionality can probably be done without hurting the end results.


On 5/26/16 9:36 PM, Moritz Pflanzer wrote:
Hi all,

I am wondering if there might be interest in rewriting the C-Reduce core algorithm and the reduction passes in Python. Potential benefits could be:

- I suspect more people are familiar with Python than with Perl
- Python offers a lager set of features without the need to install additional modules (see below)
- The implementation seems to be a bit simpler and cross-platform compatibility seems to be easier (see below)
- Python is more actively maintained? (Here I am just guessing based on recent popularity)
- A Python based implementation could lead to smaller run-times (see below)

Feel free to add other points or to discuss about potential cons of switching. So far I could think of:

- Some effort is required to do the rewriting
- You guys might be more familiar with Perl?

To push a little bit more in the direction of switching over I created a first proof of concept Python version and compared (most of) the included test between the existing Perl and my Python version. Because the Python version is not complete yet (see below) I had to disable a few passes to allow a fair comparison. And I ran only tests 0-3 and 6, 7 because 4 and 5 make use of KCC and Frama-C and I did not want to go through to much trouble setting everything up. ;-) (Running them wouldn't have been a problem, though.)

My detailed results can be found here: https://docs.google.com/spreadsheets/d/1FIvuHr29X2T2H2wOrnGCU0BUM3NeQrvJY_GpKMVJRCA/edit?usp=sharing

In short: On Linux my Python version takes only 62% of the time on average, on Windows there is not much of a difference. (This might be because the bottleneck on Windows is the process creation -- as opposed to forking on Linux -- and not the passes themselves.)
On Linux the Perl variant used the original shell test scripts, for the Python variant I converted the tests to equivalent Python function. In both cases each test was run as a separate process, so I guess the comparison is fair.
On Windows, since I could not run the shell scripts, both variants used the same Python scripts.

Some words about the Python version. First, it can be found here: https://github.com/mpflanzer/creduce/blob/python/creduce/creduce.py
- It took me about 10-20 hours to write this version -- hard to say how long exactly since I could always only work for short periods. I would estimate that it is about 70% complete with respect to the Perl version.
- I have written it in Python3 as it offers some convenient features over Python2 and the recommendation is to start new work with Python3 anyway.
- It does not use anything but the modules which come with the default Python installation (both Linux and Windows)
- I think the largest missing piece are the passes that remove matched parentheses, braces etc. Python has no built-in functionality so a small custom parser would have to be written -- should not be to difficult
- I have not yet figured out the best way to represent, load and execute the interestingness tests. Ideally I would like to have a base class from which each custom test could inherit. Each test would then be written in a separate Python script but dynamically imported into the C-Reduce script. Then it could be used as any other class. If that's not really feasible it is however no problem to just run them as independent scripts -- the same way like it is now in the Perl version.

I think that is all I can report for now. Please let me know what you think about the idea or if you need some more information. I might have missed something in this writeup.

Best regards,