🚀 go-pugleaf

[Followups redirected to comp.lang.misc only]
In article <4dhuoj$cbe@shellx.best.com> yogi@shellx.best.com (Yogi) writes:
> I don't want to start a religeous war, and YES, I did read the FAQ's,
> and did not find any info on relative speed of comparing C vs Perl vs Tcl
> vs Java in a very general sort of fashion.

There is a recent posting in comp.lang.java attempting such a comparison.

> I'm very interested in the uses of Tcl and Perl, with regard to Tk and 
> other GUI toolkits (what other's are there?)

By now, almost everybody working with the two languages, seems to be committed
to Tk.

> Can't seem to find any info on statements I have read that seem to conflict:

> Somewhere I have read that Perl coded grep runs as fast or faster than C
> coded grep in Unix. (Larry Wall wrote this, correct me if I'm wrong.)

Possible. grep is almost built into perl.

> And in a CGI-web book I read that Perl is an interpreted language that runs
> 10 times slower than C.

According to Tom Christiansen, a typical factor is on the order of "e", i.e.,
2.7.

> But Perl is compiled, right?

Precompiled, I'd say. I wouldn't call a language "compiled" unless there exists
a mechanism for storing compiled programs in non-source form. A compiler is in
development, though. 

> So how is that different than say, the Tcl interpreter?

Perl and Tcl are almost on the two extreme sides of interpreter
technology. Perl precompiles into an internal parse tree, while Tcl is pure
sring substitution. As an example, compare:

Perl:                                Tcl:
for ($i = 0; $i<100; $i++) {         for {set i 0} {$i<100} {incr i} {
 for ($j = 0; $j=100; $j++) {         for {set j 0} {$j<100} {incr j} {
  for ($k = 0; $k<100; $k++) {         for {set k 0} {$k<100} {incr k} {
   print $i, " ", $j, " ", $k, "\n";    puts "$i $j $k\n";
  }                                    }
 }                                    }
}                                    }

Syntactically, the two examples are very similar. But while the Perl lexical
analyzer makes a single pass over the text of the innermost loop, the Tcl
lexical analyzer makes MORE THAN A MILLION passes over the text.

This does not mean, though, that Tcl is bad. In fact, I find it more than fast
enough for the work I do in it.

> So what's the real answer, or are both statements true somehow? I know that
> Perl can run faster or slower depending on how you code it, (C too) and so I
> guess you would have to find the fastest C code for a particular function and
> similar fastest Perl code (or Tcl) and compare THOSE programs to get a
> definative answer.

One important point to make here is that for text processing problems, it is
much easier writing a close to optimal Perl solution that a close to optimal
C solution and therefore, the Perl solution is often faster although it is
easily proven that a C solution that is at leats as fats must exist.

> And then, what about the speed of Java in comparison to the other 3?

Java proponents will tell you that this doesn't matter because Java has "won"
already. Java detractors will tell you that your question is pointless as there
are not a single release quality implementation of Java in existence as of now.

Matthias

-----
Matthias Neeracher <neeri@iis.ee.ethz.ch> http://err.ethz.ch/members/neeri.html
  "We have built a lot of security directly into Java to make it virus-proof.
   And people's concerns about security on the Net tend to be based on age.
   You talk to people in their twenties and they are much less concerned about
   it than older generations. Pretty soon it won't worry them at all."'
                                -- Scott McNealy, _Sunday Times_ 19Nov95

yogi@shellx.best.com (Yogi) writes:

>Can't seem to find any info on statements I have read that seem to conflict:

Have you ever heard the phrase "Lies, damned lies, and benchmarks"?

>Somewhere I have read that Perl coded grep runs as fast or faster than C
>coded grep in Unix. (Larry Wall wrote this, correct me if I'm wrong.)

Sounds quite likely to be true.
For this specific task, Perl could easily be as fast as C.

>And in a CGI-web book I read that Perl is an interpreted language that runs
>10 times slower than C.

For most programs, that is probably true.

>But Perl is compiled, right?

Sort of.  Perl code gets compiled to a bytecode which is then interpreted.

>So how is that different
>than say, the Tcl interpreter?

It's much more efficient.

>So what's the real answer, or are both statements true somehow? I know that
>Perl can run faster or slower depending on how you code it, (C too) and 
>so I guess you would have to find the fastest C code for a particular function
>and similar fastest Perl code (or Tcl) and compare THOSE programs to get 
>a definative answer.

That's right, although even then the answers will no doubt be subject
to much debate.  I'm afraid that obtaining a genuinely definitive
answer on questions like this is prohibitively expensive.

>And then, what about the speed of Java in comparison to the other 3?

The currently available implementation of Java uses the same basic
technology (compiling to bytecodes) as Perl, so performance is likely
to be pretty similar.  But Java is probably much easier to write
an efficient native-code compiler for.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3

Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
: yogi@shellx.best.com (Yogi) writes:

: >Can't seem to find any info on statements I have read that seem to conflict:

: Have you ever heard the phrase "Lies, damned lies, and benchmarks"?

: >Somewhere I have read that Perl coded grep runs as fast or faster than C
: >coded grep in Unix. (Larry Wall wrote this, correct me if I'm wrong.)

: Sounds quite likely to be true.
: For this specific task, Perl could easily be as fast as C.

You have to remember that Perl program will be about 3 lines long, and
most of the CPU intensive work is regexp matching and file operations.
In Perl, both of those are very highly optimized C routines.
Therefore, such a 'Perl' program is essentially a C program; you are
using it for exactly what Perl was designed to do very well.

: >And in a CGI-web book I read that Perl is an interpreted language that runs
: >10 times slower than C.

: For most programs, that is probably true.

BTW, 10 times is about typical for bytecode compilers; 7-15 or so is a
reasonable range, except where the time is dominated by 'high level'
constructs, where it can be 2-3 or much lower, as noted above.

: >So what's the real answer, or are both statements true somehow? I know that
: >Perl can run faster or slower depending on how you code it, (C too) and 
: >so I guess you would have to find the fastest C code for a particular function
: >and similar fastest Perl code (or Tcl) and compare THOSE programs to get 
: >a definative answer.

An important point, though, is that all 'reasonably' written C programs
will run within a factor of 2 or so of 'about as fast as you can get,
while for some problems, Perl won't be able to break through about a
factor of 7 or so, even if you are a Perl expert.  Languages like Perl
tend to be important in context where you are willing to give up the
speed advantage for some other features of the language.  Let's face
it; very few applications need C's speed any more.

--
Tim Hollebeek      | Everything above is a true statement, for sufficiently
PChem Grad Student | false values of true.
Princeton Univ.    | tim@wfn-shop.princeton.edu
-------------------| http://wfn-shop.princeton.edu/~tim

>>>>> "Tim" == Tim Hollebeek <tim@franck> writes:

Tim> An important point, though, is that all 'reasonably' written C programs
Tim> will run within a factor of 2 or so of 'about as fast as you can get,
Tim> while for some problems, Perl won't be able to break through about a
Tim> factor of 7 or so, even if you are a Perl expert.

I just want to point out to everyone that you are simply making that
figure up based on what you think Perl is doing internally.

Tom Christiansen has had a long-standing bet that someone can't give
him a program in C that he can't make run no more than "e" times
slower (about 2.8 for you non-math-geeks) in Perl.  So far, no one's
done it.

That's also been my experience as well.  Perl is *not* slow.  In fact,
a Perl-written egrep is *faster* than most vendor's egrep, for
example.

So, if you have a number of "7-times-slower" programs, post'em, and I
bet we can easily boost their speed by two or three times.

ObDisclaimer: Yes, I know a few things about Perl. :-)
-- 
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <merlyn@stonehenge.com> Snail: (Call) PGP-Key: (finger merlyn@ora.com)
Web: <A HREF="http://www.teleport.com/~merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me

In article <ukvim4pceu.fsf@linda.teleport.com>,
Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>>>>>> "Tim" == Tim Hollebeek <tim@franck> writes:
>Tim> An important point, though, is that all 'reasonably' written C programs
>Tim> will run within a factor of 2 or so of 'about as fast as you can get,
>Tim> while for some problems, Perl won't be able to break through about a
>Tim> factor of 7 or so, even if you are a Perl expert.

>I just want to point out to everyone that you are simply making that
>figure up based on what you think Perl is doing internally.

>Tom Christiansen has had a long-standing bet that someone can't give
>him a program in C that he can't make run no more than "e" times
>slower (about 2.8 for you non-math-geeks) in Perl.  So far, no one's
>done it.

>That's also been my experience as well.  Perl is *not* slow.  In fact,
>a Perl-written egrep is *faster* than most vendor's egrep, for
>example.

But is it faster than GNU grep?  :)

>So, if you have a number of "7-times-slower" programs, post'em, and I
>bet we can easily boost their speed by two or three times.

HAH! I found Randall making a mistake...

He didn't say 7 times slower.  He said about 3.5 times slower, which is not
nearly as strong.  He gave perl a factor of 7, but C a factor of 2.

That sounds believeable.  For anyone other than you perl wizards, quite sane
even.  Although I think I know an example that I could use... Maybe I should
talk to Tom.  (And what do I get if I win?)

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1995 Peter Seebach.
C/Unix proto-wizard -- C/Unix questions? Send mail for help.  No, really!
Using trn?  Weird new newsgroup problem?  I know the fix!  Email me!
The *other* C FAQ - ftp taniemarie.solon.com /pub/c/afq - Not A Flying Toy

 [courtesy cc of this posting sent to cited author via email]

In comp.lang.perl.misc, 
    seebs@solutions.solon.com (Peter Seebach) writes:
:>Tom Christiansen has had a long-standing bet that someone can't give
:>him a program in C that he can't make run no more than "e" times
:>slower (about 2.8 for you non-math-geeks) in Perl.  So far, no one's
:>done it.

Well, fibonacci implemented recursively is slower than that.  
Matrix multiply is slower than that.  But most things are 
faster than the stdly quoted 10x, mostly because I can figure
out ways to get it to spend all its time in C.

:But is it faster than GNU grep?  :)

No, but it's much faster than std fgrep.

--tom
-- 
Tom Christiansen      Perl Consultant, Gamer, Hiker      tchrist@mox.perl.com

    The nice thing about standards is that there are so many of them to
    choose from.  -- Andrew S. Tanenbaum

Randal L. Schwartz (merlyn@stonehenge.com) wrote:
: >>>>> "Tim" == Tim Hollebeek <tim@franck> writes:

: Tim> An important point, though, is that all 'reasonably' written C programs
: Tim> will run within a factor of 2 or so of 'about as fast as you can get,
: Tim> while for some problems, Perl won't be able to break through about a
: Tim> factor of 7 or so, even if you are a Perl expert.

: I just want to point out to everyone that you are simply making that
: figure up based on what you think Perl is doing internally.

: Tom Christiansen has had a long-standing bet that someone can't give
: him a program in C that he can't make run no more than "e" times
: slower (about 2.8 for you non-math-geeks) in Perl.  So far, no one's
: done it.

	I find that exceptionally hard to beleive.  What is this bet 
exactly?  Do I get any money for "winning" it?  For example, I have 
some programs that are heavily math-intensive, ( matrix multiplies,
number cracking, image manipulation ) which I have written in C, 
which I would be shocked as all get-out to see run nearly as fast in 
PERL.

: That's also been my experience as well.  Perl is *not* slow.  In fact,
: a Perl-written egrep is *faster* than most vendor's egrep, for
: example.

	Sure, as long as you are writing grep, it's great.  That's
because you're then spending 99% of your time in some C code that's
already been way optimized.

: So, if you have a number of "7-times-slower" programs, post'em, and I
: bet we can easily boost their speed by two or three times.

	Okay.  It's a bit long, but this finds amicable number pairs
using the dumb old-try-every-number method.  I'd be shocked to see a
2.8 factor, and be even mildly surprised to even see 7 times as fast
C->Perl.

#include <iostream.h>
#include <math.h>
#include <stdlib.h>
#include <string.h>

typedef unsigned int Int;
char *Table;

unsigned int SumOfFactors( Int Num )
{
    Int Res = 1;
    Int SNum = Int( floor( sqrt( (double) Num ) ) );
    memset( Table , 0 , SNum );
    for( Int i = 2 ; i < SNum ; ++ i )
    {
      if ( Table[ i ] == 0 )
      {
        int divresult = Num / i;
        int Remainder = Num - ( divresult * i ) ;
        if ( Remainder == 0 )
	{
	  Res += i;
	  Res += divresult;
	}
        else
        {
          int temp = i;
          while( temp < SNum )
          {
            Table[ temp ] = 1;
            temp += i;
          }
        }
      }
    }
    return Res;
}

main( int argc , char *argv[] )
{
    Table = new char[ 1000000 ];

    for( Int i = 1 ; i < 1000000000 ; ++i )
    {
        if ( ( i % 100000 ) == 0 )
        {
            cout << "Reached " << i << endl;
        }
        Int r1 = SumOfFactors( i );
        if ( r1 == i )
            cout << "Perfect " << i << endl;
        else
        {
            Int r2 = SumOfFactors( r1 );
            if ( r2 == i )
                cout << "Amicable : " << r1 << " " << r2 << endl;
        }
    }
}
        


--
------------------------------------------------------------------------------
David Hanley,                 |______     Computer Science graduate student.  
dhanley@lac.ecs.uic.edu       |\ ___/__  Martial Artist. Biker. Chess Freak   
www_lac.eecs.uic.edu/~dhanley/| \\ /  / Libertarian.  Atheist.  Bisexual.     
My employer barely KNOWS me.  |  \/BI/ Aspiring novelist.Joyce Kafka Neitzchie
-----------------------------------\/-----------------------------------------
Member:Hermetic order of the Golden Dawn.

In article <4e0af7$glv@csnews.cs.colorado.edu>,
Tom Christiansen  <tchrist@mox.perl.com> wrote:
> [courtesy cc of this posting sent to cited author via email]

>In comp.lang.perl.misc, 
>    seebs@solutions.solon.com (Peter Seebach) writes:
>:>Tom Christiansen has had a long-standing bet that someone can't give
>:>him a program in C that he can't make run no more than "e" times
>:>slower (about 2.8 for you non-math-geeks) in Perl.  So far, no one's
>:>done it.

I didn't write that.  Much though I appreciate being credited with
Merlyn's work, he said that, and I responded.

>Well, fibonacci implemented recursively is slower than that.  
>Matrix multiply is slower than that.  But most things are 
>faster than the stdly quoted 10x, mostly because I can figure
>out ways to get it to spend all its time in C.

Hmph.

>:But is it faster than GNU grep?  :)

>No, but it's much faster than std fgrep.

Uhm, not to be picky, but a distracted half-blind cat is significantl
faster than standard fgrep.

(Depends, though; whose fgrep is "standard"?  Also, on what kind of
match; I seem to recall that fgrep beat egrep on matching for any
of 200+ fixed strings, in a historical implementation.)

>    The nice thing about standards is that there are so many of them to
>    choose from.  -- Andrew S. Tanenbaum

I've been wondering who said that.  Thx.

-s
[Courtesy cc: of this posting copied to /dev/null.]
-- 
Peter Seebach - seebs@solon.com - Copyright 1995 Peter Seebach.
C/Unix proto-wizard -- C/Unix questions? Send mail for help.  No, really!
Using trn?  Weird new newsgroup problem?  I know the fix!  Email me!
The *other* C FAQ - ftp taniemarie.solon.com /pub/c/afq - Not A Flying Toy

Randal L. Schwartz wrote:
> 
> >>>>> "Tim" == Tim Hollebeek <tim@franck> writes:
> 
> Tim> An important point, though, is that all 'reasonably' written C programs
> Tim> will run within a factor of 2 or so of 'about as fast as you can get,
> Tim> while for some problems, Perl won't be able to break through about a
> Tim> factor of 7 or so, even if you are a Perl expert.
> 
> I just want to point out to everyone that you are simply making that
> figure up based on what you think Perl is doing internally.
> 
> Tom Christiansen has had a long-standing bet that someone can't give
> him a program in C that he can't make run no more than "e" times
> slower (about 2.8 for you non-math-geeks) in Perl.  So far, no one's
> done it.
> 
> That's also been my experience as well.  Perl is *not* slow.  In fact,
> a Perl-written egrep is *faster* than most vendor's egrep, for
> example.
> 
> So, if you have a number of "7-times-slower" programs, post'em, and I
> bet we can easily boost their speed by two or three times.
> 
> ObDisclaimer: Yes, I know a few things about Perl. :-)
> --How about diff? ...

In article <4e06en$a6v@solutions.solon.com>,
Peter Seebach <seebs@solutions.solon.com> wrote:
>In article <ukvim4pceu.fsf@linda.teleport.com>,
>Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>>>>>>> "Tim" == Tim Hollebeek <tim@franck> writes:
>>Tim> An important point, though, is that all 'reasonably' written C programs
>>Tim> will run within a factor of 2 or so of 'about as fast as you can get,
>>Tim> while for some problems, Perl won't be able to break through about a
>>Tim> factor of 7 or so, even if you are a Perl expert.
>
>>I just want to point out to everyone that you are simply making that
>>figure up based on what you think Perl is doing internally.
>
>>Tom Christiansen has had a long-standing bet that someone can't give
>>him a program in C that he can't make run no more than "e" times
>>slower (about 2.8 for you non-math-geeks) in Perl.  So far, no one's
>>done it.
>
>>That's also been my experience as well.  Perl is *not* slow.  In fact,
>>a Perl-written egrep is *faster* than most vendor's egrep, for
>>example.
>
>But is it faster than GNU grep?  :)
>
>>So, if you have a number of "7-times-slower" programs, post'em, and I
>>bet we can easily boost their speed by two or three times.
>
>HAH! I found Randall making a mistake...
>
>He didn't say 7 times slower.  He said about 3.5 times slower, which is not
>nearly as strong.  He gave perl a factor of 7, but C a factor of 2.
>
>That sounds believeable.  For anyone other than you perl wizards, quite sane
>even.  Although I think I know an example that I could use... Maybe I should
>talk to Tom.  (And what do I get if I win?)

If anyone gives Tom an example that he has trouble with, I'm sure we can 
push it through the compiler, even if it's not ready for release yet.
That should bring it down below the magic e factor.

--Malcolm

-- 
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Oxford University Computing Services
"Widget. It's got a widget. A lovely widget. A widget it has got." --Jack Dee

On 22 Jan 1996, Randal L. Schwartz wrote:

> Tim> An important point, though, is that all 'reasonably' written C programs
> Tim> will run within a factor of 2 or so of 'about as fast as you can get,
> Tim> while for some problems, Perl won't be able to break through about a
> Tim> factor of 7 or so, even if you are a Perl expert.
> 
> I just want to point out to everyone that you are simply making that
> figure up based on what you think Perl is doing internally.
> 
> Tom Christiansen has had a long-standing bet that someone can't give
> him a program in C that he can't make run no more than "e" times
> slower (about 2.8 for you non-math-geeks) in Perl.  So far, no one's
> done it.

hang on.  i think you missed what he's saying.  he said, effectively,
no that perl runs no less than 7 times slower than c, but that it runs
about 3.5 times slower.  ok, it's still about 26% up on e, but it
isn't quite as far from reality.

obviously, though, something that perl is very efficient at will go
like anything, because that's what the bytecode was designed for.
(similar results can be seen when rewriting a forth word in assembler,
for example.)  but for "generic" applications, of course c will
outpace perl, simply because a bytecode interpreter adds a 1-200%
overhead to _any_ program.

xian the desk lisard -- cdahello@comp.brad.ac.uk
    time's taught the killing game herself
  NO        i taught the killing game
                                              first