Greetings Fellow Perlites,

For St. Valentine's Day, we have released RPerl v1.6, with support for a number of new features:

- Two Dimensional Arrays
- Logical Ops
- Uncompile Mode
- Mandelbrot app via MathPerl

As always, the latest official release may be found on CPAN:

https://metacpan.org/release/RPerl

Thanks to our first grant from The Perl Foundation, we have released the first partial draft of the new book Learning RPerl, available on either CPAN or directly on the RPerl webs…

What’s in a name? that which we call a rose (William Shakespeare, Romeo & Juliet, Act II Scene ii)

I went to FOSDEM in Brussels this year as a representative of the Perl Foundation. As such I spent the weekend doing my best to be a good advocate of the Perl programming languages.

FOSDEM for those of you in gentle unawareness is probably the world's largest, free, Open Source event. It is held each year in Brussels, Belgium, and attracts speakers for hundreds of talks on dozens of projects,…

To me It seemed a particularly good FOSDEM for both for Perl5/6 and
*BSD or Tor stalls. I was stuck by the statistic that there were
about 500 speakers from many thousands of people so of the order of
one speaker per tens of attendees which is very high.

Videos are already starting to appear at

http://video.fosdem.org/2016/

On Saturday I started with Poettering and systemd which was a keynote
and perhaps a little disappointing…

I uncovered and fixed many 5.22 problems with cperl already, but in the last months I was busy to port the 3 compilers B::C, B::CC and B::Bytecode to 5.22.

As I said in my interview it's my belief that if all current p5p core committers would stop committing their bad code it would be actually be the best for the perl5 project. They weren't able to implemented any of the already properly designed features from perl6 in the last 12 years, and every feature they did implement is just so horrifibly bad, making our already bad code base, which led to reimplementation efforts of perl6/parrot with a better core, even worse. With cperl I can only undo a little, but when they start breaking the API and planned features in an incompatible way they should just stop.

Nevertheless, 5.22 added a significant improvement from outside, syber's monomorphic inline caching for method calls besides the internal improvement of multideref by Dave Mitchell.

Now to the problems I had to fix in the last months with that 5.22.0 release:

1. Father broke ByteLoader

cperl #75 perl-compiler

This is something I cannot fix in the compiler. I updated my perl patcher App::perlall with new --patches=Compiler patches to fix this, and cperl of course also has this fix.

I had to write a complicated probe mechanism for ByteLoader to check if the used perl5.22 version is already patched or not. Probing a to-be-built XS submodule is not that easy. A typical chicken and egg problem. I could use my already existing B::C::Flags helper config, which allows custom compiler settings. There I initialize the variable $B::C::Flags::have_byteloader with undef, and when the XS modules are all built I call a helper script to probe for a working ByteLoader, and patch $B::C::Flags::have_byteloader to 0 or 1. I can use this then in the tests to skip or run the bytecode tests. And I had to put this helper script into the hints directory to skip it from being installed. Messing with EUMM libscan() was too dirty for me.

The internal compiler op.c creates a new main or eval environment with newPROG(), setting the entry points PL_main_start and PL_main_root from the intermediate parsed PL_compcv. In the case of en empty source the parser always adds a final ; semicolon, which leads to an empty optree starting with OP_STUB.

But with commit 34b5495 for [perl #77452] the compiler now always adds a LINESEQ in front of the STUB, but the logic in newPROG for source filters which already setup PL_main_start and PL_main_root wasnot changed, which led to a broken ByteLoader.

This is an interesting commit as it added a lot of wrong comments about the inner working of this, but didn't update the logic.

The fix in cperl is here and for perlall here, and my perlbug report did not get through.

I can only guess that p5p blocked me again, because they didn't like me to call them incompetent. Blocking bug reports and fixes is worse than just incompetence, but I got used to that recently. They blocked my simple fix for the horrific double-readonly system, and they proudly announced last week some new optimization regarding faster arithmetic, but didn't have a look into my fast arithmetic optimizations which I wrote half a year ago, and which makes them look very bad in the end. Everybody applauded poor Dave for this "fantastic breakthrough". The guys are really that simple. Looking through my improvements would have wasted less time and would have improved it upstream by 30% not just 10%.

2. Dave couldn't implemented multideref access for the compiler

cperl #76 perl-compiler #341

Multideref merges sequential hash or array access into one compressed op. This is a pretty good compiler optimization, if the B design would not be so bad.

The upstream design of the new 5.22 B::UNOP_AUX::aux_list method deviates significantly from proper B design. aux_list requires the curcv to be provided, which is not trivial to do for a B module, and it needs this to resolve shared SVs beforehand. Requiring the curcv to resolve the padoffset is unneeded and does not help B and any of its clients. Clients need the padoffset and resolving it e.g. in B::Deparse is to be done in B as with all other threaded and shared SV accessing methods.

Thanksfully I can patch most of B bugs by myself, and don't have to fork it publicly into a worse name. B is already a good enough name, and I don't want to deviate from that, even if p5p consistently refused to maintain B properly in the last years. There was some short time a few years ago where I could work without a patched B, but this period only lasted very shortly, and none of my fixes were applied, while other new horrific mistakes made it in.

3. Missing HV::ENAMES api

perl-compiler commit ++

Stashes can be aliased to seperate namespaces, and the ENAMES API to access this names never made it into B, and thus never into a compiler. Namespaces aliases are rather seldom, so it caused not too much trouble, but now I added ENAMES and could hereby fix most of the remaining compiler limitations, even for 5.14.

4. Missing PADNAME B api

I explained that technically in my interview. Currently we limit the max name length of lexical variables to 60, because we statically allocate the buffers for them. It is not a practical problem, and I'll optimize that sooner or later to smaller static structs.

5. Fixed HEK assertions

HEK's (shared hash keys) are still dynamic, not static, but I could fix the remaining refcount issues at least.

The cperl code to support static HEKs is already there, but I still need to add compiler code and probes to support that.

6. Broken B::RV->FLAGS for GVOP_gv -> CVREF

5.22 has a wrong RV->FLAGS for a GVOP_gv pointing to a CVREF gv(cv ref:). It returns the flags for a GV (0x808009) where it should be just 0x801, a ROK RV. This is suddenly broken in 5.22 because it's a new optimization they did, and of course wrong.

cperl #63

I haven't fixed that yet in cperl, I just a workaround in the compiler with this patch

Overall we are very happy with the new 5.22 compiler, though we are not yet using the much more advanced cperl optimizations. The B::C optimizations alone lead to ~20% less memory, with cperl and its compiled readonly hashes for Config and warnings and its upcoming support for static GV/AV/CV/PAD/HEK layout it's much more dramatic. This will be a real COW (copy-on-write) mechanism then, being able to statically allocate readonly buffers, and copy it to the heap, when it's being changed. For the compiler we only need to ensure that static buffers are not freed, which is trivial with the added flag.

-m support for perlcc, compiling to modules, not single binaries is also improving. This can split various optimizations per module/.pm file, so we can use B::CC compiled modules or even rperl compiled modules, compile-times should go down from 20min to ~5min, with much faster smoker feedbacks, and pushing updates live is much faster, because they will be much smaller. The old compile times were 2 hours.

But since fixing B::C for 5.22 needed so much more time than expected I couldn't add most of the planned cperl optimizations for the upcoming cperl-5.22.2 release and B-C-1.53 release.

Actually I'm shocked when I've read this blog written in 4 months ago.

I'm shocked not only because many codes I've written is used with AnyEvent but also because I'm afraid it's a sign which perl5 world is beginning mess.

We love perl because it's expressive, because it's cpan and more importantly, because it's consistent. you can install a same perl in many OS and retrieve the same. But let's think, because perl5 has not a offical spec, what if there are m…

Greetings Perlites,

We're continuing our trend of success with...

THE RPERL CHALLENGE!!!

After watching the video linked above, you'll want to head over to Kickstarter:

http://tinyurl.com/RPerlKickstarter1

Thanks in advance for your financial support, it is critical to the future of RPerl's performance future!

Perling,
~ Will the Chill

Greetings, Perl Lovers!

I am proud to announce the launch of our next Kickstarter campaign.

We immediately reached our minimum of $1,701; now our goal is to reach $20K in the next 9 days. We can do it... WITH YOUR HELP!

STEP 1: Make a generous pledge.
STEP 2: Get your friends to match your pledge.
STEP 3: Get your boss to double your pledge.
STEP 4: Go back and increase your pledge.
STEP 5: PERL WILL BE THE FASTEST LANGUAGE EVER.

Thanks so …

Howdy Perl Lovers,

RPerl v1.1, codename 'Jupiter', has been released to CPAN!

Jupiter supports fully-automated compiling of the long-awaited N-body application software, which is a solar system simulator used by the Alioth Benchmark Game to rank programming languages by speed.

RPerl and the new ="https://github.com/wbraswell/ph…

Howdy Perlites,

After over 2.5 years of work, I'm very proud to (finally) announce the full release of RPerl v1.0 on CPAN!

Installation should now be as simple as:

$ cpan RPerl
OR
$ cpanm RPerl

For more information about install options, please see:

https://github.com/wbraswell/rperl/blob/master/INSTALL

As outlined in step 3 of the install notes file, we can now automatically compile our…

While being blocked from p5p I had to read a new outragious statement by a porter. Who is in reality not a porter like me, just some developer who happens to have no idea what he is talking about.

Re: OP_SIGNATURE

He struggles with his new super-op OP_SIGNATURE which is at second thought a better idea then the old way to assign lexical values from the call stack at the begin of subroutines, just that it cannot take the stack values, it has to go through an intermediate @_ copy, but that is just an implementation detail which can be optimized away, and goes then on like this:

Also, every op/optree related internals change now involves fixups to B and Deparse, so every change is that much more work.

If I could travel back in time and stop Malcolm B. writing B and friends, I would in an instant. Perl now would have been far, far better, and probably a lot more truly extensible than it is now.

The realisation that B (and B::C etc) were a failed experiment was one of the drivers of perl6. It's been an albatross round perl5's neck ever since.

Dear Dave, are you completely out of your mind?

I know that you all don't want to maintain your reflection API and AST. p5p was also not able to maintain B::C and the other 2 compilers, so I had to step up and fix it for them. Even if p5p is unwiling to fix the outstanding problems they create and is still doing more damage than good, B::C is a huge success story.

B::Generate, optimizer and types are not so easy to fix because there the damage done by p5p is too outragious that it can only be fixed in a forked version of perl. I still have to maintain patchsets in my perlall build suite (perlall build --patch=Compiler) to be able to create perls without those roadblocks. And to support windows, because p5p is not willing to export the needed API functions.

Nick Clark really claimed publicly that changing function bodies at run-time is too dangerous when used with concurrent threads. Let that be the problem of the optimizer, not yours. By further blocking dynamic optimizations B::Generate is worthless and type or profile based optimizations cannot be done. Do you have an idea why javascript, an even more dynamic language and worse language than perl could be optimized so much? Apparently not.

To the success

B::C passes the complete core testsuite. B::C compiled code is faster and smaller than uncompiled perl. Look at the B::CC and rperl benchmarks. We are close to v8 and in the next step we will be there.

B::C is successfully used in production by cPanel, which is in fact the largest and most successful company using perl. We just don't shout it out as loud as Booking.com, because we are privately held and we don't need to publish our numbers. Nevertheless cPanel is the facto one of the backbones of the internet, used by ca 70% of all webhosters worldwide, with compiled perl applications and its distribution based on CentOS.

We have to compile perl to have a low memory footprint for our daemons. They need to be smaller than apache and mysql at least, and they need to run on hosting VM's which are low on memory.

Even with p5p non-ability to come up with non-bloated versions of their releases, and their non-ability to come up with any improvements since 5.6, B::C is a huge success.

Dave and Nick, you are the real albatros around perl5's neck for years. Finally stop doing your destructive work, step back and let the people do the work who got a track record and have an idea what they are doing. You both got paid for years to work to improve perl5 and the results are hopeless. One year to fix eval in regex? My dear.

Still not a single feature written and discussed by p5p was ever successful, besides the trivial defined-or syntax. The only non-trivial improvement in the last years came from outside and was initially heavily critized and not understood. ("Why do we need another hash table implementation?") But will this lead eventually to an efficient implementation of classes, roles (mixins), polymorphism and types? Or a better runloop. For sure not. This is shot down since 2002, and everybody who was able to do that and was interested left p5p. Not about talking fixing the easy stuff like smartmatch, switch, given/when or even hash tables. You just gave up.

I have to do my work now behind closed doors.

Stop doing your destructive work, start listening to advice and maybe even implement a good feature or library. Like OP_MULTIDEREF which is nice. Even if it just tampers around the fact that the runloop is too big and slow.

Without B perl5 would have been more successful?

What a ridiculous statement. Inspecting the AST, the optree, how perl compiles its ops? Certainly totally outragious. Nobody would need that. You even refused to accept documentation for the optree. You are just bitching about your need for B::Deparse and B::Concise test updates. Who needs precise optree representations? It's just an implementation detail. The functionality needs to be tested not how it looks internally.

But maybe you'll eventually learn how the optree (i.e. the AST) looks like, when you are forced to update some B modules. I'll do the rest for you anyway for the parts you do not understand.

Realize that your work is looking worse than PHP.