Perl is currently un-ranked in the Mandelbrot Alioth category
Not true.
The existing mandelbrot Perl program gives the correct result with USE_ITHREADS.
http://benchmarksgame.alioth.debian.org/u64q/program.php?test=mandelbrot&lang=perl&id=1
I think RPerl is an important piece of work and as this grant request is the smallest of the four, it is the most worthy of approval.
I do not think this project is worth the money. RPerl is an extremely limited and non-idiomatic subset of perl that I do not believe it to be worthwhile. It's a poor substitute for C/XS with a syntax of poor Perl. It's effectively still another language to learn, and not necessarily an easier one than C/XS.
Anonymous:
I believe you are confused. The link you have provided does not, in any way, show that the Perl implementation of Mandelbrot is either functional or ranked on Alioth, because it is neither.
The only Alioth Benchmarks Game link which shows if Mandelbrot is functional and ranked is the same I have already provided in my proposal above:
http://benchmarksgame.alioth.debian.org/u32/performance.php?test=mandelbrot
The label next to "Perl" at the above link clearly states "Failed", which simply means the existing implementation of Mandelbrot using pure Perl fails on Alioth's servers for some unknown reason.
Unfortunately, Alioth Benchmarks Games is a closed platform, so we can't easily fix their bugs. Either way, this TPF grant proposal does not rely on Alioth's platform or the pure Perl Mandelbrot code at all. We are writing our own RPerl versions of Mandelbrot and the other benchmark applications.
(Also, Alioth Benchmark Games has very recently redesigned their website, so it is now seemingly impossible to find the actual rankings by clicking through the website links, you must use the existing links I have already provided in this grant proposal and elsewhere.)
Ed Avis,
Thank you for your support and vote of confidence!
You have my personal pledge to continue working indefinitely to make RPerl a success and help build the global Perl community.
Perling,
~ Will the Chill
Mr. Timmermans,
Thank you for your interest in the RPerl optimizing compiler.
RPerl is specifically designed to serve as a more-effective-and-efficient replacement for XS, SWIG, Inline::C, and Inline::CPP.
Like RPython, the "R" in RPerl specifically and explicitly stands for "Restricted", in that we openly and purposefully restrict the parts of pure Perl 5 which contribute to slowness (high-magic).
RPerl currently supports a low-magic subset of the Perl 5 language, and code compiled using RPerl can be seamlessly called and run directly from high-magic interpreted pure Perl code. Future versions of RPerl will support medium-magic Perl 5 code, and eventually we will support all of Perl 5 high-magic code. RPerl is an early-stage project compared to Perl 5 core, please be patient with us, it took >28 years for Perl to get here, it will take a few more to fix the problems with slow Perl 5.
Now to the meat of the discussion: your three main arguments are critically flawed and ultimately false.
First, RPerl is not "non-idiomatic", in fact I have made sure to make RPerl as idiomatic as possible within our constraints by working closely from the very beginning with several prominent Perl developers including mst, bulk88, Reini Urban, etc. When you call RPerl non-idiomatic, what you really mean is "I'm mad that my personal favorite kinds of high magic are disabled". This is a natural reaction, the same experienced by most professional Perl programmers the first time they investigate RPerl. Remember, low-magic code compiled using RPerl becomes super fast, and can be called seamlessly from within your existing high-magic Perl code without the high-magic code even knowing (or caring) that it is calling fast RPerl instead of normal slow Perl. You don't have to give up any of your beloved (albeit slow) high-magic code to benefit from new super-fast RPerl code. You can and will enjoy the best of both worlds!
Second, RPerl is not a "poor substitute for C/XS", it is a clearly-intended full replacement for C/XS! While there may still be some very-low-level binary-bit-twiddling features of XS which are not yet implemented in RPerl, this will change as RPerl continues to be developed. Soon there will be no reason at all for anyone to write Perl-compatible code directly using C or XS ever again. Why? Because RPerl generates the XS for you. (RPerl generates C++, which is fed through Inline::CPP to generate XS, which is fed through GCC to generate fast binaries.)
Third, and perhaps most alarmingly incorrect, is your claim that RPerl is "not necessarily easier to learn than C/XS". RPerl is to C/XS as C is to assembly. Anyone who claims that it is easier to program in assembly than C is either crazy, ignorant, or an old-school assembly programmer with a vested interest in keeping their old assembly $clients and/or a deep-seated fear of learning a new, better language. Everyone knows that, in nearly ever practical case, it is far, far better to program in C than in assembly. Smart programmers (or even just non-dumb programmers) let C generate their assembly code for them. The exact same arguments apply to RPerl vs XS. One line of readable-and-grokkable RPerl code is equivalent to perhaps dozens of lines of very-difficult-to-understand-and-maintain XS code. Smart Perl programmers let RPerl generate their XS code for them.
Don't be afraid of change.
RPerl is the future, and the future is better than the past.
Perling,
~ Will the Chill