07:41 FROGGS joined 08:35 zakharyas joined 09:27 kjs_ joined 09:37 rurban joined 10:13 kjs_ joined 13:50 btyler joined 14:10 rurban joined 17:31 FROGGS joined 18:01 tgt joined 18:21 kjs_ joined 18:33 dalek joined, FROGGS_ joined 18:42 rurban joined 19:46 zakharyas joined
dalek arVM: 786d0b8 | jnthn++ | src/platform/threads.h:
Revert "Quiet pthread_yield() warnings."

This reverts commit 0194409f7599850d73b8861cd26d2fe9b9f7f85b, which got rid of a warning on some platforms at the expense of breaking the build on others.		 20:13
jnthn If anybody fancies figuring out the right way to fix this, that'd be helpful :)
dalek arVM: bccbeac | jnthn++ | docs/6model-parametric-extensions.markdown:
Start documenting the parametric 6model design.
 20:16
arVM: 3bcab71 | jnthn++ | / (6 files):
Stub parametricity-related ops.

Fix a bunch of places real NULL escaped.
As of a while ago, the VM's null sentinel should be used. This fixes various ways to end up with a SEGV due to a null pointer.
jnthn d'oh
But anyway, what's missed was:
Merge branch '6pe'
Comfortable enough with the overall design, after experimenting a
bit with it in NQP and Rakudo. So there's no need to do what remains
in a branch.
20:17 dalek joined 20:24 brrt joined
FROGGS_ \o/ 20:27
nwc10 All tests successful. 20:36
Result: PASS
(spectest)
jnthn phew :) 20:37
FROGGS_ just in case somebody thinks I am lazy: p6-XML-LibXML: 56 commits / 6,980 ++ / 1,349 -- 20:38
nwc10 jnthn: I think you deserve a beer. 20:39
jnthn The fridge is possessed.
Uh
The fridge possesses them.
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...
nwc10 wonders what sort of specialist you would need to get to exorcise Carlsberg
20:41 zakharyas joined, tgt joined
nwc10 jnthn: it was distracted by the thought of beer? 20:41
jnthn Maybe :)
TimToady nqp bump needed? 20:42
nwc10 quite possibly - I was testing master/master/nom
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.
TimToady aww
jnthn TimToady: I need to port it to Parrot, and the minimal serialization bits to JVM
TimToady: And then my 6pe-mop branch in Rakudo has some regressions due to tripping over a previous unresolved bug. 20:44
We'll probably get them all within a week or so, but not in time for the January monthly.
FROGGS_ that'd be tomorrow, right?
jnthn Right.; 20:45
The MoarVM branch is very low risk to merge, in so far as the things it adds are very isolated.
FROGGS_ yeah }ā¤
I guess I have to do a slidathon at the weekend :S 20:46
21:03 ilbot3 joined 21:07 zakharyas joined
dalek arVM: f8a07d4 | nicholas++ | src/6model/serialization.c:
Remove redundant call to varintsize() from write_array_int().

There's no need for write_array_int() to call varintsize() or expand_storage_if_needed() because the call it makes to write_varint_func() will do these checks as well.		 21:41
arVM: f1aeb7d | nicholas++ | src/6model/serialization.c:
A slightly simpler implementation of write_varint9().
arVM: c308312 | nicholas++ | src/6model/serialization.c:
Inline write_varint9() into its only caller, write_varint.

Update the comment describing MVM_serialization_write_varint(). c8ba587 | nicholas++ | src/6model/serialization.c: In read_array_int(), use MVM_serialization_read_varint() in place of two other calls.
This mirrors write_array_int(), which calls MVM_serialization_write_varint.
timotimo probably not an amazing time win, eh? :) 21:44
jnthn Well, didn't measure those but that final one I just did, 'cus it runs a load at startup
timotimo the one that got committed seconds before you wrote that? 21:49
but yeah, read_aray_int would very probably like to be fast
jnthn yes
timotimo OK
jnthn m: say 878062346 / 886463444
camelia rakudo-moar 20aa85: OUTPUTĀ«0.9905229053ā¤Ā»
jnthn Well, 1% less CPU instructions at startup from that... :) 21:50
timotimo mhm mhm
could just as well be noise?
but i'll take it :)
jnthn No
timotimo oh, CPU time would be more exact, eh?
jnthn Measured with callgrind
timotimo OK
jnthn Which, in theory, can tell me actual Irs. 21:51
timotimo oh, cpu *instructions*
could just as well be just cheap instructions :P
nwc10 1% fewer CPU instrcutions from what?
timotimo read_array_int
nwc10 er, from which one?
jnthn nwc10: Rakudo startup
With 0005 in the patch series 21:52
c8ba587
21:52 dlem joined, dlem left
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:52
timotimo i ... don't understand that last line 21:53
21:53 dlem joined
jnthn timotimo: Ages ago, nwc10++ sent me a bunch of patches for varint serialization. 21:53
I sat on them for ages, so now I get to apply them partially by hand... 21:54
timotimo oh?
oh!
jnthn Well, sent to perl6-compiler...
timotimo i thought nwc just did those patches
dlem jnthn: Regarding pthread_yield warnings - can you use sched_yield instead? 21:55
dlem is lurking :-) 21:56
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. 21:59
I wonder if there's anywhere that only has the latter, and not the former... 22:00
dlem Hmm, I wouldn't know, unfortunately. 22:02
dalek arVM: fa01e02 | nicholas++ | src/6model/serialization.c:
A simpler implementation of read_varint9().
jnthn That's another 10 million instructions less too.
nwc10 oh, gosh
jnthn nwc10++ 22:03
The win makes juggling the patches worthwhile :)
nwc10 although if they aren't cache missees, does it matter that much?
jnthn Well, cache misses are expensiver, but 10 million instructions aren't free either. 22:05
22:09 travis-ci joined
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.org/MoarVM/MoarVM/builds/47843994 github.com/MoarVM/MoarVM/compare/8...ba587399ab
22:09 travis-ci left
jnthn ?? 22:14
nwc10 yes, confused too
worked on "my" machine
jnthn Other patches get it down to 854,696,557 22:17
m: say 854696557 / 886463444 22:18
camelia rakudo-moar 20aa85: OUTPUTĀ«0.9641644704ā¤Ā»
jnthn That's more than 3% less CPU instructions at startup.
nwc10++
nwc10 gosh, I had no idea it would do *that*
dalek arVM: 45a459f | nicholas++ | src/6model/serialization.c:
Inline read_varint9() into its only caller, read_varint_func().
arVM: c7ca2ab | nicholas++ | src/6model/serialization.c:
Inline assert_can_read_varint() into read_varint_func()

To work at all, assert_can_read_varint() had to duplicate the variable length decode logic. Really we only want that logic in one place, so it's simpler to move the buffer bounds check inside the reader function itself.
arVM: befcddf | nicholas++ | src/6model/serialization.c:
Slight simplification possible in read_varint_func()

ChangeLog for 2015.01.
nwc10 I just could see a way to write simpler code to get the same job done 22:19
jnthn :) 22:20
callgrind tells some interesting things 22:22
5,942,340 ???:rpo_idx [/home/jnthn/dev/rakudo/nqp/MoarVM/install/lib/libmoar.so] 22:23
That's an interesting one, for example
nwc10 what does that mean? 22:24
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
I'd not have guessed that.
(It's part of the SSA transform in spesh)
Anyway, not going to do it now, but we can just annotate the nodes with their index rather than re-computing it. 22:26
dlem remembers the time when 6 million instructions would take *a long time* to run... 22:29
jnthn can only remember so far back :)
First machine I know the processor speed of that I used was 25MHz 22:30
But I know I programmed on a slower one before that, using a BASIC interpreter too :)
dlem My introduction to computers was the C64 - approximately 1MHz :-)
nwc10 First machine that I can remmeber was 3.5MHz
that I can remember the figure for that is
not first machine I used 22:31
(can't remebmer the clock speed for a ZX81)
jnthn is clearly the (relative) baby here :)
nwc10 but the spectrum still works (tested about a year ago)
dlem :-D
nwc10 the ZX81 was not mine 22:32
jnthn Our startup time is muchly spent on serialization and, curiously, binding symbols into hashes.
Well, deserialization
And malloc.
nwc10 how much of (de)serialisation is copying data?
and, particularly, copying data that it might be possible to use in-place?
(that may not be an easy question to answer) 22:33
I might be rambling off in completely the wrong direction
jnthn Not easy generally, because we're reconstructing an object graph
nwc10 but I wondered if the format of things in the serialised file should be either 22:34
1) stored in a way that can be used directly without copying
or
2) if it needs copying, stored in the most space effient way that is still quick to unpack
but that's cheap for me to say.
jnthn Well, the varint stuff is about 2. 22:36
There may well be more things in that direction.
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
travis-ci MoarVM build passed. Nicholas Clark 'Slight simplification possible in read_varint_func() 22:37
travis-ci.org/MoarVM/MoarVM/builds/47847730 github.com/MoarVM/MoarVM/compare/f...fcddfc7c9a
22:37 travis-ci left
nwc10 when I was experimenting with fakecutables, there was a lot of repetative looking data in the dumped out files 22:37
"1" might be things like string constants
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
(looked like 0, value, 0, value, 0, value)
jnthn Hmm
nwc10 and didn't have time to stop and get sidetracked, if I wanted to get the fakecutable proof/prototype done
jnthn Aye. Well, another thing for somebody to look at sometime :) 22:39
nwc10 use more 'somebodies'
my trainee minion is only just 1, and whist enthusiastic, isn't very useful yet for this sort of task.
jnthn :)
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:41
aha yes. 22:42
All tests successful.
that's what I was waitingfor
dlem Keep up the good work, jnthn++ and nwc10++
nwc10 but that's not necessarily exciting, as it was the machine on which the patches were first tested
jnthn Doing a Windows build/test run now
I'll cut the relesae tomorrow 22:46
22:50 kjs_ joined
jnthn This'll be our 12th release :)
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... :) 23:25

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!