[Tutor] BLAS Implementation on Python
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:
>>> 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
>> Also, there's NumPy SciPy. Check those out.
>> More comments below ...
>> My design goals are:
>>>  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
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
>> 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