|
in reply to Teach him a lesson with facts
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;
}
|
Re(2): Lesson Taught
by shotgunefx (Parson) on Feb 23, 2003 at 01:30 UTC
|
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 first benchmark was from a linux 2.2 kernal running 5.6.0 with an Intel Celeron 400MHZ with 256MB.
On a ultrasparc 10 running linux 2.2 with 256 MB (5.6.1) I get similar results...
Benchmark: timing 5 iterations of int_iterate, iterate, lex_iterate...
int_iterate: 14 wallclock secs (14.19 usr + 0.12 sys = 14.31 CPU) @
+0.35/s (n=5)
iterate: 53 wallclock secs (52.45 usr + 0.15 sys = 52.60 CPU) @ 0
+.10/s (n=5)
lex_iterate: 47 wallclock secs (47.03 usr + 0.11 sys = 47.14 CPU) @
+0.11/s (n=5)
s/iter iterate lex_iterate int_iterate
iterate 10.5 -- -10% -73%
lex_iterate 9.43 12% -- -70%
int_iterate 2.86 268% 229% --
Regardless... what does this actually mean? Not much. The iteration test isn't usually what the problem is. Usually it's all the stuff in-between that is the bottleneck and how fast the turn-around time is. It to me is a useless metric... (unless you're writing a video driver or such.) I think it's a case of not seeing the forest through the trees. If I was making a renderer or such that needed low-level speed I would just use XS or Inline, but the biggest thing for me is, how quick can I get a job done and how quick can I implement changes and to me Perl fits the bill perfectly.
-Lee
"To be civilized is to deny one's nature." | [reply]
[d/l] |
|
|
|
|
| |
|
Take back my comment on "use integer", I confused it with bigint.
This might have something to do with our hardware difference, i.e. your machine may not have floating point hardware.
| [reply] |
Re^2: Teach him a lesson with facts
by adrianh (Chancellor) on Feb 23, 2003 at 01:07 UTC
|
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] |
|
|
I would be so worried if anybody agreed with me word for word - I spend so much time talking nonsense :-)
Those posts actually made me think what is the major diffence between Perl OO and Java OO.
Interesting question. For me the major differences would be:
- Perl supports multiple-inheritance of implementation.
- Java supports private methods and attributes as native language features.
The static vs dynamic typing also raises issues that affect OO. For example, in Perl we can trivially make containers for any object. In Java this is harder. The addition of generic classes (or whatever they're calling them) in the next Java version should make this a lot easier tho'.
1. In Java, everything is OO
Depends on your definition of everything ;-) It has a bunch of types included for efficiency reasons that aren't "objects". This can mean tedious transformations of ints to Integers, booleans to Booleans, etc.
| [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] |
|
|
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!)
Some examples please. Perl is pretty consistant in it's structure in my opinion, certainly not radicallly inconsistant compared to other languages. The lack of a defined foundation can be considered an advantage. Perl shamelessly steals interesting things from other languages. Perl6 is carrying on this tradition. I far prefer useful functionality to theoretical purity.
Perl's OO is hacked, which hurts modulization that is a main contributor to maintainability in all modern languages.
This is arguable. It lacks useful things like direct support for private methods/attributes. However, these can be implemented using other language features. It's rarely an issue in real world code in my experience.
Perl's OO also gives you a lot of flexibility in your OO models - witness things like Class::Delegation and Class::Contract.
You can make arguments about Java's OO too (lack of generic classes, lack of multiple implementation inheritance, non-OO base types, etc.).
Again, these are arguable points (well, except for generic classes - not having those was insane and will be fixed in the next version :-) There are good reasons for non-OO base types and interfaces - but there are also disadvantages.
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
Completely disagree. Perl has been remarkably stable. I've still got perl4 scripts running unchanged in perl 5.8. It has certainly evolved, but it's kept compatability to a remarkable degree.
Java has gone through a lot of changes too since it was first released and is still having major features added (witness the proposed addition of generic classes to the next version.) I've had people working on projects where they have had to completely gut elements due to changes in the "standard" libraries :-)
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.
Again, I beg to differ ;-)
Its language independent. I've seen a lot of terrible perl code. I have also seen a lot of terrible C, C++, Java, insert-language-of-choice code. I've seen great perl code. I've also seen great C++, C, even assembler. Bad programmers write bad code. Period.
Now, you can make an argument that it is easier to write bad code in perl than it is in some other languages. Personally I'm undecided on that issue. However, in my opinion, even if this is true it is part of the price you pay in having a flexible language that enables a good programmer to produce good code in a timely manner.
This is why many people can and do use perl for serious commercial projects.
I've not chosen to use perl for fun (well, not just for fun :-). Fun doesn't pay my rent.
I've used it because it's a useful language. I've used it because people pay me to use it. Whether that be because they have existing perl code that is doing its job very well, or because it is easier (aka cheaper) to develop a solution in perl than any other language. I've used it because some CPAN modules cut development time to almost nothing compared to Java/C++/whatever (try an API with multiple-database support as good as DBI in another language).
I don't think perl is a silver bullet. I don't use it for everything. I don't recommend it for everything. I've even regretted using it on occasion. The same applies to every other language. There is no silver bullet.
You use the right tool for the right job. Perl can be that tool a great deal of the time.
| [reply] |
|
|
|
|
why don't they think in a systematic way???
Perl is a very practical language. There are plenty of times where, reading the docs, I've thought "why did they do it that way?" Then when I got to actually using the thing, it suddenly saw that doing it that specific way made coding a lot easier, and said "Ahh, that's why it works that way!"
So if it doesn't appear systematic, it's only because we don't live in a systematic world.
Perl's OO is hacked
Yes, it is. But did you also know that adding OO to Perl required defining precisely zero new syntax to the language? Which brings me to this:
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.
Not needing any new syntax for OO is a direct counterexample to this. By the time people started looking for OO to be added to Perl, closures, lexically scoped variables, packages, and referances were already in the language. These things comprise the building blocks of Perl OO (and probably a few other things I can't think of ATM). I think bless() had to be added, but that's a builtin subroutine, not new syntax.
The so called perlish style does not agree with maintainability at all, hope we at least agree with each other on this.
Are you talking about obfu/golf? If so, you're looking at the wrong place. Nobody is (should) be writing Perl that way for real programs. Look around this site, for instance. The community here hates it when people post code that isn't using strict and warnings--two ideas that generally get in the way of obfu/golf.
It is perfectly reasonable to write Perl code that looks just as pretty as a well-formatted Java code. All that is needed is a few rules about identation and spacing (I prefer K&R, myself). Regexen can be ugly, but they're equally ugly everywhere, as Java programmers are sure to (re)discover, since 1.4 now includes them. The /x modifier can help, if used properly.
----
Reinvent a rounder wheel.
Note: All code is untested, unless otherwise stated
| [reply]
[d/l] |
|
|
|
|
|
Re: Re: Teach him a lesson with facts
by derby (Abbot) on Feb 23, 2003 at 00:58 UTC
|
| [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] |
|
|
