Grant Proposal: RPerl Alioth Benchmarks, Part 2

Category: Grants

Comments (8)

Improving speed has many applications to the use of perl, this is a vital project!

I've been reading up on RPerl for some days now, and mailing with Will Braswell, mostly about the documentation and examples. Last YAPC::NA in Salt lake City, I got a demo of what he was doing.

If, thanks to this grant, RPerl can show results like Will describes they will, it might get some more interest from core developers of both Perl 5 and Perl 6. If these sister languages could gain speed because of the techniques and methods used in RPerl, thatb would be more than just nice.

I think this proposal is promising and I hope TPF will fulfill this grant.

I know little about RPerl, so I welcome explanations of anything I have misunderstood. However, from the little I understand, this grant seems strange.

Generally, I encourage optimising code after it has become widely used, once the real-world performance limitations have become identified.

Optimising against arbitrary of benchmarks seems considerably less useful than optimising against production application code used at a large scale. Perl is commonly used as a data manipulation language, not for fractal generation.

Finally, as I understand it, RPerl only provides a subset of Perl 5's functionality. I don't see how improving RPerl's performance will help Perl's performance.

vote for!

Speeding up Alioth benchmarks will give RPerl as well as Perl much needed media attention. I vote for this.

esaym, why do you believe that? As far as I can tell media outlets almost never report on Alioth benchmarks.

Tom, by media I never meant "Google News" or "CNN". Perhaps a better term might have been "Social Media" (but I don't like that term either). Alioth is indeed a big deal:

Mr. Hukins,

Thank you for your interest in RPerl!

To answer your concern:


Currently, the Alioth Benchmark website is the #1 ranked Google result for computer language performance benchmarks:

Most people will look to Alioth when they want to know if a language is fast or slow, and Perl is one of the very slowest at nearly any task except regular expressions.

Thus, even from a solely marketing standpoint, having new benchmarks which show support for fast Perl are a critically important part of the future of our language.


You (correctly) state that Perl is not commonly used for computationally-intensive jobs, which is precisely due to the fact that Perl is far too slow to do so!

In other words, this argument is a self-fulfilling prophesy: "Perl doesn't need to be fast because Perl isn't currently fast". This is both illogical and a seriously problematic viewpoint within the Perl community.

Keeping Perl slow because it has always been slow is one of the reasons why use of Perl has declined dramatically over the past decade.


Most of the Alioth benchmark algorithms have some real-life applicability, or can be used as very helpful learning tools to further develop real-life applications.

Drawing fractal designs for fun is only 1 of 15 algorithms currently listed on the Alioth website.

Scientists always adopt the easiest, fastest language for building their code. These benchmark algorithms will help scientists start using RPerl sooner rather than later.

Thus, the use of the term "real-world" to refer to non-scientific algorithms is a misnomer. Science is very much a real-world use of fast software like RPerl.


In the near future, we have several options for using RPerl to speed up some non-scientific parts of Perl, such as the accessors/mutators of Moo and/or Moose.

This will come after we have implemented a few more of the scientific algorithms.


Does that answer your questions and concerns?

Sign in to add comment