Choosing Perl/Python for my particular niche

[Cameron Laird]

In article <40661C14.8365E058 at doe.carleton.ca>,
Fred Ma  <fma at doe.carleton.ca> wrote:
			.
			.
			.
>On the topic of speed, It's surprising to hear that this can be possibly rivaled
>by Perl/Python, considering that even my matlab code is about 10x slower than
>C++.  That's with extensive profiling and round-about coding styles to exploit
>vectorization tricks, and no such effort in the C++ code.  Some of the
>limitations are pretty fundamential e.g. large speed penalties for invoking
>nonbuiltin functions.  Such limitations discourage clear coding practice e.g.
>huge swaths of code to avoid encapsulating some functionality in its own
>function.  Together with the sometimes roundabout coding style, it can detract
>from the matlab's high level ease of programming and clarity, especially
>considering that C++ can be brought to a high level with its STL library.  And
>this speed disparity shows up despite matlab's mission to develop in a way that
>rivals 3G languages.  Speed considerations aside, however, matlab is infinitely
>easier to use and to read.  With time, perhaps the limitations will shrink.
>
>This is not to say that Perl/Python will have the same limitations.  They are,
>however, more general purpose languages, so I expect that speed is less of a
>priority than in scientific computing (compared to other important priorities).
>Hence, learning curve aside, some time needs to be invested in exploring its
>speed in a realistic scientific applications.  For me, this is an option for the
>more distant future rather than the immediate term. I spent quite alot of time
>in this phase with matlab, trying to squeeze out all possible speed before
>conceding that some of the limits were fundamental, at least in the current
>release.
>
>One thing I learned was that speed characterization was not a simple.  Many of
>the tasks found in scientific computing are done blistering fast by matlab.  It
>is not until you put together a larger application when you start running into
>the limitations.  Aside from the speed penalties of calling nonbuiltins,
			.
			.
			.
'Couple of reactions:  first, I think it's entirely healthy 
for you to focus on finishing your dissertation.  Everything
else is and should be subordinate to that.  Picking up as
much of Perl as you need to achieve that goal, but not more,
is thoroughly sensible.

Second, be aware that I'm the only one in this thread who has
made explicit claims that it's reasonable to expect Perl- or
Python-based applications to rival those in C++ for
performance.  Maybe I'm wrong, or, more charitably, maybe I'm
making assumptions that I've kept implicit.  It certainly is
possible to exhibit comparable-looking C and Python programs,
where the former is over a hundred times as fast as the latter.
Still, I'm sticking with my claim:  for practical, effective
algorithmic experimentation, PDL, Numpy, and comparable exten-
sions bring 'P' programs' achieved speed up to the level of
C++.

Ultimately, you're right:  "speed characterization [is] not
simple."

Perl and Python feel like breaths of fresh air after Matlab
precisely for their scalability and maintainability.  Matlab
just doesn't generalize and abstract and express as agilely
as the more general-purpose programming languages.
-- 

Cameron Laird <claird at phaseit.net>
Business:  http://www.Phaseit.net