Could it be that your Perl implementation simply sucked?
Of course it's possible, though I don't think I'm that bad a coder, and on this project I tried
really hard to program using best practices.
More likely, IMO, is that the Java implementation had the benefit of months, if not years, of
refinement, including optimization.
What in Perl was making it unusable?
The major culprit, by far, was dynamic method resolution.
(The implementation was highly OO.)
Simply saying Perl is slow sounds to me like "I didn't really try that hard".
I won't argue with that assertion, but I will point out that I didn't "simply say Perl is slow".
There's no doubt I could have found places for optimization.
But the only thing that would have made a major difference was to kill the OO, and that was
a sacrifice I wasn't willing to make.
I'm sorry, I don't have actual measurements to give you.
| [reply] |
Simply saying Perl is slow sounds to me like "I didn't really try that hard".
Sometimes it is, sometimes it isn't. I know (from profiling :-) that heavily numeric stuff like GAs and neural nets that Perl is just too darn slow. The interpreter overhead on tight loops and the overhead of dealing with scalars instead of raw integers just gets in the way.
Sometimes there's a nice Perl module sitting there I can use that drops down to something faster, but if there isn't I have to amble off into XS or Inline:: land.
Since I don't like C if I can avoid it I'm likely to go for Lisp, which I can usually tweak enough to be substantially faster than the equivalent Perl.
With any luck better compilation techniques in Parrot/Perl 6 will mean that I can stay in Perl more often on those few occasions when I need to write something that ends up CPU bound.
| [reply] |
Simply saying Perl is slow sounds to me like "I didn't really try that hard".
I thought the Perl motto was "Making easy problems easy and hard problems possible", not "Bang your head against a wall for a long time, since theoretically you might be able to make it fast enough". Sure, you could write your own customized perl compiler and you might be able to squeeze out a little more performance, but it's a matter of economics. Sometimes you bite the bullet and use a language where it is easier to get close the the maximum performance your hardware allows. Maybe you should try optimizing some of the Perl programs over at the shootout.
I'd really like to see a good perl implementation of the raytrace benchmark.
| [reply] |
Hi,
I have a small question... Those benchmarks, You need to implement the same algorithm or you can change the algorithm as long as the results are the same?
Sure, it is an idiotic question, diferent algorithms are not benchmarkable together.
But, for example, with the ackermann benchmark, there is after some analisis an small change very, very, very much more eficient, than the presented, based in a special case of that algorithm:
In Ack($m,$n), with $m<3, the result can be calculed using $m*$n+$m+1.
In this case, the result would be the same, but, even if you still need to use the recursive algorithm to find the results for $m>=3, it would reduce to an infime part the number of interactions taken to find the result.
| [reply]
[d/l]
[select] |
See the the faq...
We are trying to show the performance of various programming language implementations - so we ask that contributed programs not only give the correct result, but also use the same algorithm to calculate that result.
Doug Bagley used both same way (same algorithm) and same thing (same result) benchmarks - so in many cases the performance differences were simply better algorithms.
After hearing many arguments, it seems to me that we should think of same way (same algorithm) tests as benchmarks, and we should think of same thing (same result) tests as contests.
At present, we are only trying to show benchmarks.
| [reply] |