Sure, you have to write more code, but Perl still hasn't stopped you from doing anything.

Could it be that your Perl implementation simply sucked? I've often found that I'm the one to blame (not the language) for my sucky software. :)

What was the limitation though? What in Perl was making it unusable? Was it that you had coded it yourself? Was the Java implementation already ready for you to use? I'm looking for specifics. What did the profiler show as the slow part?

I've had a lot of opportunities to improve the performance of Perl programs by orders of magnitude. Simply saying Perl is slow sounds to me like "I didn't really try that hard".

--
brian d foy <brian@stonehenge.com>

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.

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.

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.