<br><br><div class="gmail_quote">On Mon, Mar 19, 2012 at 2:32 PM, Maciej Fijalkowski <span dir="ltr">&lt;<a href="mailto:fijall@gmail.com">fijall@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Mon, Mar 19, 2012 at 9:15 PM, Peter Cock &lt;<a href="mailto:p.j.a.cock@googlemail.com">p.j.a.cock@googlemail.com</a>&gt; wrote:<br>
&gt; On Mon, Mar 19, 2012 at 6:36 PM, Maciej Fijalkowski &lt;<a href="mailto:fijall@gmail.com">fijall@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt; <a href="http://mail.python.org/mailman/listinfo/pypy-dev" target="_blank">http://mail.python.org/mailman/listinfo/pypy-dev</a><br>
&gt;&gt;<br>
&gt;&gt; append_charpsize is special - it&#39;s not the *actual* implementation,<br>
&gt;&gt; the actual implementation is buried somewhere in<br>
&gt;&gt; rpython/lltypesystem/rbuilder.py, with the one you&#39;re mentioning being<br>
&gt;&gt; just fake implementation for tests. StringBuilder is special in a<br>
&gt;&gt; sense that it has some special GC support (which we can probably<br>
&gt;&gt; improve upon).<br>
&gt;&gt;<br>
&gt;&gt; Cheers,<br>
&gt;&gt; fijal<br>
&gt;<br>
&gt; I guess you are referring to the copy_string_contents function here:<br>
&gt; <a href="https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/lltypesystem/rstr.py" target="_blank">https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/lltypesystem/rstr.py</a><br>
&gt;<br>
&gt; However, methods ll_append_multiple_char not ll_append_charpsize<br>
&gt; defined in rbuilder seem to use this - they both use a for loop char-by-char,<br>
&gt; <a href="https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/lltypesystem/rbuilder.py" target="_blank">https://bitbucket.org/pypy/pypy/src/default/pypy/rpython/lltypesystem/rbuilder.py</a><br>
&gt;<br>
&gt; My hunch would be to replace this:<br>
&gt;<br>
&gt;    @staticmethod<br>
&gt;    def ll_append_charpsize(ll_builder, charp, size):<br>
&gt;        used = ll_builder.used<br>
&gt;        if used + size &gt; ll_builder.allocated:<br>
&gt;            ll_builder.grow(ll_builder, size)<br>
&gt;        for i in xrange(size):<br>
&gt;            ll_builder.buf.chars[used] = charp[i]<br>
&gt;            used += 1<br>
&gt;        ll_builder.used = used<br>
&gt;<br>
&gt; with this:<br>
&gt;<br>
&gt;    @staticmethod<br>
&gt;    def ll_append_charpsize(ll_builder, charp, size):<br>
&gt;        used = ll_builder.used<br>
&gt;        if used + size &gt; ll_builder.allocated:<br>
&gt;            ll_builder.grow(ll_builder, size)<br>
&gt;        assert size &gt;= 0<br>
&gt;        ll_str.copy_contents(charp, ll_builder.buf, 0, used, size)<br>
&gt;        ll_builder.used += size<br>
&gt;<br>
&gt; (and similarly for ll_append_multiple_char above it)<br>
&gt;<br>
&gt; Like an onion - more and more layers ;) I&#39;m beginning to suspect<br>
&gt; speeding up append_charpsize in order to make passing strings<br>
&gt; to/from C code faster is a bit too ambitious for a first contribution<br>
&gt; to PyPy! [*]<br>
&gt;<br>
&gt; Peter<br>
&gt;<br>
&gt; [*] Especially as after three hours it is still building from source:<br>
&gt; $ python translate.py --opt=jit targetpypystandalone.py<br>
<br>
</div></div>ok, so let me reply a bit more :)<br>
<br>
First of all, you don&#39;t have to translate pypy to see changes. We<br>
mostly run tests to see if they work. You can also write a very small<br>
rpython program in translator/goal (look at targetnopstandalone.py) if<br>
you want to just test the performance of single function.<br>
<br>
I suppose your code is indeed a bit faster, but my bet would be it&#39;s<br>
not too much faster (feel free to prove me wrong, especially on older<br>
GCCs, they might not figure out that a loop is vectorizable for<br>
example).<br>
<br>
The main source of why passing strings to C is slow is however copying<br>
the string from the GC area to non-moving one, raw malloced in C.<br>
There are various strategies how to approach this, one of those would<br>
be pinning, so the GC structures don&#39;t move and you can pass a pointer<br>
to C. This is however definitely not a good  first patch to pypy ;-)<br>
<br>
What I would suggest:<br>
<br>
* Your patch looks good to me, although I&#39;m not sure if<br>
copy-string-contents would accept a raw memory. Check if tests pass.<br>
* If you want to benchmark, write a small test for passing such<br>
strings in translator/goal and see if it works.<br>
<br>
We&#39;re usually available for help on IRC and thanks for tackling this problem!<br>
<br>
Cheers,<br>
fijal<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
pypy-dev mailing list<br>
<a href="mailto:pypy-dev@python.org">pypy-dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/pypy-dev" target="_blank">http://mail.python.org/mailman/listinfo/pypy-dev</a><br>
</div></div></blockquote></div><br>FWIW, copy_string_contents definitely doesn&#39;t take raw memory, it takes an rstr.<div><br></div><div>Alex<br clear="all"><div><br></div>-- <br>&quot;I disapprove of what you say, but I will defend to the death your right to say it.&quot; -- Evelyn Beatrice Hall (summarizing Voltaire)<br>
&quot;The people&#39;s good is the highest law.&quot; -- Cicero<br><br>
</div>