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.

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.

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.

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?

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.

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.
[download]

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

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

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.

   larryk                                          
perl -le "s,,reverse killer,e,y,rifle,lycra,,print"

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

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.

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

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