Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

Teach him a lesson with facts

by Anonymous Monk
on Feb 22, 2003 at 04:57 UTC ( #237665=perlmeditation: print w/replies, xml ) Need Help??

Yesterday, there was a heat flame all over the sky of this church. Although I don't agree with that Anonymous monk, but I felt really disappointed that no single monk came out, and taught him a lesson with facts.

Why nobody came out write up three pieces of code, one in Perl, one on c, one in Java and show him how wrong he is? Why?

I couldn't, as I don't know Java.

Instead, everyone rebated his post pointlessly, use flame to fight flame. Why I didn't see a single firefighter?

Even worse, one monk has a certain country of original, started spread his hatred towards American and her people, without a single thought of what US has given him, his job, his education, the freedom he enjoyed.

I am absolutely diappointed that most of those replies sounds like written by Robin Hood, not a warrior.

Replies are listed 'Best First'.
Re: Teach him a lesson with facts
by IlyaM (Parson) on Feb 22, 2003 at 09:26 UTC
    Frankly I don't see any reason to comment on that thread. Its author is obvious troll and he will not learn anything anyway. Your lesson will be wasted.

    __________________________ /| /| | | ||__|| | Please don't | / O O\__ feed | / \ the trolls | / \ \ | / _ \ \ ---------------------- / |\____\ \ || / | | | |\____/ || / \|_|_|/ | __|| / / \ |____| || / | | /| | --| | | |// |____ --| * _ | |_|_|_| | \-/ *-- _--\ _ \ // | / _ \\ _ // | / * / \_ /- | - | | * ___ c_c_c_C/ \C_c_c_c____________

    Ilya Martynov,
    CTO IPonWEB (UK) Ltd
    Quality Perl Programming and Unix Support UK managed @ offshore prices -
    Personal website -

      I ++ just for the ascii graphic... :)
      Update: ++ for being honest too... :)

      Pluralitas non est ponenda sine neccesitate - mysql's philosphy
Re: Teach him a lesson with facts
by perrin (Chancellor) on Feb 22, 2003 at 06:38 UTC
    A short benchmark (like the one he did) is meaningless, since it has so little resemblance to a real program. A longer one takes more time to do well. Responding to trolls is not worth the days or weeks of effort that it takes to make a legitimate and interesting benchmark.

    If you're interested in seeing benchmarks done to demonstrate Perl's performance, you should aim to create something more useful that can be shown to business people in the IT field; something along the lines of the benchmarks they publish for application servers in eWeek or similar publications. Meanwhile, you are welcome to look at this benchmark which puts mod_perl up against Resin and Tomcat. In both tests, mod_perl is faster and uses less memory. Source code is available for you to run it yourself.

Re: Teach him a lesson with facts
by adrianh (Chancellor) on Feb 22, 2003 at 14:21 UTC
    Why nobody came out write up three pieces of code, one in Perl, one on c, one in Java and show him how wrong he is? Why?


    • You don't feed the trolls.
    • Small benchmarks are pointless, unless you have to deal with a specific micro-optimisation (which is rare).
    • You don't feed the trolls.
    • Raw speed is not the only way you judge the utility of a language. The vast majority of the time it's not that important. Issues of maintainability, development speed, reliability, robustness, etc. are usually more important.
    • You don't feed the trolls :-)

    (Personally, I disagree with your other comment on an individual monk - but PM is certainly not the place to raise these issues.)

    People - please remember the first, third and fifth point above (and note how well points two and four were addressed :-)

      A troll is a troll, just becasue you think he is a troll.

      Call him troll 1000000000000000000000 times does not make your arguement more powerful.

      I am not surprised to see more people here are on the side you stand, as this is a Perl site. However man power does not prove you are right. 1 person say 1 = 1, and another 100000000000000 persons say 1 <> 2. So what?

      use logic, don't use strong wording, ;-) My advice is free.
        1 person say 1 = 1, and another 100000000000000 persons say 1 <> 2. So what?

        I guess all of them are right, since 1=1 and 1<>2 are both true. Or was it a trick question?

        The stupider the astronaut, the easier it is to win the trip to Vega - A. Tucket
Re: Teach him a lesson with facts
by derby (Abbot) on Feb 22, 2003 at 12:38 UTC
    I did write the code for all three languages and I did run them. I didn't post the code because 1) the poster was correct about the timing and 2) as others in the thread pointed out, it is a very contrived and useless test case for language comparison. Why does the Java and C code run faster? Loop optimization. The java compiler and c compiler I used optimized the loop away so the execution time is O(1). Perl did not optimize the loop away. Could it have? I'm not sure if there are any command line switches to do this type of optimization. Should that be the basis to throw away the whole language? No. Pure execution speed should be just one of your criteria and a very low one at that (otherwise we'd all be programming in machine language).


      Perl is very difficult to optimize. For example, take the code

      for (0..1_000_000) { $x=$_+1; }
      (Take my code, please!) In C, the equivlent code would be equivlent to x=1000001. In perl, you can't do that optimization, because $x might be tied, in which case, writing to it might have side effects. In C, you'd have to declare that, using the volitile keyword. In perl, there's no way to tell, so the compiler can't assume anything.
      Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

      So I was right about that testing.

      Now for whether that testing is meaningful. I tell what, it is meaningful. My purpose is not to show you that Perl cannot do ++ quick. What's wrong with perl is that it cannot do loop quick, as the first reply to your post agreed.

      This is something serious, loop is something you used everywhether in your real program, not a testing case made up by me.

      This is just a tip of the iceburger. I don't want argue about this any more. If you say this is the only performance issue in Perl, it is fine with me.

        I think you're misunderstanding how optimization works. Take the code posted above:

        for (0..1_000_000) { $x=$_+1; }

        Or in C or Java:

        int i, x; for(i = 0; i < 1000000; i++) { x = i + 1; }

        C and Java optimizers can turn the above into this:

        int x = 1000000;

        Thus totally eliminating the loop. Run your C compiler with -O0, and you'll get comparible performance to the Perl version.

        Why isn't this test relevent? Because the C/Java optimizer cannot always unroll loops. This is fairly common in any real-world program.

        Reinvent a rounder wheel.

        Note: All code is untested, unless otherwise stated

Re: Teach him a lesson with facts
by Enlil (Parson) on Feb 22, 2003 at 05:38 UTC

    Why nobody came out write up three pieces of code, one in Perl, one on c, one in Java and show him how wrong he is? Why?

    I think this would explain the main reason I would not try to write up code.

    As for the rest of your comments: They don't have anything to deal with why I come here (learn from other people methods, and help when I can), so there is no need for me to comment one way or another.


Re: Teach him a lesson with facts
by pg (Canon) on Feb 22, 2003 at 06:19 UTC
    Don't misunderstand, the fact I front paged this post does not mean I agree with you. On the contrary, I don't agree with you at all.

    I want to give everyone a chance to teach you a lesson, and give those good lessons high publicity. I know which monk you were talking about, when you talked about all the politics. I had some little discussion with that monk last week ;-), but I respect his contribution to this site, although it is not neccessary for us to agree with each other every single time.

    Is it not true that, what you just said showed a kind of pure hatred? (I do not mean your whole post is about hatred, but unfortunately hatred is a part of your post)

    When I said that I want everyone to teach you a lesson, I don't mean I hate you, but I really have some problem with some of your points.
Re: Teach him a lesson with facts
by Anonymous Monk on Feb 22, 2003 at 06:59 UTC
    Why nobody came out write up three pieces of code, one in Perl, one on c, one in Java and show him how wrong he is? Why? I couldn't, as I don't know Java.

    I know all three well. So why didn't I post examples? Because I don't care the slightest bit if ignorant trolls want to flame eachother, they're not worth my time. Try asking nicely for comparisons and I might help you out.

    Oh, and maybe, just maybe, Perl isn't always best.

Re: Teach him a lesson with facts
by hardburn (Abbot) on Feb 22, 2003 at 20:02 UTC

    I assume you mean that "Perl sux0rs, Java Ru1z" post. I didn't bother responding because it ammounts only to troll-feeding. There is only one question that needed to be asked of that post: is the original poster willing to show the actual code they ran in the benchmarks? This was asked by several people, but no code was forthcoming.

    IMHO, not showing the code in a benchmark is the scientific equivilent of not revealing your sources. Such people are practically cursed for life for not doing such in a scientific endeavor. While that might be going too far, there is a good argument for ignoring people who aren't willing to give enough data so that others can duplicate their results.

    Further, that post commited a number of logical fallacies, such as unrepresentative samples and generalizations.

    So the PM community reaction was probably more than should have been done. Any response can do nothing more than feeding a troll. If the orginal poster had shown the Java and Perl implementations of the code, then we might have something to work with. Until I see the code, I see no point in giving him any respect.

    Reinvent a rounder wheel.

    Note: All code is untested, unless otherwise stated

Re: Teach him a lesson with facts
by Aristotle (Chancellor) on Feb 22, 2003 at 20:42 UTC
    Please, can we let this die? We don't need a clone of that thread. Enough already.

    Makeshifts last the longest.

Re: Teach him a lesson with facts
by Aristotle (Chancellor) on Feb 24, 2003 at 12:25 UTC
Re: Teach him a lesson with facts
by Anonymous Monk on Feb 22, 2003 at 23:24 UTC
    Now this troll is back, waiting for wise people to teach me a lesson. You said there is some optimization in c and java, I got rid of them for you. Still perl:java:c = 34:7:5. The ball is again in your hands.
    $t1 = time(); open(FILE, ">", "file.txt"); for ($i = 0; $i < 1000000; $i ++) { print FILE $i++; } close(FILE); print "\n", time() - $t1; import java.util.Date; import*; public class test111 { public static void main(String[] argv) { int i; long t1 = System.currentTimeMillis(); try { FileOutputStream file = new FileOutputStream("file.txt"); PrintWriter out = new PrintWriter(file); for (i = 0; i < 1000000; i ++) { out.print(i ++); } out.close(); file.close(); } catch (Exception e) { } System.out.print((System.currentTimeMillis() - t1) / 1000); } } #include <stdio.h> #include <stdlib.h> int main(int argc, char * * argv) { int i; int t1; FILE * fp; t1 = time(0); fp = fopen("file.txt", "w"); for (i = 0; i < 1000000; i ++) { fprintf(fp, "%d", i ++); } fclose(fp); printf("%d", time(0) - t1); return 0; }
      While I didn't bother to bench the C and Java versions, I can tell you there are many ways to speed this up.

      Changing $i to a lexical gives you 10% more speed.

      By using the pragma use integer in a lexically scoped block around the code you get 310% more speed.

      It may not be a perfect number as I didn't not run the Java and C code, and there may be differences in implementation between my system and yours, but that would bring Perl down to 8 seconds which is a negligible difference.

      More importantly, runtime is only a fraction of what matters in a real software project so comparing numbers like this is a really just mental wanking. And the fact that you go to a perl site to do it just says to me that your instigating which is pretty dumb. Would you go to an ethnic neighborhood and start slandering the locals? Not if you weren't looking for trouble.
      #!/usr/bin/perl use Benchmark qw(cmpthese timethese); sub iterate { open(FILE, ">", "file.txt"); for ($i = 0; $i < 1000000; $i ++) { print FILE $i++; } close(FILE); } sub lex_iterate { open(FILE, ">", "file.txt"); for (my $i = 0; $i < 1000000; $i ++) { print FILE $i++; } close(FILE); } sub int_iterate { use integer; open(FILE, ">", "file.txt"); for (my $i = 0; $i < 1000000; $i ++) { print FILE $i++; } close(FILE); } my $results = timethese(5 , { iterate=>\&iterate , lex_iterate=>\&lex_ +iterate, int_iterate=>\&int_iterate } ); cmpthese($results); __END__ Benchmark: timing 5 iterations of int_iterate, iterate, lex_iterate... int_iterate: 4 wallclock secs ( 4.03 usr + 0.06 sys = 4.09 CPU) @ +1.22/s (n=5) iterate: 17 wallclock secs (16.70 usr + 0.07 sys = 16.77 CPU) @ 0 +.30/s (n=5) lex_iterate: 15 wallclock secs (15.20 usr + 0.08 sys = 15.28 CPU) @ +0.33/s (n=5) s/iter iterate lex_iterate int_iterate iterate 3.35 -- -9% -76% lex_iterate 3.06 10% -- -73% int_iterate 0.818 310% 2


      "To be civilized is to deny one's nature."
        Good one, man. my $i does speed it up, now the ratio become perl:java:c = 27:7:5.

        But use integer does not seem to affect the result, and it should not affect the result on a 32 bit machine, when integers are less than 10^6.

        I also tried 0..1,000,000 as one post suggested, it slows down the whole thing.

        I then became interested in the difference between your benchmark and my result. (I didn't suspect you cook the numbers and I don't, never, just as you should not suspect me.) So I ran your benchmark testing, and got:
        Benchmark: timing 5 iterations of int_iterate, iterate, lex_iterate... int_iterate: 131 wallclock secs (130.94 usr + 0.00 sys = 130.94 CPU) +@ 0.04/s (n=5) iterate: 172 wallclock secs (172.63 usr + 0.00 sys = 172.63 CPU) @ + 0.03/s ( n=5) lex_iterate: 137 wallclock secs (136.66 usr + 0.00 sys = 136.66 CPU) +@ 0.04/s (n=5) s/iter iterate lex_iterate int_iterate iterate 34.5 -- -21% -24% lex_iterate 27.3 26% -- -4% int_iterate 26.2 32% 4% --
        I would believe this is due to my small mem config as I said in another reply.

        But your data shows use integer speeds up the thing a lot, that part really confuses me. I don't think you are using 16 bit OS though. Did you compiled your perl yourself?

      The point that several people have already made is that speed is not the sole reason for choosing a language. If that were true everybody would be coding in assembler.

      If writing out those integers needs to be done faster than perl can do it, then you obviously use a language faster than perl.

      If it doesn't - I'll pick perl out of the above three languages since I only have to write and maintain 6 lines of code. Compared to C's 15 and Java's 19.

      Most of the time programmer efficiency, robustness, maintainability, portability, etc. are far more important than raw speed when it comes to language choice. Especially since many programs have their speed bound by external factors (disk, network, database, etc.) rather than by CPU.

      Speed in meaningless tasks like the above is not an issue for most people, most of the time.

        Read this post and all the follow ups, although I don't agree with adrianh word by word (and there is no need), those are good posts. Other posts in this sub-tree are also very interesting.

        Those posts actually made me think what is the major diffence between Perl OO and Java OO.

        Of course there are lots of differences, but at this moment, if you ask me to pick only one difference, I would say:
        1. In Java, everything is OO.
        2. In Perl, OO is a feature. This makes Perl more powerful than Java in a way.
        Agreed. There are lots of facts we need to consider. My original post was not focused on the speed thing, if you read it again, it is just one example, which was exggerated during the discussion/dispution.

        I definitely agree that all what you mentioned are very important to a project: efficiency (I believe you mean the efficiency of development), robustness, maintainability and portability etc.

        Let's narrow down the scope of our comparason, only talk about Java and perl. For all those what you mentioned, which I agreed, Java delivers them in a more graceful way.

        Let's again narrow down to maintainability. I don't quite agree with you, that Perl code is (easy) maintainable, on the contrary, There are couple of big things really hurt Perl's maintainability:
        1. Perl's scope is getting better, but still very prime, and hacked (this is one thing I really hate about Perl, Perl has too much hacked pacthes and concepts, it almost become a daily routine in Perl, why don't they think in a systematic way??? largely because Perl is building on a poorly defined foundation!)
        2. Perl's OO is hacked, which hurts modulization that is a main contributor to maintainability in all modern languages.
        3. perl is not a stable language, it is still RADICALLY (don't read this sentence without this word) evolving, and many times, that is done by hacking. There is a delimer for Perl, because the original design of this language is flawed, you have to either radically modify it, or to keep it familiar but with lots of hacking.
        4. The so called perlish style does not agree with maintainability at all, hope we at least agree with each other on this.
        I can go on and on, but back to the point, I don't agree that perl code is easily maintainable. That's not determined by Perl programmer's capability, it is really a built-in defect of Perl.

        This made lots of people feel difficult to consider Perl seriously in a project.
      that's pretty close to the code I did but my results were way different than yours - what version of perl are you using? On my eMac (G4 800Mhz 512M), the results are more like 4:2:1 and even those numbers are bogus. Utilizing the unix time function for better granularity, I get 4.132:2.474:0.643. And that proves ... absolutely nothing. Except maybe your perl installation is seriously broken or you're cooking the numbers. I've spent way too much time on this troll. I concede that C is faster than perl - Hoo--Feckin--Ray. I concede that Java, in this particular case is faster than perl - another Hoo-Feckin-Ray. I think your missing the well intentioned (and not so well intentioned) messages that a your conclusion is way to broad given your supporting arguments.

      I feel way too dirty now (and I think someone called me a coward earlier). Good night.


        ;-) I didn't cook the numbers, and I tested again, and got the same number. My perl is 5.8.0, and java is 1.4.0_01.

        But I am using my old PC/win32, which has only 32M RAM. My guess is that Perl requires way more memory, otherwise there would be lots of pageout.

        Anyway, even on your 512M, Perl is still slowER, but not that ugly ;-).

        My apology, Buddy, I take back my word that you are coward. Now I know you are a man serious with tech, not a fundamentalist.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://237665]
and the questions are moot...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (7)
As of 2017-02-21 20:10 GMT
Find Nodes?
    Voting Booth?
    Before electricity was invented, what was the Electric Eel called?

    Results (318 votes). Check out past polls.