On Mar 26, 7:13 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> Thanks you all for giving a little insight into what Python can > actually do, I think I've read enough to convince me that Python is > generally a very flexible, fast, powerful language that can be used in > a wide variety of applications instead of focusing on numerical > functions like fortran does. I wouldn't go as far as to say Python is a 'fast' language. But it's certainly fun (particularly that), powerful, readable, and useful, even for numerical computing. Speed in numerical computing is a strange beast. First, a small bottleneck in your code is likely to dominate the execution time. But very often it is impossible to guess where it is, common sense usually doesn't help, for some strange reason. You can use the Python profiler to identify the real bottlenecks, but you may be surprised when you find where they are. These bottlenecks are the only portion of the code that can benefit from being moved to Fortran or C. The bottlenecks will dominate regardless of what you do to the rest of you code. You may gain nothing from moving the bottlenecks to C or Fortran. Don't let that surprise you. Python may be doing the work as fast as it can be done. It may actually be the case that moving this code to C or Fortran causes a slowdown. Python may be calling hand tuned C, assembly or Fortran code that you cannot match. You can hand code a sorting routine in C, but will you be able to beat Python's 'timsort'? Probably not! Timsort is one of the fastest and stable sorting routines known to man. It has taken years to develop and fine tune, and you simply cannot beat that, even if you spend hours on end optimizing your code. The same holds for the hashing routines in Pythons dictionaries. You can write a hashtable in C, but I doubt it can match the speed of Python's dictionaries. And then there is files, strings, network sockets and protocols, access to databases, encryption, etc. Python's libraries are tuned by people who knew what they were doing and had the time to do the fiddling. Most likely you don't (well, I certainly do not). Finally, you will most likely use numerical libraries like LAPACK and BLAS. These are written in Fortran or C anyway. Whether you call the libraries from Fortran or Python may not matter very much! In the end, the code that can really benefit from being moved to C or Fortran is rare to come by. Python is a very high-level language. That means there are certain things that put constraint on the attained speed. Most importantly: keep the number of interpreter evals as scarce as possible. If you make a for loop, the interpreter may evaluate the lines within the loop several times. Languages like C, C++ and Java really teach you bad habits when it comes to an interpreted language like Python. In these languages, loops are almost free. In Python, they may be very expensive as the interpreter is invoked multiple times. But if you can 'vectorize' the loop statement into a one-liner (or a few lines) using slicing, list comprehensions or functional programming (e.g. the lambda, map and filter intrinsics), the overhead will be very small. That is the secret to getting high-performance from a language like Python. If you can get away from the C++ habit of using for loops for any kind of iteration, Python may not feel sluggish at all. In the end, the main determinant of performance in numerical tasks is really big-O, not the language you prefer to use. Choice of algorithm is fare more important than the Python vs. Fortran issue! -- http://mail.python.org/mailman/listinfo/python-list
