[pypy-svn] extradoc extradoc: review the blog post

[antocuni]

Author: Antonio Cuni <anto.cuni at gmail.com>
Branch: extradoc
Changeset: r3566:a12bfab04d7f
Date: 2011-05-05 17:32 +0200
http://bitbucket.org/pypy/extradoc/changeset/a12bfab04d7f/

Log:	review the blog post

diff --git a/blog/draft/numpy_followup.rst b/blog/draft/numpy_followup.rst
--- a/blog/draft/numpy_followup.rst
+++ b/blog/draft/numpy_followup.rst
@@ -1,23 +1,28 @@
 NumPy Follow Up
 ===============
 
-Hi everyone.  Since yesterday's blow post we got a ton of feedback, so I want
+Hi everyone.  Since yesterday's blow post we got a ton of feedback, so we want
 to clarify a few things, as well as share some of the progress we've made, in
 only the 24 hours since the post.
 
 Reusing the original NumPy
 --------------------------
 
-First, a lot of people seem to think we should be reusing the original NumPy, via CPyExt (our CPython C-API compatibility layer). This isn't feasible for a few reasons:
+First, a lot of people asked why we cannot just reuse the original NumPy
+through ``cpyext``, our CPython C-API compatibility layer).  We believe this
+is not the best approach, for a few reasons:
 
- 1) CPyExt is slow, and always will be slow. It has to emulate far too many
-    details of the CPython object model that don't exist on PyPy. Since people
-    using NumPy primarily for speed this would mean we could have a working
-    NumPy, but no one would want to use it.
+ 1) ``cpyext`` is slow, and always will be slow. It has to emulate far too many
+    details of the CPython object model that don't exist on PyPy (e.g., reference counting). Since people
+    are using NumPy primarily for speed this would mean that even if we could have a working
+    NumPy, no one would want to use it.  Also, as soon as the execution crosses the ``cpyext`` 
+    boundary, it becomes invisible to the JIT.
+
  2) NumPy uses many obscure documented and undocumented details of the CPython
     C-API. Emulating these is often difficult or impossible (e.g. we can't fix
     accessing a struct field, as there's no function call for us to intercept).
- 3) It's not much fun.  Frankly, working on CPyExt, debugging the crashes, and
+
+ 3) It's not much fun.  Frankly, working on ``cpyext``, debugging the crashes, and
     everything else that goes with it is not terribly fun, especially when you
     know that the end result will be slow. We've demonstrated we can build a
     much faster NumPy, in a way that's more fun, and given the people working
@@ -29,23 +34,35 @@
 There are two issues on C code, one has a very nice story, and the other not so
 much. First is the case of arbitrary C-code that isn't Python related, things
 like `libsqlite`, `libbz2`, or any random C shared library on your system. PyPy
-will quite happily call into these, and once we merge the `jittypes2` branch
-it'll even be smoking fast. The right way to do this binding is using the
-`ctypes` library, which every implementation of Python supports. On the other
+will quite happily call into these, and bindings can be developed either at the 
+RPython level (using ``rffi``) or in pure Python, using `ctypes`.  Writing bindings
+with `ctypes` has the advantage that they can run on every alternative Python
+implementation, such as Jython and IronPython.  Moreover, once we merge the `jittypes2` branch
+`ctypes` call will even be smoking fast. 
+
+On the other
 hand there is the CPython C-extension API. This is a very specific API which
 CPython exposes, and PyPy tries to emulate. It will never be fast, because
-there is far too much overhead in all the emulation that needs to be done. The
-correct solution for C-extensions is: if they are written for speed, rewrite
-them in pure-Python, it's our goal to obliterate the need for C for speed, as
-much as possible, if PyPy alone isn't fast enough then it might make sense to
+there is far too much overhead in all the emulation that needs to be done.
+
+One of the reasons people write C extension is speed.  Often, with PyPy you
+can just forget about C, write everything in pure python and let the JIT to do
+its magic.
+
+In case the PyPy JIT alone isn't fast enough then it might make sense to
 split your C-extension into 2 parts, one which doesn't touch the CPython C-API
 and thus can be loaded with `ctypes` and called from PyPy, and another which
-does the interfacing with Python for CPython (where it will be faster). There
+does the interfacing with Python for CPython (where it will be faster).
+
+There
 are also libraries written in C to interface with existing C codebases, but for
 whom performance is not the largest goal, for these the right solution is to
 try using CPyExt, and if it works that's great, but if it fails the solution
 will be to rewrite using `ctypes`, where it will work on all Python VMs, not
-just CPython. And finally there are rare cases where rewriting in RPython makes
+just CPython. 
+
+
+And finally there are rare cases where rewriting in RPython makes
 more sense, NumPy is one of the few examples of these because we need to be
 able to give the JIT hints on how to appropriately vectorize all of the
 operations on an array.
@@ -53,10 +70,9 @@
 Progress
 --------
 
-On a more positive note, since we wrote the last post we've had several new
-contributors, and I'd like to share some of the improvements that have been
-made to NumPy by them, I've only included patches from people totally new to
-PyPy:
+On a more positive note, after we published the `last post`_, several new people
+came and contributed improvements to the numpy-exp branch.
+We would like to thank all of them:
 
  * nightless_night contributed: An implementation of `__len__`, fixed bounds
    checks on `__getitem__` and `__setitem__`.
@@ -72,4 +88,4 @@
 `pypy-dev <http://codespeak.net/mailman/listinfo/pypy-dev>`_ mailing list, or
 send us pull requests on `bitbucket <https://bitbucket.org/pypy/pypy>`_.
 
-Alex
\ No newline at end of file
+Alex