Changes during week 6 of 2014

Hey there,

it’s timotimo here to kick off this new blog project with an overview of the changes over the last 7 days:

Backwards-incompatible Changes

Rakudo now handles for loops at the statement statementlist level as “in sink context”. That means that you will no longer need to put a “1” or “Nil” at the end of the for loop’s body to conserve memory and there’s also no need to ensure that for loops at the end of functions get eagerly evaluated, rather than lazily or maybe not at all.

If you want to collect the results of a for loop now, you need to write a “do” before “for”.

In addition to that, we now have “lazy” and “eager” statement prefixes for loops.

“make” used to automatically put its arguments into item context. That no longer happens, so you may need to go through your code and either add .item everywhere or think about how you can make use of the new semantics to shorten your code some.

Performance Changes

On the JVM and MoarVM backends, the code-gen for loops is now a bit better, as it doesn’t need to hold results from the loop bodies any more.

Another change causing big performance wins for loops af all kinds and numeric code in general across all backends is turning comparisons on native integers into actual operations on native integers, whereas before they would convert both arguments to native double values before.

Where did all the Work go?

These changes don’t seem like much. That’s because I’ven’t started listing the MoarVM changes yet. And MoarVM is where most of the development time apparently went in that particular week. Here’s a few nice things that happened:

• Nicholas Clark continued his torture testing and revealed a bunch of missing write barriers, made Valgrind happier and also shrunk every MVMObject in existence by 8 bytes.
• jnthn held a talk at the FOSDEM where all examples (except for the “how to do parallel stuff with JVM” part) ran on MoarVM, including Rakudo::Debugger.
• jnthn helped me get started on a bunch of work to reduce the memory and cpu-time costs of Int objects in Rakudo. They used to hold a full big integer regardless of how small the value was. Now they can shrink significantly if the value can fit into 32 bits and a bunch of operations on them are fast-pathed for the case where both “big integers” are actually “small integers”.
• FROGGS and hoelzro worked on openpipe, thus making qx{…} and run() work

On the spectest side, 2 new tests were added. Niecza got 0.01% closer to the currently leading implementation, which is rakudo-jvm. rakudo-moar got 40 more passing tests and reached 99.51% of rakudo-jvm, an improvement of 0.13%. rakudo-parrot stayed at 99.72% of rakudo-jvm.

What’s cooking?

It’s easy to see, that a lot of time is currently being spent on our newest backend, MoarVM. Before I do the rakudo release for this month, jnthn wants to get the IO system rewritten/refactored. That should also lead to support for sockets. Hopefully most of the work will happen this coming week.

hoelzro has been going through the modules included in Rakudo Star to figure out what’s currently broken and what’s keeping us from doing an actual Rakudo Star release.

We are also currently working on allowing MoarVM to run panda, our module installer. The most obvious missing part is sockets, as getting the project list is one of the first things panda wants to do.

One thing I’m hoping to get done soon-ish is fixing (or at least finding out what’s wrong with) the rope support for strings in MoarVM. Currently the performance of concatenation is algorithmically pessimal.

Since this is my first attempt at doing this, I’d be especially thankful for any constructive criticism or feedback in general.