Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-01-21

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
07:41 FROGGS joined #moarvm
08:35 zakharyas joined #moarvm
09:27 kjs_ joined #moarvm
09:37 rurban joined #moarvm
10:13 kjs_ joined #moarvm
13:50 btyler joined #moarvm
14:10 rurban joined #moarvm
17:31 FROGGS joined #moarvm
18:01 tgt joined #moarvm
18:21 kjs_ joined #moarvm
18:33 dalek joined #moarvm
18:33 FROGGS_ joined #moarvm
18:42 rurban joined #moarvm
19:46 zakharyas joined #moarvm
20:13 dalek MoarVM: 786d0b8 | jnthn++ | src/platform/threads.h:
20:13 dalek MoarVM: Revert "Quiet pthread_yield() warnings."
20:13 dalek MoarVM:
20:13 dalek MoarVM: This reverts commit 0194409f7599850d73b8861cd26d2fe9b9f7f85b, which
20:13 dalek MoarVM: got rid of a warning on some platforms at the expense of breaking the
20:13 dalek MoarVM: build on others.
20:13 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/786d0b802a
20:13 jnthn If anybody fancies figuring out the right way to fix this, that'd be helpful :)
20:16 dalek MoarVM: bccbeac | jnthn++ | docs/6model-parametric-extensions.markdown:
20:16 dalek MoarVM: Start documenting the parametric 6model design.
20:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bccbeac0e6
20:16 dalek MoarVM: 3bcab71 | jnthn++ | / (6 files):
20:16 dalek MoarVM: Stub parametricity-related ops.
20:16 jnthn d'oh
20:16 jnthn But anyway, what's missed was:
20:16 jnthn Merge branch '6pe'
20:16 jnthn Comfortable enough with the overall design, after experimenting a
20:16 jnthn bit with it in NQP and Rakudo. So there's no need to do what remains
20:16 jnthn in a branch.
20:17 dalek joined #moarvm
20:24 brrt joined #moarvm
20:27 FROGGS_ \o/
20:36 nwc10 All tests successful.
20:36 nwc10 Result: PASS
20:36 nwc10 (spectest)
20:37 jnthn phew :)
20:38 FROGGS_ just in case somebody thinks I am lazy: p6-XML-LibXML: 56 commits / 6,980 ++ / 1,349 --
20:39 nwc10 jnthn: I think you deserve a beer.
20:39 jnthn The fridge is possessed.
20:39 jnthn Uh
20:39 jnthn The fridge possesses them.
20:40 nwc10 "The fridge is possessed" - if so, that would be a bad thing
20:40 jnthn yeah, I dunno what my head was doing there...
20:40 * nwc10 wonders what sort of specialist you would need to get to exorcise Carlsberg
20:41 zakharyas joined #moarvm
20:41 tgt joined #moarvm
20:41 nwc10 jnthn: it was distracted by the thought of beer?
20:41 jnthn Maybe :)
20:42 TimToady nqp bump needed?
20:42 nwc10 quite possibly - I was testing master/master/nom
20:43 TimToady and does that mean we get Str(Any) too?
20:43 jnthn TimToady: No, 6pe needs to stay in a branch in NQP for now.
20:43 TimToady aww
20:43 jnthn TimToady: I need to port it to Parrot, and the minimal serialization bits to JVM
20:44 jnthn TimToady: And then my 6pe-mop branch in Rakudo has some regressions due to tripping over a previous unresolved bug.
20:44 jnthn We'll probably get them all within a week or so, but not in time for the January monthly.
20:44 FROGGS_ that'd be tomorrow, right?
20:45 jnthn Right.;
20:45 jnthn The MoarVM branch is very low risk to merge, in so far as the things it adds are very isolated.
20:45 FROGGS_ yeah }␤
20:46 FROGGS_ I guess I have to do a slidathon at the weekend :S
20:51 dalek MoarVM: 35a8ee2 | jnthn++ | src/core/interp.c:
20:51 dalek MoarVM: Fix a bunch of places real NULL escaped.
20:51 dalek MoarVM:
20:51 dalek MoarVM: As of a while ago, the VM's null sentinel should be used. This fixes
20:51 dalek MoarVM: various ways to end up with a SEGV due to a null pointer.
20:51 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/35a8ee2f8f
21:03 ilbot3 joined #moarvm
21:03 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
21:07 zakharyas joined #moarvm
21:41 dalek MoarVM: f8a07d4 | nicholas++ | src/6model/serialization.c:
21:41 dalek MoarVM: Remove redundant call to varintsize() from write_array_int().
21:41 dalek MoarVM:
21:41 dalek MoarVM: There's no need for write_array_int() to call varintsize() or
21:41 dalek MoarVM: expand_storage_if_needed() because the call it makes to
21:41 dalek MoarVM: write_varint_func() will do these checks as well.
21:41 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f8a07d4c5d
21:41 dalek MoarVM: f1aeb7d | nicholas++ | src/6model/serialization.c:
21:41 dalek MoarVM: A slightly simpler implementation of write_varint9().
21:41 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f1aeb7d9e4
21:41 dalek MoarVM: c308312 | nicholas++ | src/6model/serialization.c:
21:41 dalek MoarVM: Inline write_varint9() into its only caller, write_varint.
21:41 dalek MoarVM:
21:41 dalek MoarVM: Update the comment describing MVM_serialization_write_varint().
21:44 timotimo probably not an amazing time win, eh? :)
21:48 dalek MoarVM: c8ba587 | nicholas++ | src/6model/serialization.c:
21:48 dalek MoarVM: In read_array_int(), use MVM_serialization_read_varint() in place of two other calls.
21:48 dalek MoarVM:
21:48 dalek MoarVM: This mirrors write_array_int(), which calls MVM_serialization_write_varint.
21:48 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c8ba587399
21:48 jnthn Well, didn't measure those but that final one I just did, 'cus it runs a load at startup
21:49 timotimo the one that got committed seconds before you wrote that?
21:49 timotimo but yeah, read_aray_int would very probably like to be fast
21:49 jnthn yes
21:49 timotimo OK
21:49 jnthn m: say 878062346 / 886463444
21:49 camelia rakudo-moar 20aa85: OUTPUT«0.9905229053␤»
21:50 jnthn Well, 1% less CPU instructions at startup from that... :)
21:50 timotimo mhm mhm
21:50 timotimo could just as well be noise?
21:50 timotimo but i'll take it :)
21:50 jnthn No
21:50 timotimo oh, CPU time would be more exact, eh?
21:50 jnthn Measured with callgrind
21:50 timotimo OK
21:51 jnthn Which, in theory, can tell me actual Irs.
21:51 timotimo oh, cpu *instructions*
21:51 timotimo could just as well be just cheap instructions :P
21:51 nwc10 1% fewer CPU instrcutions from what?
21:51 timotimo read_array_int
21:51 nwc10 er, from which one?
21:51 jnthn nwc10: Rakudo startup
21:52 jnthn With 0005 in the patch series
21:52 jnthn c8ba587
21:52 dlem joined #moarvm
21:52 dlem left #moarvm
21:52 jnthn These are taking a little applying but I'm hoping simpler code is not only better to maintain, but also faster or more optimizable :)
21:53 timotimo i ... don't understand that last line
21:53 dlem joined #moarvm
21:53 jnthn timotimo: Ages ago, nwc10++ sent me a bunch of patches for varint serialization.
21:54 jnthn I sat on them for ages, so now I get to apply them partially by hand...
21:54 timotimo oh?
21:54 timotimo oh!
21:54 jnthn Well, sent to perl6-compiler...
21:54 timotimo i thought nwc just did those patches
21:55 dlem jnthn: Regarding pthread_yield warnings - can you use sched_yield instead?
21:56 * dlem is lurking :-)
21:59 jnthn dlem: Good question. At the moment it looks for various things to be defined and uses sched_yield if they are, and then falls back to pthread_yield.
22:00 jnthn I wonder if there's anywhere that only has the latter, and not the former...
22:02 dlem Hmm, I wouldn't know, unfortunately.
22:02 dalek MoarVM: fa01e02 | nicholas++ | src/6model/serialization.c:
22:02 dalek MoarVM: A simpler implementation of read_varint9().
22:02 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fa01e0249b
22:02 jnthn That's another 10 million instructions less too.
22:02 nwc10 oh, gosh
22:03 jnthn nwc10++
22:03 jnthn The win makes juggling the patches worthwhile :)
22:03 nwc10 although if they aren't cache missees, does it matter that much?
22:05 jnthn Well, cache misses are expensiver, but 10 million instructions aren't free either.
22:09 travis-ci joined #moarvm
22:09 travis-ci MoarVM build failed. Nicholas Clark 'In read_array_int(), use MVM_serialization_read_varint() in place of two other calls.
22:09 travis-ci http://travis-ci.org/MoarVM/MoarVM/builds/47843994 https://github.com/MoarVM/MoarVM/compare/88e433c956e2...c8ba587399ab
22:09 travis-ci left #moarvm
22:14 jnthn ??
22:14 nwc10 yes, confused too
22:14 nwc10 worked on "my" machine
22:17 jnthn Other patches get it down to 854,696,557
22:18 jnthn m: say 854696557 / 886463444
22:18 camelia rakudo-moar 20aa85: OUTPUT«0.9641644704␤»
22:18 jnthn That's more than 3% less CPU instructions at startup.
22:18 jnthn nwc10++
22:18 nwc10 gosh, I had no idea it would do *that*
22:18 dalek MoarVM: 45a459f | nicholas++ | src/6model/serialization.c:
22:18 dalek MoarVM: Inline read_varint9() into its only caller, read_varint_func().
22:18 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/45a459fb66
22:18 dalek MoarVM: c7ca2ab | nicholas++ | src/6model/serialization.c:
22:18 dalek MoarVM: Inline assert_can_read_varint() into read_varint_func()
22:18 dalek MoarVM:
22:18 dalek MoarVM: To work at all, assert_can_read_varint() had to duplicate the variable length
22:18 dalek MoarVM: decode logic. Really we only want that logic in one place, so it's simpler to
22:18 dalek MoarVM: move the buffer bounds check inside the reader function itself.
22:18 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c7ca2ab36c
22:18 dalek MoarVM: befcddf | nicholas++ | src/6model/serialization.c:
22:18 dalek MoarVM: Slight simplification possible in read_varint_func()
22:19 nwc10 I just could see a way to write simpler code to get the same job done
22:20 jnthn :)
22:22 jnthn callgrind tells some interesting things
22:23 jnthn 5,942,340  ???:rpo_idx [/home/jnthn/dev/rakudo/nqp/MoarVM/install/lib/libmoar.so]
22:23 jnthn That's an interesting one, for example
22:24 nwc10 what does that mean?
22:25 jnthn We spend nearly 6 million instructions linear-scanning the reverse post-order sorted list of basic blocks to get the index of the one we're looking for
22:25 jnthn I'd not have guessed that.
22:25 jnthn (It's part of the SSA transform in spesh)
22:26 jnthn Anyway, not going to do it now, but we can just annotate the nodes with their index rather than re-computing it.
22:29 * dlem remembers the time when 6 million instructions would take *a long time* to run...
22:29 * jnthn can only remember so far back :)
22:30 jnthn First machine I know the processor speed of that I used was 25MHz
22:30 jnthn But I know I programmed on a slower one before that, using a BASIC interpreter too :)
22:30 dlem My introduction to computers was the C64 - approximately 1MHz :-)
22:30 nwc10 First machine that I can remmeber was 3.5MHz
22:30 nwc10 that I can remember the figure for that is
22:31 nwc10 not first machine I used
22:31 nwc10 (can't remebmer the clock speed for a ZX81)
22:31 * jnthn is clearly the (relative) baby here :)
22:31 nwc10 but the spectrum still works (tested about a year ago)
22:31 dlem :-D
22:32 nwc10 the ZX81 was not mine
22:32 jnthn Our startup time is muchly spent on serialization and, curiously, binding symbols into hashes.
22:32 jnthn Well, deserialization
22:32 jnthn And malloc.
22:32 nwc10 how much of (de)serialisation is copying data?
22:32 nwc10 and, particularly, copying data that it might be possible to use in-place?
22:33 nwc10 (that may not be an easy question to answer)
22:33 nwc10 I might be rambling off in completely the wrong direction
22:33 jnthn Not easy generally, because we're reconstructing an object graph
22:34 nwc10 but I wondered if the format of things in the serialised file should be either
22:34 nwc10 1) stored in a way that can be used directly without copying
22:34 nwc10 or
22:34 nwc10 2) if it needs copying, stored in the most space effient way that is still quick to unpack
22:34 nwc10 but that's cheap for me to say.
22:36 jnthn Well, the varint stuff is about 2.
22:36 jnthn There may well be more things in that direction.
22:36 jnthn 1 I struggle to see since it's not a self-contained object graph, but it's got references into objects from other compilation units.
22:37 travis-ci joined #moarvm
22:37 travis-ci MoarVM build passed. Nicholas Clark 'Slight simplification possible in read_varint_func()
22:37 travis-ci http://travis-ci.org/MoarVM/MoarVM/builds/47847730 https://github.com/MoarVM/MoarVM/compare/fa01e0249bed...befcddfc7c9a
22:37 travis-ci left #moarvm
22:37 nwc10 when I was experimenting with fakecutables, there was a lot of repetative looking data in the dumped out files
22:37 nwc10 "1" might be things like string constants
22:38 jnthn Yeah, that's potential to do better on those.
22:38 nwc10 but I had no idea what part of the moarvm file the repetative data was in
22:38 nwc10 (looked like 0, value, 0, value, 0, value)
22:38 jnthn Hmm
22:38 nwc10 and didn't have time to stop and get sidetracked, if I wanted to get the fakecutable proof/prototype done
22:39 jnthn Aye. Well, another thing for somebody to look at sometime :)
22:39 nwc10 use more 'somebodies'
22:39 nwc10 my trainee minion is only just 1, and whist enthusiastic, isn't very useful yet for this sort of task.
22:39 jnthn :)
22:41 nwc10 and, erk, might wake up in 7 hours, so probably I should brush my teeth and put the Internet back in its box
22:42 nwc10 aha yes.
22:42 nwc10 All tests successful.
22:42 nwc10 that's what I was waitingfor
22:42 dlem Keep up the good work, jnthn++ and nwc10++
22:42 nwc10 but that's not necessarily exciting, as it was the machine on which the patches were first tested
22:42 jnthn Doing a Windows build/test run now
22:46 jnthn I'll cut the relesae tomorrow
22:50 kjs_ joined #moarvm
23:15 dalek MoarVM: a19eb2a | jnthn++ | docs/ChangeLog:
23:15 dalek MoarVM: ChangeLog for 2015.01.
23:15 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a19eb2a05a
23:15 jnthn This'll be our 12th release :)
23:25 jnthn Things we didn't have a year ago: native call support, spesh (or inlining, OSR, and JIT), I/O that handled codepoints dangling over byte boundaries, most of the concurrency and async I/O stuff, rope-y strings, profiling... :)

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary