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.

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.

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?

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.

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.

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.

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.

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.

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