We have received the following grant application "RPerl Alioth Benchmarks, Part 2". Please leave feedback in the comments field by September 27th, 2015. If your comment does not appear in 24 hours, contact me at tpf-grants-secretary at perl-foundation.org. As we have four proposals on RPerl this time, please use RPerl User Documentation proposal if your comment is about RPerl in general and not specific to this proposal.
Name:
Will Braswell
Amount Requested:
USD 1,200
RPerl v1.1 has been released with a working N-body benchmark, as promised. Thanks to RPerl, we are now able to run N-body at the speed of C++, which was claimed by many in the Perl community to be impossible. This grant proposal is to create 2 additional Alioth benchmark applications.
Alioth is the premier language benchmarking website, and Perl is ranked at-or- near the bottom of several different benchmark applications.
http://benchmarksgame.alioth.debian.org/u32/performance.php?test=nbody
Many members of the general public will be turned away from Perl adoption by the terrible ranking of Perl among other programming languages. The N-body benchmark is 1 step forward, now we need to take 2 more.
The Perl community will benefit by a dramatically more positive public language ranking, and (hopefully) an increase in new Perl users as a result.
Deliverables for this grant proposal are:
I've already written 1 of the Alioth benchmark applications, a solar system simulator called N-body, comprised of 3 main files:
https://github.com/wbraswell/physicsperl/blob/master/lib/PhysicsPerl/Astro/System.pm https://github.com/wbraswell/physicsperl/blob/master/lib/PhysicsPerl/Astro/Body.pm https://github.com/wbraswell/physicsperl/blob/master/script/nbody.perl-3.pl
Using the new RPerl optimizing compiler, we decrease the runtime from thousands of seconds to a mere 13 seconds, which achieves the much-coveted speed of C++, and reverses the fortunes of Perl all the way from the bottom of the ranking heap to the top, along with perennial fastest-languages C, C++, and Fortran.
I've already created an empty stub file for the Mandelbrot application: https://github.com/wbraswell/rperl/blob/master/lib/RPerl/Algorithm/Fractal/Mandelbrot.pm
Perl is currently un-ranked in the Mandelbrot Alioth category: http://benchmarksgame.alioth.debian.org/u32/performance.php?test=mandelbrot
In addition to Mandelbrot, I will implement 1 other Alioth benchmark application, to be chosen by TPF or delegated to the Perl community for a vote of some kind. The only exception is the regex-dna application, because RPerl does not currently support regular expressions, and the Perl regular expression engine is already a separate computational entity from the main Perl language.
1a. Copy file template contents into empty stub file
1b. Study existing Alioth Mandelbrot source code
1c. Create new RPerl code to implement Mandelbrot calculations
1d. Create new RPerl code to save and/or display Mandelbrot image
2a. Copy file template contents into as-yet-nonexistent stub file
2b. Study existing Alioth source code for chosen application
2c. Create new RPerl code to implement chosen application
2d. Create new RPerl code to save and/or output application data if necessary
I will begin work immediately upon granting.
I expect work to take approximately 30 to 60 days.
I will release a new version of RPerl to CPAN with support for the benchmarks.
I will release the benchmarks to CPAN, if not wholly contained with RPerl.
I am the creator and lead developer of RPerl.
I've spent the last 32 months working on RPerl without the support of TPF.
I would like that to change now.
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: http://benchmarksgame.alioth.debian.org/
Mr. Hukins,
Thank you for your interest in RPerl!
To answer your concern:
1. IMPORTANCE OF ALIOTH
Currently, the Alioth Benchmark website is the #1 ranked Google result for computer language performance benchmarks:
https://www.google.com/?gws_rd=ssl#q=language+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.
2. COMMON USES OF PERL
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.
3. IMPORTANCE OF BENCHMARK ALGORITHMS
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.
4. NON-SCIENTIFIC RPERL BENCHMARKS
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?