[Tutor] BLAS Implementation on Python

Knacktus knacktus at googlemail.com
Tue Mar 8 05:52:51 CET 2011

Am 07.03.2011 22:44, schrieb Steven D'Aprano:
> On Tue, 8 Mar 2011 12:28:56 am Knacktus wrote:
>> Am 07.03.2011 01:50, schrieb Mahesh Narayanamurthi:
>>> Hello,
>>> I am thinking of implementing a BLAS package in pure python. I am
>>> wondering if this is a good idea.
> Sure, why not? Even if nobody uses it, it looks good on a resume and you
> will hopefully learn a lot.
>> I don't think so. Usually people write extensions to the CPython
>> implementation (when talking about performance, we need to talk about
>> Python implementations like CPython, Jython or PyPy) in C to do high
>> performance stuff. Pure CPython is (depeneding on the problem)
>> magnitudes slower than C.
> Typical pure Python code is between 10 and 100 times slower than C, but
> talking about implementations, it is the aim of the PyPy project to use
> Just In Time compilation and clever optimizations to meet *and exceed*
> the speed of static C compilers. In just a few years, with a handful of
> people working on it, and a tiny grant from the EU, they have already
> doubled the speed of CPython. If PyPy could get *half* the love and
> attention that CPython gets, who knows what they could accomplish?
> (If only Google had thrown some work into PyPy, instead of wasting time
> with Unladen Swallow that never went anywhere useful...)
> But the beauty of Python is that if a piece of code is too slow, you can
> rip it out into an extension written in C or Fortran while keeping the
> rest of the library in Python. See, for example, the re module, which
> has a front end written in Python and the regex engine in C.
> The itertools module is another good example. Using a few primitives
> written in C, itertools allows Python code to run efficiently and
> quickly.
>> Also, there's NumPy SciPy. Check those out.
>> More comments below ...
>> My design goals are:
>>> [1] Efficient manipulation of Matrices and
>>>       Vectors using pure python objects and
>>>       python code.
>> No, not efficient in terms of performance.
> How do you know how efficient his code will be before he's even written
> it?

He doesn't have to write it, as it is very obvious, that no Python code 
on earth (even written by Guido himself ;-)) stands a chance compared to 
Fortran or C. Look at this:


CPython implementation runs 12 mins compared to 8 secs of a Fortran 
implementation. PyPy is about 100 secs, which is remarkable but still 
far off.

> [...]
>> The future of High Performance Python is probably PyPy.
> Exactly why a pure-Python library *may* be useful. Today it will be
> slow, running under CPython, but in five (unlikely) or ten years
> (possibly), it may be fast, running under PyPy.
> Or not. Who can tell what the future will bring?

More information about the Tutor mailing list