On 12 Nov, 18:32, "Alf P. Steinbach" <al...@start.no> wrote:
> Of course Python is slow: if you want speed, pay for it by complexity. Python is slow is really a misconception. Python is used for scientific computing at HPC centres around the world. NumPy's predecessor numarray was made by NASA for the Hubble space telescope. Python is slow for certain types of tasks, particularly iterative compute-bound work. But who says you have to use Python for this? It can easily be delegated to libraries written in C or Fortran. I can easily demonstrate Python being faster than C. For example, I could compare the speed of appending strings to a list and "".join (strlist) with multiple strcats in C. I can easily demonstrate C being faster than Python as well. To get speed from a high-level language like Python you have to leverage on high-level data types. But then you cannot compare algorithms in C and Python directly. Also consider that most program today are not CPU-bound: They are i/o bound or memory-bound. Using C does not give you faster disk access, faster ethernet connection, or faster RAM... It does not matter that computation is slow if the CPU is starved anyway. We have to consider what actually limits the speed of a program. Most of all I don't care that computation is slow if slow is fast enough. For example, I have a Python script that parses OpenGL headers and writes a declaration file for Cython. It takes a fraction of a second to complete. Should I migrate it to C to make it 20 times faster? Or do you really think I care if it takes 20 ms or just 1 ms to complete? The only harm the extra CPU cycles did was a minor contribution to global warming. -- http://mail.python.org/mailman/listinfo/python-list