On Tue, 2005-02-08 at 22:44, Caleb Hattingh wrote: > Hi m > > Speed is a contentious issue here. Point is, if you really need raw > speed, why stop only at Perl and Python? There are plenty of statically > compiled languages that will produce native binaries. > > The relative difference in speed between Perl and Python, whatever it is, > is completely washed out by the enormous jump using, say, C for example > [please, everyone else, I am aware of all the mitigating circumstances > regarding, e.g. parts of the standard library written in C, etc. That is > not my point.]
I think the expression you seek is "comparing virtue among whores." Now we can all acknowledge that there is a spectrum in the programmer time vs machine time trade-off. (Voice reader users: Please forgive my ASCII art ... imagine a data set that loosely fits a linear relationship with a negative slope.) ASCII art start + M|* A| * * C| * H| * "STUPID" I| * * N| * E| * | * C| * * O| "Holy * S| Grail" * T| * 0------------------------- + PROGRAMMER COST ASCII art stop This metric is actually in two dimensions, but we usually consider it in one dimension with High Machine cost and low programmer cost at one extreme and low machine cost and high programmer cost at the other extreme. ASCII art start High Machine <---------------> High Programmer Cost ASCII art stop because there is a high inverse correlation between programmer and machine costs. Only a fool would use a programing language in the "stupid" area of the above chart (both costs high). Likewise, nobody gets to use the language that does not exist in the "Holy Grail" area of the chart (both costs low.) Both Python and Perl are way up in the upper left ( machine cost high, programmer cost low) of my little chart. Perl has much magic that drives up its programmer cost. Not by much in the know, but by enough that I would consider it to have a slightly higher programmer cost than Python. If Perl code executes a bit faster, then fine, all I can say is "that's nice." If machine costs were an issue I'd recode in vhdl and compile to silicone. Of the topic I want to address, you can entirely circumvent those issues by coding in C and using the Python C-API instead of strcmp and friends. > > A Good Reason for thinking along these lines (Perl/Python) is more > something like speed and reliability of development. Another one is > maintaintability. I must confess that I know pretty much nothing about > Perl, so I can't comment about that. My opinion about Python is that it > is very, very good for these things. > > The problem domains in which I do most of my work (chemical process > modelling and simulation) really do require speed. That's why I mostly > use Delphi (i.e. reasonably fast code) at work. I believe I know when > speed is and is not an issue, and (by far) most of the time, my experience > is that it is *not*. So I use Delphi for numerical code and python for > everything else. Why don't you use C for the numerical work? Then you can do your number crunching within a c-based python module. Have your cake and ... > > You really will have to convince people here that execution speed is a > real issue for your programming task (in order to continue this > discussion). Otherwise the debate will go south real quick. Not only most speed be an issue, but the economics must be such that any alternative is better than throwing more hardware at the problem. Adam DePrince -- http://mail.python.org/mailman/listinfo/python-list
