[pypy-dev] [PATCH] Improving readability of generated .c code
David Malcolm
dmalcolm at redhat.com
Tue Dec 21 19:54:36 CET 2010
On Tue, 2010-12-14 at 15:14 +0100, Carl Friedrich Bolz wrote:
> Hi David,
>
> On 12/14/2010 01:57 AM, David Malcolm wrote:
Thanks for looking at this; sorry for the belated reply.
I'm attaching the latest work-in-progress version of the patch,
addressing some of the areas discussed.
(snip)
> > Hopefully this makes the generated .c much more readable.
>
> I like the general approach, though I have the vague fear that it will
> make the generated C code much bigger. Could you check that this is not
> the case?
The .c code seems to get roughly 15% bigger (which I don't think is an
issue), but the translation may be getting significantly longer (40%
more time; it's a real pain to benchmark this, though).
I'm also not getting as many comments as I'd like for inlining (see
below), and I expect the code to grow when I fix that.
Method:
Control:
- clean pypy hg checkout of 40149:cd083843b67a
- cd pypy/translator/goal
- python translate.py (i.e. without any flags)
- wait for the build to complete
- locate the generated code in the "testing_1" subdirectory:
- invoke David A. Wheeler's "SLOCCount" tool on the "testing_1" dir
(http://www.dwheeler.com/sloccount/)
- run "du -h" on the "testing_1" dir
Experiment:
- as above, but with the attached changes to the source tree
Actually, the first time I built the clean version, I was hacking on the
debug tree, and lost my copy of the relevant /tmp/usession-N directory,
so I set PYPY_USESSION_DIR=/tmp/clean-build and redid it. (I was also
checking mail, IRC, and other stuff on the machine, but I don't think
this significantly affects the timings).
Size of generated source::
Output of "wc *.c"::
(trimmed to final summary, giving newline, word, and byte counts)
Unpatched::
5166080 15803859 186007458 total
With the patch::
5544105 18458780 213205652 total
Disk usage::
This is:
du -h -c *.c
omitting the individual counts
Unpatched::
178M total
With the patch::
204M total
"sloccount"::
Unpatched::
SLOC Directory SLOC-by-Language (Sorted)
4728922 testing_1 ansic=4728922
With the patch::
SLOC Directory SLOC-by-Language (Sorted)
4730181 testing_1 ansic=4730181
I haven't measured memory usage during conversion.
The above looks fine to me (I'll happily take a 15% increase in on-disk
size of files that are used at runtime only for debugging, in exchange
for easier debugging).
However, conversion time seems to increase roughly 40%.
Unpatched:
[Timer] Timings:
[Timer] annotate --- 1180.5 s
[Timer] rtype_lltype --- 730.7 s
[Timer] backendopt_lltype --- 468.5 s
[Timer] stackcheckinsertion_lltype --- 68.9 s
[Timer] database_c --- 546.4 s
[Timer] source_c --- 1323.5 s
[Timer] compile_c --- 347.4 s
[Timer] ===========================================
[Timer] Total: --- 4665.9 s
Patched:
[Timer] Timings:
[Timer] annotate --- 1428.2 s
[Timer] rtype_lltype --- 913.6 s
[Timer] backendopt_lltype --- 831.9 s
[Timer] stackcheckinsertion_lltype --- 106.6 s
[Timer] database_c --- 991.1 s
[Timer] source_c --- 2385.8 s
[Timer] compile_c --- 400.2 s
[Timer] ===========================================
[Timer] Total: --- 7057.3 s
> > (I hope to
> > work on the names of locals also; ideally they ought to embed the python
> > indentifier)
>
> This should already work in theory, see e.g. "l_cls_0" above, which
> embeds the Python variable name "cls". I guess that the information is
> simply lost in some of the transformation steps. If you feel like
> hunting down where, you can probably get better naming in some cases.
I think I was wrong about this: the variables that are getting
uninformative names are the temporaries; .c locals that "are" RPython
locals are being named informatively.
>
> > This is on a Fedora 13 x86_64 box, with cpython 2.6.5
> >
> > Caveats:
> > - this is my first patch to PyPy (please be gentle!): I hope I've
> > correctly understood the various levels, but I suspect I may still be
> > missing things at the conceptual level
>
> I think you are doing great. You might have to grep around a bit for
> more places that create SpaceOperations, or did you look at all of them?
There are numerous places where ops are created, (in llops.genops iirc),
and somewhere in that process, many of the resulting operations are only
getting a partial "path" of CodeLoc instances (see below). I plan to
look into that next.
> > - haven't completed the full unit tests yet.
>
> This is the biggest problem of the patch, of course. I think that you
> should at least try to write tests for each of the places where you
> propagate the offset down one level. In addition, you probably need an
> integration test where you check the generated C code for the presence
> of the correct comments.
The latest version of the patch adds two integration tests into
pypy/translator/c/test/test_genc.py
I haven't yet added unit tests for the location propagation (see below).
> > - the patch attempts to propagate the "offset" of flowspace
> > SpaceOperation instances in a couple of places where the offset was
> > being discarded:
> > - in BaseInliner.copy_operation
>
> This is wrong. If you inline one function into another, it doesn't make
> sense to put the offset of the inner function into the outer function.
> To solve this problem, you have two options:
> 1) when inlining, set the offset to -1, and just don't get source code
> then
> 2) make every *operation* contain a reference to the func it comes
> from. The memory implications of this should be checked, but are
> probably not too bad.
What I've done is (2): introduce a CodeLoc class representing a (code,
offset) pair, and to replace the "offset" of a flowspace SpaceOperation
with a new OperationLoc class, which consists of a list of 1 or more
CodeLoc instances. In the simple case we have a single CodeLoc, but in
the case of operations within an inlined function we have the CodeLoc of
the callsite, followed by that of the operation within the inlined body.
For the case of nested inlining, I'm assuming we could have an arbitrary
long list of CodeLoc instances describing the OperationLoc.
Having said that, within inlining most operations seem not to get part
of the "path", and I'm using None for these. This is probably the area
most needing further unit tests.
Other changes in the patch:
- I've attempted to reorder blocks within the generated C to reflect
the source-level ordering of operations within the RPython. This breaks
down somewhat in the presence of inlined ops with only partial paths,
but it makes a best attempt.
- I had a go at renaming block labels in the C, so that e.g. a return
block might be "return_block3", and a raise block might be
"raise_block42".
- I'm now cleaning out C-style comments from the .py code when writing
them into comments in the generated C code, to avoid syntax errors
- two new self tests, as mentioned above. I made interactive
Translation.source_c() return the .c filename to help write the tests
(...snip...)
> > - I haven't tried doing this on a full build of the interpreter
> > (having highly readable generated .c for this is my objective [1]).
>
> I fear it will never be "highly readable", but I think your work
> improves things already.
Thanks!
> > One other idea I had was to sort the blocks in the function by the
> > bytecode offset; currently the c blocks seem to "jump around" a fair bit
> > relative to the corresponding rpython code. Has any tuning been done on
> > the ordering of the blocks within the generated .c code? (or is it
> > assumed that the .c compiler will "flatten" these, for the case when a
> > node has a single successor node?)
>
> The C compiler should not care about the order of blocks. If it does, I
> am prepared to call it insane.
As mentioned above, I attempted this.
(..snip...)
> > The C code doesn't look anything like the .py code that my patch is
> > inserting in the above. (My current guess is that I need to be smarter
> > about inlined operations, though that's a guess at this stage)
>
> Sounds like a correct guess, malloc is transformed into something else,
> and the offset of the inlined operations is basically just random, if
> you interpret it in the context of the outer function.
I'd hoped with the OperationLoc/CodeLoc changes to be able to propagate
the full hierarchy of RPython source location at an inlined callsite,
but I'm not getting that yet. I plan to look at that next.
However, the comments do at least now reflect true locations throughout.
One other idea that occurred to me: currently in
pypy/translator/c/genc.py the code spits all of the functions into a
series of numbered implement.c files.
I thought it might be nice to split them up somehow by namespace, so for
example, all "PyUnicode_*" and "pypy_g_PyUnicode_*" functions could end
up in "PyUnicode.c", "PyUnicode_1.c", etc, and implement*.c could then
only contain the ones that don't match such a pattern.
Does this sound reasonable, and any pointers on minimal ways of testing
this? (I'm guessing the unit tests for the C database are the best
guidance here).
Hope this is helpful
Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pypy-add-py-source-as-comments-to-generated-c-2010-12-21-001.patch
Type: text/x-patch
Size: 26643 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20101221/8218cf33/attachment.bin>
More information about the Pypy-dev
mailing list