Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re: Perl speed VS. other languages

by FoxtrotUniform (Prior)
on Jan 15, 2002 at 07:36 UTC ( #138798=note: print w/replies, xml ) Need Help??


in reply to Perl speed VS. other languages

One thing to consider when evaluating "why" Perl is (generally) slower than a compiled language, like C, is that tokenization and parsing happens once for compiled programs, but every time you run a Perl script.

As for speed in general, I imagine it depends on what you do with the language. My only data point is on some fairly brute-force statistics (regression analysis): I ran pretty much the same program in C and in Perl, and the C program ran about 200 times faster. I suspect that Perl is much closer to C in areas like string manipulation, where Perl has very heavily optimized (C) primitives. Keep in mind that, since Perl is implemented in C, optimizations being equal C will always be (even just a little bit) faster than Perl, since Perl scripts will be running code written in C, plus the tokenizer and parser.

Language speed depends heavily on how good an optimizer the compiler or interpreter has, and how well it can take advantage of the hardware. That said, program speed is often dependent on the algorithms you use, not the language; if speed is important to you, choose a language that makes writing quick algorithms easy before worrying about this kind of issue.

--
:wq

Replies are listed 'Best First'.
Re: (FoxUni) Re: Perl speed VS. other languages
by nooa (Beadle) on Jan 15, 2002 at 08:54 UTC
    I ran pretty much the same program in C and in Perl, and the C program ran about 200 times faster.

    In a simalar vein, I ran the Pontifex encryption algorithm (Solitare) on a fairly slow computer with both the C and Perl versions on the American Standard Bible. The C version ran in a minute and a half. I just killed the Perl version after an HOUR and a half.

    Considering purely speed with most kinds of mathmatical algorithms leads you to think C is better to Perl. However, modern computing power almost makes this problem a non-issue for anything but 3D games or high end simulators. If getting things done in Perl is easier for you (which, of course, it is :-) ), I think Perl will save more time.

      Considering purely speed with most kinds of mathmatical algorithms leads you to think C is better to Perl. However, modern computing power almost makes this problem a non-issue for anything but 3D games or high end simulators.

      Well, realtime 3D is my field of choice, which gives me some appreciation for C. :-)

      It's rather naive to say that, in general, program speed doesn't matter because (a) modern computers are just so damn fast that they chew through any problem in no time or (b) any program can be made fast enough by throwing hardware at it, because modern hardware is so cheap for what you get. Even in good ol' web automation, which many people think of as the only thing that Perl's good for (lo these many years ago, I was victim to this fallacy), speed is important, especially on large data sets.

      But especially on large data sets, it isn't language speed that's important, it's algorithm speed, first of all asymptotic order, that's vitally important. It doesn't matter whether your language of choice runs a thousand times faster than mine, statement for statement; if your program is O(n^2) and mine is O(n), on even remotely large data sets I'm going to win. That's the point. Forget about language-speed pissing contests. Pick up an algorithms book and start learning.

      --
      :wq
Re^2: Perl speed VS. other languages
by pbeckingham (Parson) on Jun 15, 2004 at 15:01 UTC

    My thoughts entirely. Get the right algorithm before worrying about execution speed.

    It also has to be stated that costs are often relevant here. It costs pennies to have a computer run a task for an hour, but it costs dollars to have me work on a program for an hour. My ability to complete a program quicker is going to be a considerable factor.

    Are there any known studies of how quickly languages allow implementation of set problems? This would be quite hard to administer.

    I suppose we could generate an equation that considered cost of developer(s), cost of operation, number of runs required, expected lifespan of code, time to implement, debug, time to run etc that might apply to projects. Anyone seen this?

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://138798]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (2)
As of 2022-05-19 22:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you prefer to work remotely?



    Results (72 votes). Check out past polls.

    Notices?