2010 Grant Proposal: Perl Compiler
Sat, 06-Feb-2010 by
Alberto Simões
edit post
<![CDATA[
<h1>Perl Compiler</h1>
<dl>
<dt><strong>Name: Reini urban</strong></dt>
<dt><strong>Email: [hidden email]</strong></dt>
<dt><strong>Duration: Until March 2011</strong></dt>
<dt><strong>Amount Requested: € $1000 <em>(just for motivation)</em></strong></dt>
</dl>
<p>
</p>
<h2>Synopsis</h2>
<p>Fix most of the remaining perl compiler, i.e. B::C, B::CC, B::Bytecode bugs.</p>
<p>Improve documentation a bit.</p>
<p>Maintain the planned <strong>compiler.perl.org</strong> site.</p>
<h2>Benefits to the Perl Community</h2>
<p>A working compiler.</p>
<p>Faster startup time.</p>
<p>Optionally faster run-time if the B::CC optimizations work out as
expected.</p>
<p>parrot? I've worked with them. I gave up. Better a half-ass perl5
compiler now, than the ongoing ... with parrot/perl6.</p>
<p>
</p>
<h2>Deliverables</h2>
<p>Extend the testsuite reasonably - but less is more. The full author
tests for all tested perls on all platforms needs 2 days.</p>
<p>Fix the existing SKIPs and TODOs</p>
<p>Testsuite passing on my main platforms cygwin, MSWin32, debian5,
centos5, freebsd7, solaris10.</p>
<p>compiler.perl.org</p>
<p>More fun, less headaches</p>
<p>
</p>
<h2>Inch-stones</h2>
<p>I don't think I need this.</p>
<p>See below at <a href="#project_schedule">Project Schedule</a>. From now until end of March 2011,
the next surf-season.</p>
<p>
</p>
<h2>Project Details</h2>
<p>I successfully ported the abandoned compiler to 5.10 and blead and
fixed most of the old bugs, so that the tests pass now on most
platforms.</p>
<p>But there's more todo. Finding bugs cannot be detailled here. In the
core suite are some, in the top100 modules are some, the community
will come up with more. Some are known, some not yet. So far all
found bugs could be fixed within 1-2 days, sometimes they are just
hard to catch.</p>
<ol>
<li><strong>Adjust the perl core suite and find limitations (runperl issues) vs bugs</strong>
</li>
<li><strong>Check modules</strong>
</li>
<li><strong>Check user reports</strong>
</li>
<li><strong>Check weird platforms, compilers, programming tricks.</strong>
</li>
</ol>
<p>
</p>
<h3>CC bugs</h3>
<p>Well, some bugs are run-time limitations which will require run-time
solutions. The sortcv bug [CPAN #53536] is easily understood but hard
to fix. Will need at least 2 days concentration on it.</p>
<p>
</p>
<h3>Planned CC Optimizations</h3>
<p>Static initialization of readonly data: SVs, AVs, HVs.</p>
<p>-fcog for strings (copy on grow by using a custom destructor)</p>
<p>Fill in missing Opcodes flags for most optimisable ops. Maybe even automatically.</p>
<p>Check possible type declarations with Devel::TypeCheck, MooseX::Types,
attributes and such.</p>
<p>I've finished 50% of Malcom's Todo during the winter surf-holidays,
and fixed 90% of Malcom bugs in the last year so I'm confident.</p>
<p>I've already got a sponsor for my conference travel expenses. A tip:
They could be persuaded to sponsor this grant also :) <em>(cPanel)</em></p>
<p>
</p>
<h2>Project Schedule</h2>
<p>During summer-time I prefer surfing over coding to keep emotional
stability in the coorporate environment. Winter 2009-2010 was very
productive, because I got a kick by cPanel who needed it.</p>
<p>For the next coding season I might need further kicks, a mini-grant
like this might be enough.</p>
<p>2010: Find and fix all remaining bugs. I suspect there are still 5-6
major ones.</p>
<p>2010: Faster testsuite. Now: 8 min user - 40min author - 2 days all perls + plats.</p>
<p>Until March 2011: CC type and sub optimisations</p>
<p>Later (not part of this proposal)</p>
<p>Until 2012: CC unrolling => jit within perl (perl -j)</p>
<p>
</p>
<h2>Bio</h2>
<p>Reini Urban, living in Graz, Austria. Born 1963, pretty old, yes.</p>
<p>Born Lisper, but I've been writing perl programs since 1992 and
released my first module to CPAN in 1995, the perl5.hlp file for
Windows, created by some pod2rtf.pl. cygwin maintainer (perl, parrot,
postgresql, clisp, ...) for a couple of years, and several B::*
modules.</p>
<p>I work for a large HW+SW company (>2000 developers), 8-16 o'clock.</p>
<p>Since nobody is able to help me with the compiler it looks like I'm
alone. Hopefully this will change! I even had to write my own
Debugger. Yes, I'm aware of trucks. Surfing is not risky at
all. Bycycling is more dangerous.</p>
]]>
Comments (9)
Seriously WANT!
Pay the man...
If PHP can do it, so should Perl.
I'm all for improving the Perl compiler, but this grant request is kind of confusing. Are the deliverables really stretched out over the next two years? Why?
Given the small amount being requested, I'd prefer too see this narrowed down to a smaller set of inchstones that can be achieved in the near future.
PHP without string eval() (and other restrictions) can "do it"...
I'm guessing they're stretched out over two years only because the requester can envision his work that far ahead (and this labor of love is only a moonlighting endeavor, not fulltime $dayjob). It seems the requester wants the compensation as a psychological motivation from TPF's public backing/approval of his work, and not necessarily as something to offset/recover the actual opportunity cost of choosing to work on B::.
I should clarify that I am all for funding work on this project in general, I just don't think this grant is clear in what the funding is for.
Good idea. It would get Perl a formal commitment from Reini, more optimization and testing, fewer bugs, etc. Some concrete deliverables would strengthen the application. How about a goal like successfully compiling and running a good portion of a list of important Perl modules and applications?
perlcc has long been broken and it's awesome that someone's working on it. The fee Reini is asking for is obviously just a token amount. I don't think it's unreasonable that he doesn't give a detailed project schedule as long as it's understood that he simply continue doing the good work that he has been doing already.
To clarify the unusual time frame again:
I already stopped busy compiler development until next november. I rather concentrate on writing the jitter and rely on others reporting bugs.
Most of the deliverables are already in svn, e.g. but cutting down the testsuite, testing core and the top100 modules. But there are still 2-3 major bugs lurking, which need a good amount of full concentration > 2 days per bug.
And a lot of documentation is missing, so that others can understand it and help.
I wrote:
2010: Find and fix all remaining bugs. I suspect there are still 5-6 major ones.
2010: Faster testsuite. Now: 8 min user - 40min author - 2 days all perls + plats.
Until March 2011: CC type and sub optimisations
$1000 for fixing those until March 2011 seems fair to me.
Matthew Wilson: Our perl compiled eval works fine, in contrast to php. No issue for us. I fixed major eval issues after writing this proposal while visiting Frozen Perl 2010 in Minneapolis.
Martin Berends: I have now 4% failures on the top100 cpan modules on a good platform, but a lot of weird failures on the core testsuite. Unimplemented magic mostly, and failing xs stub and dl_init(). Bigger applications are expected to work end of this year. With workarounds even now.
I uploaded B-C-1.30 at March 6, 2011 with most of goals fulfilled in my little developer point of view.
See http://cpansearch.perl.org/src/RURBAN/B-C-1.31/Changes
full 5.14 support, full dynaload support, fixed half of the outstanding bugs.
But unfortunately the ability to dynaload modules caused some new code paths and bugs which I'm currently exploring.
CPAN Testers is red because I was overly optimistic.
Also darwin and MULTIPLICITY was not covered.
And the symbol walker needs to be rewritten, to improve dependency detection for the masses.
