[pypy-commit] extradoc extradoc: First pass at a blog post.

[alex_gaynor]

Author: Alex Gaynor <alex.gaynor at gmail.com>
Branch: extradoc
Changeset: r3850:309e625a09c3
Date: 2011-07-30 15:29 -0700
http://bitbucket.org/pypy/extradoc/changeset/309e625a09c3/

Log:	First pass at a blog post.

diff --git a/blog/draft/string-formatting.rst b/blog/draft/string-formatting.rst
new file mode 100644
--- /dev/null
+++ b/blog/draft/string-formatting.rst
@@ -0,0 +1,50 @@
+String formatting with PyPy
+===========================
+
+String formatting is probably something you do just about every day in Python,
+and never think about.  It's so easy, just ``"%d %d" % (i, i)`` and you're
+done.  No thinking about how to size your result buffer, whether your output
+has an appropriae NUL byte at the end, or any other details.  A simple C
+equivilant might be::
+
+    char x[23];
+    sprintf(x, "%d %d", i, i);
+
+Which is fine, except you can't even return ``x`` from this function, a more
+fair comparison might be::
+
+    char *x = calloc(23, sizeof(char));
+    sprintf(x, "%d %d", i, i);
+
+``x`` is slightly overallocated in some situations, but that's fine.
+
+But we're not here to discuss the exact syntax of string formatting, we're here
+to discuss how blazing fast PyPy is at it, with the new ``unroll-if-alt``
+branch.  Given the Python code::
+
+    def main():
+        for i in xrange(10000000):
+            "%d %d" % (i, i)
+
+    main()
+
+and the C code::
+
+    #include <stdio.h>
+    #include <stdlib.h>
+
+
+    int main() {
+        int i = 0;
+        char x[23];
+        for (i = 0; i < 10000000; i++) {
+            sprintf(x, "%d %d", i, i);
+        }
+    }
+
+Ran under PyPy, at the head of the ``unroll-if-alt`` branch, and compiled with
+GCC 4.5.2 at -O4 (other optimization levels were tested, this produced the best
+performance). It took .85 seconds to execute under PyPy, and 1.63 seconds with
+the compiled binary. We think this demonstrates the incredible potential of
+dynamic compilation, GCC is unable to inline or unroll the ``sprintf`` call,
+because it sits inside of libc.
\ No newline at end of file