Good Monday to you!
As I predicted in last week’s post, this week’s tuits have mostly gone into making MoarVM “moar awesome”:
- my untested varint serialization/deserialization code, which helped reduce the size for pretty much every integer that was serialized, turned out to be shoddy, so nwc10 made some tests and wrote the corresponding fixes, such that pre-compiled modules that have big-ish integer numbers in them don’t blow up in strange ways any more
- in the same vein, we figured out that we were mistakenly using doubles for the nqp::radix operation that is in charge of parsing integers into integers. now it returns an array of integers, which doesn’t have any precision problems any more. We have JimmyZ to thank for that
- jnthn has started and finished the I/O refactor, which also quickly led to client sockets, then server sockets. Panda can now get its project list off the ‘net on MoarVM
- In addition, there was an STable Reposession related bug that was fixed yesterday and now panda is almost ready! Just some test failures or something left ;)
- I’ve merged in my experiments with python plugins to gdb, resulting in a pretty-printer for MVMString while debugging as well as a nursery and gen2 analysis command that will show what Reprs appear how often and things like that. It also shows how fragmented the pages of the gen2 are. Using that, I found a way to reduce the startup memory usage by about 2 megabytes. Hopefully I’ll be able to push that a lot further in the future!
- small boxed integers between 0 and 15 (inclusive) are now cached, since they were overwhelmingly common in the nursery and gen2.
In other news, raydiak and smls have put in some work to make doc.perl6.org prettier. It’ll get even prettier in the future! And there’s a website for moarvm now, too. We mostly needed that to prevent people from accidentally downloading the tarballs from github, which unfortunately don’t contain some of the 3rdparty code.
Arnsholt has almost finished NativeCall for the JVM, the only thing missing now is the nqp::nativecallrefresh op which is needed to force a re-read of C-level memory to flush out some stale caches sometimes.
Spectest wise, moar has gained 0.1% on the jvm implementation, but that’s the only notable change.
What’s cooking this week?
I just turned my attention to syntax highlighting, IDE support, tooling etc. Turns out the description language Kate uses is pretty decent and is supported by QtCreator. QtCreator itself is apparently a thoroughly plugin-driven IDE. Since I’m somewhat comfortable with C++ and Qt, I may be spending some time building support for Perl6 into QtCreator. The syntax highlighting part, however, is now hoelzro’s job, as he’s already experienced :)
I’ve got a little bit of work on the JVM interop code-gen that’s not polished enough to be merged yet. In addition to that, I’m trying to build an optimization for NQP that would help inline some blocks, reduce code size and shorten object lifetimes hopefully.
Unfortunately I haven’t paid enough attention to my fellow devs this week, so I don’t know what other cool projects are in the pipeline — I blame being sick this week — but I’ve come up with a different section to make up for the gap:
How can I get involved?
I’m meaning to have a section like this often-ish. Maybe not every week, but hopefully at least once a month. Here I’d like to highlight some “low hanging fruit” that potentially anyone could pick up and get a feel for Perl 6 Development:
- If you know some C, you could have a look at some of the outstanding inefficiencies in MoarVM:
- Strings are currently forced to use 32bits per codepoint even if they could fit into 8bits per codepoint. The reason for that is the hash implementation we use. It doesn’t have a way to differentiate between 32bit/codepoint strings and 8bit/codepoint strings, so the same actual string can have two hashes, which messes up very early during compilation of NQP.
- Looking at the strings found in the nursery, the empty string comes up surprisingly often. Maybe a boxed empty string could be cached somewhere. Also, maybe P6str needs to learn how to share MVMString?
- Since I’m already talking about strings so much, if you’re interested in that topic, you can have a look at the implementation of “ropes”, that is “a string made up of a tree of string parts”. There’s a possibly wrong implementation of rope pretty-printing in moar-gdb.py, which you could test & improve.
- There’s an op called “nqp::locallifetime” that causes registers that hold locals to be freed early if the code-gen already knows they won’t be needed any more. MoarVM currently just no-ops. Could be relatively easy to implement, since the “freeing up locals” code already exists for leaving Blocks and Stmt nodes.
- We don’t have terribly much stuff that uses sockets yet. I’d almost call them untested (except for the spectests). So if you’re interested in some protocol, why not whip up an implementation, see how well the sockets hold up? They now work on all three of our backends.
- If you’re interested in learning how the code-gen works in nqp, you can implement loop labels on JVM and Moar, or take the parrot implementation of loop labels on NQP and port it over to rakudo. You can find FROGGS on the irc and ask him questions
- the list of GSoC ideas for this year
I hope I could give you a nice overview of what happened in the last 7 days. Soon I’ll do my first Rakudo Compiler Release, so maybe the weekly changes article will be skipped (you could just read the changelog of the release) or it would be a bit shorter than usual and only point out the things that were done between thursday and sunday.
Have an appropriate amount of fun! :)