Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Perl speed VS. other languages

by tretin (Friar)
on Jan 15, 2002 at 06:57 UTC ( #138796=perlmeditation: print w/ replies, xml ) Need Help??

I come to harken unto the abounding programming knowledge of the monks! Recently, while having a chat with a programmer friend, the subject of perl came up (imagine!) and he said that, while he liked coding in Perl, he found C to be more useful because it was faster. He attributed this speed to C being a compiled language (I THINK is what he said, not sure though as I have eaten since then); my question is, is C really superior to Perl in speed, or is my friend just a dirty stinking rotten liar? Also, how does Perl compare with the likes of C, C++, Java, COBOL, Pascal, basic, and whatever other languages are out there? I'm sure this question has been raised a bazillion times (so sorry if this seems a tedious node, but I posess an inquisitive mind so I'd like to know!), and if this was not the proper forum for this discussion, sorry again.

Thanks monks!

Comment on Perl speed VS. other languages
Re: Perl speed VS. other languages
by FoxtrotUniform (Prior) on Jan 15, 2002 at 07:36 UTC

    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
      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

      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?

Re: Perl speed VS. other languages
by dws (Chancellor) on Jan 15, 2002 at 08:07 UTC
    ... he found C to be more useful because it was faster.

    I find Perl more useful because I get done faster. A lot faster. And the real truth is that for more than 90% of the stuff you do with software (outside of the real-time realm), sooner wins over faster by a wide margin.

Re (tilly) 1: Perl speed VS. other languages
by tilly (Archbishop) on Jan 15, 2002 at 09:36 UTC
    Yes, C executes faster than Perl.

    But it is often easier to write better programs in Perl than C.

    Hand the following problem to your co-worker as a problem. Anagrams are words which are the same except for the order of the letters. Write a program which takes a list of words (separated by newlines) on STDIN, and then prints out all of the different anagrams. (Tell him to make it case insensitive if he can, if he can't then don't worry too much about that detail.) Ask your friend to do it in C.

    When your friend is done, have your friend compare his performance with the simple script that I threw together in 5 minutes and posted to Find anagrams. Take a reasonable sized /etc/dictionary and throw it at both programs.

    For more advocacy about using Perl instead of C see Re (tilly) 1: Why Use Perl?. It is about web programming in particular, but many of the points apply to other environments.

Re: Perl speed VS. other languages
by runrig (Abbot) on Jan 15, 2002 at 10:17 UTC
    Hmm, if I can write something in a couple of minutes that your friend takes a couple of hours to write, I can take a 118 minute coffee break while my program is running and your friend is still working on his program. And so for the first run we'll probably be done at about the same time. For a throwaway program, or for programs where the time difference isn't so great (such as when doing database access) I prefer doing it my way. For a time-critical process that we're going to run alot, and is not likely to change much (and if his is really 100 times faster), we'll use mine as a prototype until your friend finishes his.

    The difference in runtime can be up to 100 times faster for C, but depending on the task, isn't always that great. The difference in development time (and in making modifications) can be the same but in perl's favor.

Re: Perl speed VS. other languages
by Juerd (Abbot) on Jan 15, 2002 at 15:06 UTC
    I suggest you let your friend read Ten Perl Myths, especially "Perl is too slow".
    About the other languages: C and C++ programs execute faster, Basic programs are a lot slower. Java's speed depends on a lot of things, and I know nothing about COBOL and Pascal.
    For a lot of things, it's better to have speedy development instead of speedy execution.

    Think about how you would write this in C(++):
    push @foo, [ split /:/ ] while <>; print map { "$_->[0]\n" } sort { $a->[2] <=> $b->[2] } @foo; # Two lines, for clarity. # Of course I could have used another map.
    The C(++) equivalent may execute a lot faster, but how long does programming it take? I guess it'll take longer than the one minute I spent on it.

    2;0 juerd@ouranos:~$ perl -e'undef christmas' Segmentation fault 2;139 juerd@ouranos:~$

      I quite agree! See my post, 'Re: Perl speed VS. other languages'.

      dmm

      If you GIVE a man a fish you feed him for a day
      But,
      TEACH him to fish and you feed him for a lifetime
Re: Perl speed VS. other languages
by andye (Curate) on Jan 15, 2002 at 17:04 UTC
    Perfectly decent question.

    C *is* faster, of course, though for web-stuff Perl gets a big speed boost if you use 'mod_perl', an extension to the Apache webserver which makes Perl behave more like a traditionally compiled language.

    Which is better depends what you're doing. You wouldn't (or, at least, *I* wouldn't) write heavy graphics stuff in Perl, or any other stuff where it's important that it goes as quickly as poss. For lots of other applications though, development time is more important than speed of execution, and a program is usually quicker to write in Perl than C. The programmers wages are often more expensive than the hardware.

    andy.

Re: Perl speed VS. other languages
by larryk (Friar) on Jan 15, 2002 at 17:10 UTC
Re: Perl speed VS. other languages (the best of both worlds)
by grinder (Bishop) on Jan 15, 2002 at 18:07 UTC
    The question is moot, since Perl is written in C and one can be expressed in terms of the other.

    You can write things quickly in Perl, as runrig so eloquently states, then, should your Perl prototype be too slow, you can use Devel::DProf to pinpoint where the most time is being spent, and then recast those parts in C. These days, with the advent of Inline this is not as difficult as it sounds. Otherwise, if your are brave, you can write your own XS code.

    And then, looking at things the other way around, nothing is stopping you from embedding Perl inside your own C program, thus again giving you the best of both worlds.

    --
    g r i n d e r
    print@_{sort keys %_},$/if%_=split//,'= & *a?b:e\f/h^h!j+n,o@o;r$s-t%t#u';
Re: Perl speed VS. other languages
by runrig (Abbot) on Jan 15, 2002 at 22:32 UTC
    ...he found C to be more useful because it was faster.

    useful...faster/apples...oranges :-)

    I find perl to be more 'useful' because there's CPAN :)

Re: Perl speed VS. other languages
by dmmiller2k (Chaplain) on Jan 16, 2002 at 00:04 UTC

    It is my contention that Perl (once compiled) runs noticably faster than Java (obviously using similar code), at least on the machines I ran tests on (a 300mhz dual-CPU Ultrasparc workstation running Solaris 2.6 and a 700Mhz PC running NT 4.0 SP6a).

    A consulting client had a web-page generated by Perl using CGI, and I re-implemented it in Java. There was a pure text manipulation part of the code (sorry, it was proprietary and I wasn't able to take it with me), which took about five seconds to produce an output web page using Perl 5.005_03 on Solaris 2.6.

    The same thing, written as a Java 1.18 Servlet (under JServ 1.0, with Apache 1.3.2 on the same web server) also took five seconds to run and produce the results page.

    If that sounds the same, note well that the Perl implementation was a vanilla CGI program (i.e., no mod_perl, FastCGI or the like), so that five seconds includes the standard Solaris process-startup delay plus the Perl startup/compile delay.

    I would have loved to pursue this further, but unfortunately my contract ended first.

      5 seconds to produce a page?

      That doesn't sound to me like a language issue. It sounds like an algorithm issue or a bottleneck somewhere. I would start asking questions about rendering time in the browser, database connections, and the like.

      Unless, of course, there was something inherent in what it did that made 5 seconds seem like a reasonable amount of work to do...?

        Understand, this particular page was doing a huge amount of processing (a lot of nested loops) before producing results. The actual page generation was done after the processing, and was essentially a single print statement, e.g., print join( "\n", header, start_html, ..., end_html ), so there were no speed issues in that regard (trust me -- there might have been, but in this case there weren't).

        My point was that, after accounting for the process startup time, compile time, etc. of an otherwise standard CGI Perl program, the net run time was probably about three seconds (give or take a half second or so). In contrast, the Java Servlet implementing the same algorithm took roughly five seconds (also, give or take about a half second).

        In my opinion, Perl beats (non-JIT inlined) Java in raw performance.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://138796]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (7)
As of 2014-12-27 00:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (176 votes), past polls