Using Python for programming algorithms

[Aahz]

Run time is not important until you are asked to scale to millions
or billions of users or computations or large data sets. I've seen
this first hand. Getting results back the same day or sooner may be
important. In cases such as this, I use C or C++... nothing else will
do. Nothing else is as fast. Although I always keep a py version around
for testing and for smaller tasks. Don't get me wrong, I love Python,
but there are times when nothing, but pure, hard speed will do.

YouTube?

 

[sturlamolden]

seen this first hand. Getting results back the same day or sooner may be
important. In cases such as this, I use C or C++... nothing else will
do. Nothing else is as fast.

Right. Tell that to the Fortran community. And by the way:

http://latticeqcd.blogspot.com/2006/11/why-we-use-fortran-and-python.html

 

[Kay Schluehr]

Maybe this is not the right forum, but maybe you can give me some
hints or tips...

Thank you in advance.

If Python doesn't run in production systems execution speed doesn't
matter much. What actually matters when *developing* non-trivial algos
is to partition the dataflow because it might take just long to reach
a certain execution point that is of current interest - and it has to
be reached repeatedly. For each method call one might want to work
with pre-computed data that were serialized in a former run. Given
Pythons flexibility this shall be easy and so it is! The combination
of object pickling/unpickling and using decorators makes this a snap.
Just look at the following simple decorator:

def dump_data(func):
def call(*args, **kwd):
res = func(*args, **kwd)
fl = open("dump_data.pkl", "w")
pickle.Pickler(fl, 0).dump(args[0])
return res
call.__name__ = func.__name__
call.__doc__ = func.__doc__
return call

and the corresponding loader:

def load_obj():
f = open("dump_data.pkl")
return pickle.Unpickler(f).load()

One might decorate an arbitrary object method foo() with dump_data and
resume the activity of the object after foo has been called in another
run by restoring the object with load_obj.

One can further improve this by serializing the test driver when it is
implemented as a generator. This is non-standard though and requires
some work [1] of my own or Stackless Python [2] alternatively.

What I intended to make clear is that Python has many goodies as a
toolbox besides having lots of bindings and being well readable ( the
usual suspects when it comes to advocation in threads like these ).

[1] http://www.fiber-space.de/generator_tools/doc/generator_tools.html
[2] http://www.stackless.com/

 

[Paddy]

But how about this C/C++ interpreter. Dr. Dobbs article: http://www.ddj.com/cpp/184402054. Title and first two paragraphs:

Ch: A C/C++ Interpreter for Script Computing
Interactive computing in C

Ch is a complete C interpreter that supports all language features and
standard libraries of the ISO C90 Standard, but extends C with many
high-level features such as string type and computational arrays as
first-class objects.

If you still end up chasing pointers to implement your data structures
then its still hampered.

 

[Paddy]

Hello.

I am new to Python. It seems a very interesting language to me. Its
simplicity is very attractive.

However, it is usually said that Python is not a compiled but
interpreted programming language —I mean, it is not like C, in that
sense.

I am working on my PhD Thesis, which is about Operations Research,
heuristic algorithms, etc., and I am considering the possibility of
programming all my algorithms in Python.

The usual alternative is C, but I like Python more.

Using Python doesn't mean you give up on C! Many of the best
algorithms written in other languages such as C, C++ and Fortran are
pre-wrapped in Python or can be wrapped in a Python interface to
enhance usability, without having to pay Matlab-type prices. You then
make your resulting work easier to reproduce by lowering the cost to
other researchers.

Python is a scripting language. Despite what some may think, it is a
boon, as it means that Pythons designers value its ability to work
well with other languages and systems.

Nothing stops you from exploring algorithm space in Python then re-
implementing in a language closer to assembler - and this may well be
the quicker way to your goal.

- Paddy.

 

[Bruno Desthuilliers]

Roel Schroeven a écrit :

Wow this resulted in far more reactions than I had expected ...

(e-mail address removed) schreef:

No, that's not what I said; what I said is that some languages where
designed with in the back of the head the idea that they were going to
be compiled to native code, others to be interpreted, and others to be
compiled to byte code.

I'd put it more simply : some languages were designed with low-level
access and raw performances in mind, and some were'nt. Roel, I'm totally
aware of these issues - on which you're of course right -, but that
doesn't change the fact that a language and it's implementation *are*
distinct things.

(snip)

So yes, the transformation method from source code to something that the
CPU understands depends on your tools.

And you can have different tools using different solutions for a same
language.

But if you want to get work done,
the most common method by far for C is to use a toolchain that compiles
to native code and for Python a byte code compiler + virtual machine.
With possibly a JIT compiler, that's true.


Whenever someone says that Python is interpreted, you respond saying
that that's not true, since it's compiled to byte code.

Whenever someone says that Python is interpreted, I respond saying that
being interpeted or compiled is not a feature of a language, and that
CPython compiles to byte-code.

Correct of
course,

And that's the point : being correct.

but somehow it appears to me that you imply

I don't imply anything - except eventually that the person I'm
correcting should know better.

that that makes
Python closer to a C-like language than to an interpreted language,

Strange enough, no one calls Java or C# 'interpreted languages', while
they (or, to be more exact, their reference implementations) both use
the same byte-code/VM scheme[1]. You know, the commonly accepted
definition of "byte-code" is "something that is going to be passed to a
virtual machine", not "native binary executable code", so I don't think
this could be really misleading.

Now what you don't seem to get is the difference between pure
interpretation - where each and every statement is parsed and
interpreted again and again - and intermediate byte-code compilation.
Believe me, *this* can make a huge difference wrt/ performances.

Also and FWIW, there are quite a lot of "C-like languages" that are - in
their only or reference implementation - interpreted or compiled to
byte-code. For a definition of "C-like" being "close to the C language's
syntax and grammar" !-)

[1] Oh, and before some nut-case jump in : no, this doesn't imply that
the CPython VM is 'equivalent' to Sun's Java VM or MS CLI/.NET VM.

and
that's not correct (IMO). If that's just a misinterpretation by me, I
apologize.


Isn't that more or less the same as what I said?

Can't you tell the difference ???

Maybe I don't make enough distinction between Python the language and
CPython the implementation, but Python development does happen on the
CPython implementation (Python 3.0 alpha releases are CPython releases,
for example).


I find it hard to believe that during the development of C Dennis
Ritchie was considering any other mode of operation than compilation to
assembly or machine code. I might be wrong of course.

I'm not talking about "development" (which implies implementation), but
about the design of the *language*. Roel, can you define "language" ?

I'd like to call that the exception that confirms the rule.

Which rule ?

Oh, and yes - as a couple persons pointed out, there are actually more
than "one (possibly incomplete) C interpreter" - there are also the
llvm byte-code compiler+VM and the MS CLI C/C++ compiler.

There's a very naive belief we saw every here and then here, which is
that "Python would be faster if it was compiled to native code". The
point is that, given Python's (as a language) extrem dynamism,
compiling it to native code wouldn't buy you much in terms of raw
performances. The problem is not with writing a native-code
compiler[1}, but with writing an *optimising* native-code compiler.

I admit I'm guilty of that belief. I know it's true what you say, but I
do have the more-or-less unconscious reflex 'compiled to native code ==
fast'.

So make a simple test : write a very Q&D cat-like program in Python, C
and Perl, and benchmark the three implementations. The results might
surprise you.

So you are saying that CPython is relatively slow because Python is a
highly dynamic language.

And therefore difficult to optimize.

I know that CPython is not Python and Python is
not CPython, but there is a very strong association between the two

Indeed. CPython is the reference implementation of Python. Like GCC is
the reference implementation of C on linux platforms. etc...

and
therefore I think it's not really that much wrong to simplify that to
'Python is slow because it is a highly dynamic language'

It is definitively wrong. How could a *language* be 'slow' or 'fast' ?

(until proven
wrong by PyPy or another fast implementation'.

You know, Common Lisp is also an highly dynamic language, and there are
now some optimizing native-code Common Lisp compilers that generate very
efficient binary code. It only tooks about 30 years and way more
ressources than CPython ever had to get there...

 

[Bruno Desthuilliers]

sturlamolden a écrit :

C has proven very difficult to optimize, particularly because pointer
aliasing prevents efficient register allocation.

Does this compare to optimizing something like Python ? (serious
question, but I think I already know part of the answer).

 

[Frédéric Degraeve]

By the way, is it possible (and easy) to call a C function from a
Python program??

Use SWIG. It's easy, smart and beautiful. After that, you can call C/C+
+ from a lot of scripting languages such as python, R, etc
A lot of open sources projects already use it.

http://www.swig.org/tutorial.html

Boost.Python is also very known (but never tested by myself).

Frédéric

 

[Frédéric Degraeve]

I reply to myself!

Boost.Python is also very known (but never tested by myself).

http://www.boost.org/doc/libs/1_35_0/libs/python/doc/tutorial/doc/html/index..html
here the example. I know that it has been made to simplify the
CPython's use and this is based on CPython.

Frédéric

 

[sturlamolden]

Does this compare to optimizing something like Python ? (serious
question, but I think I already know part of the answer).

In Python different references can alias the same object. But the
objects for which this is important in C, is typically elementary
types like ints and floats. Pointer aliasing has the consequence that
the compiler often cannot choose to keep an int or a float in a
register inside a tight loop. This will often have serious
consequences for numerical computing. But these elementary types are
immutable in Python, so Python is actually somewhat immune to this.
This is one of several reasons why RPython sometimes can be "faster
than C".

But there are other much more important issues if you are to generate
efficient machine code from Python, e.g. getting rid of redundant
attribute lookups.

 

[sturlamolden]

Strange enough, no one calls Java or C# 'interpreted languages', while
they (or, to be more exact, their reference implementations) both use
the same byte-code/VM scheme[1].

Java interprets the bytecode in a virtual machine by default. Only
code 'hotspots' are JIT compiled to native machine code.
Microsoft .NET compiles bytecode to native code on the first
invocation, and caches the machine code for later use. Nothing is
interpreted.

Java can benefit from more runtime information when generating machine
code, but incurs the penalty from running an interpreter most of the
time. MS .NET is more similar to a static compiler. They currently
perform about equally well, sometimes approximating traditional
compiled languages like C++.

But they do not use the same bytecode VM scheme. Particularly,
Microsoft .NET has no virtual machine.

You know, Common Lisp is also an highly dynamic language, and there are
now some optimizing native-code Common Lisp compilers that generate very
efficient binary code. It only tooks about 30 years and way more
ressources than CPython ever had to get there...

The speed of Common Lisp with compilers like SBCL and CMUCL comes from
optional static typing. This no more magical than what Cython and
Pyrex already can do. If we remove the interpreter when Cython or
Pyrex supports all features of the Python language, and instead rely
on "JIT compilation" by one oth these compilers, we are already there.