|
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, ilya@iponweb.net
CTO IPonWEB (UK) Ltd
Quality Perl Programming and Unix Support
UK managed @ offshore prices - http://www.iponweb.net
Personal website - http://martynov.org
| [reply]
[d/l] |
|
|
I ++ just for the ascii graphic... :)
Update: ++ for being honest too... :)
----
Zak
Pluralitas non est ponenda sine neccesitate - mysql's philosphy
| [reply] |
|
|
| [reply] |
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. | [reply] |
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?
Because:
- 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 :-)
| [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in. |
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).
-derby | [reply] |
|
|
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).
| [reply]
[d/l]
[select] |
|
|
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.
| [reply] |
|
|
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
| [reply]
[d/l]
[select] |
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. -enlil
| [reply] |
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. | [reply] |
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.
| [reply] |
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
| [reply] |
Re: Teach him a lesson with facts
by Aristotle (Chancellor) on Feb 22, 2003 at 20:42 UTC
|
| [reply] |
Re: Teach him a lesson with facts
by Aristotle (Chancellor) on Feb 24, 2003 at 12:25 UTC
|
| [reply] |
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 java.io.*;
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;
}
| [reply]
[d/l] |
|
|
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
-Lee
"To be civilized is to deny one's nature." | [reply]
[d/l] |
|
|
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?
| [reply]
[d/l] |
|
|
|
|
|
|
|
|
|
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.
| [reply] |
|
|
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:
- In Java, everything is OO.
- In Perl, OO is a feature. This makes Perl more powerful than Java in a way.
| [reply] |
|
|
|
|
|
|
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:
- 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!)
- Perl's OO is hacked, which hurts modulization that is a main contributor to maintainability in all modern languages.
- 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.
- 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.
| [reply] |
|
|
|
|
|
|
|
|
|
|
|
| [reply] |
|
|
;-) 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.
| [reply] |