00:42 BinGOs joined
[Coke] finds that once, somewhere, jonathan used the wrong email address in a commit. 00:45
00:51 dalek joined 00:59 dalek joined 01:12 BinGOs joined 01:37 dalek joined 02:26 BinGOs joined 04:45 ilbot3 joined 04:52 flussence joined 06:30 BinGOs joined
tadzik ah, doing releases, I see :) 06:58
07:09 vendethiel joined 08:07 domidumont joined 08:18 FROGGS joined, dalek joined 08:22 BinGOs joined 08:29 zakharyas joined 08:38 BinGOs joined 09:02 zakharyas joined 09:23 zakharyas joined 09:32 dalek joined 09:36 Ven joined 09:41 nebuchadnezzar joined 09:48 kjs_ joined 09:58 Ven joined 10:41 domidumont joined 10:42 flaviusb joined 11:18 zakharyas joined 12:09 ggoebel7 joined 12:22 Ven joined 12:24 domidumont joined 12:28 ShimmerFairy joined 12:31 Peter_R joined 13:01 domidumont joined 13:38 kjs_ joined 13:52 ShimmerFairy joined 14:03 ggoebel7 joined 14:26 domidumont joined 14:46 zakharyas joined 15:34 domidumont joined
timotimo on my JSON::Fast benchmark, self times are interesting: 11% Self on MVM_frame_dec_ref, 10% on MVM_interp_run, 8.23% on MVM_fixed_size_alloc, 5.11% on MVM_frame_acquire_ref, 4.74% on MVM_frame_invoke, 2.68% on MVM_frame_inc_ref_by_frame (with a few things in between) 15:55
15:57 ggoebel7 joined
timotimo with a check for num_user_threads == 0, the self gets down to 8.18% 16:00
(as reported by perf)
my naive attempt to implement MVM_frame_acquire_ref seems to not work :\ 16:07
i'll run a full spec test now.
16:09 brrt joined
timotimo i think it should be safe to do the checks there, as going from 0 to 1 user thread cannot happen while inside the non-threaded version of these operations 16:12
and the other direction would just mean that we accidentally do the checks with atomic ops at least once when not needed
could it be problematic if the threads somehow go from 1 to 0 to 1?
brrt good * #moarvm 16:16
timotimo heyo brrt! 16:17
brrt hey timotiom
timotimo
timotimo i'm starting to miss the ability to have perf show me disassembly of jitted frames :|
brrt my win10 download has disappeareed for some reason
timotimo :o
disappeared?!
brrt yeah, weird
why can't perf do that?
what would you need for it to do that? 16:18
timotimo i expect we need to export the perf map thingie that tells it where things start and end?
brrt hmmm
supposedly, yes
timotimo i should verify my claim before sending you off on a goose-chase! 16:19
brrt jit integration with external tooling would be a nice goal to have
timotimo on the other hand, i can just let the jit export the .o files, eh?
brrt yeah, but they won't be ELFs
timotimo but that won't give me per-instruction timings
as long as i can dump the assembly, that'll help a little bit
but they don't show what source bytecode what assembly op comes from, eh?
brrt no, they don't 16:20
i can usually tell with the jit log in hand
but it's not automated
timotimo bleh. lowlevel/lock.t and promise/start.t seem to hang here
is "hang with cpu usage non-zero" livelock and "hang with no cpu usage" deadlock? 16:21
brrt yes
timotimo as in: is that the correct differentiation metric?
JimmyZ you may like ktap since SystemTAP is hard to use on ubuntu/debian 16:23
which is easy to use as per
timotimo is that the right thing to use here? ktap sounds a bit like a kernel tool? 16:24
JimmyZ *perf
[Coke] sighs as jvm spectest is also dying.
brrt i think that is right, yes
JimmyZ you can use it to gen Flame Graph
[Coke] nine: ===SORRY!=== 16:25
Could not find Test:ver<True>:auth<True>:api<True> in:
on the jvm. updating again...
timotimo brrt: do you have a clue how good our current jit is with IntLexRef?
JimmyZ [Coke]: moarvm here :)
brrt no clue timotimo
timotimo every instance of $pos = $pos + 1 is two getlex, a decont_i, an add_i, an assign_i; i wonder if it's cheap or expensive 16:26
and i use that a whole lot in my code
also every reference to $pos is, of course, a getlex and a decont_i
brrt y not $pos++ 16:27
timotimo because that's a million times more expensive :) 16:28
brrt but to be honest.. .we need heroic optimization before we ever see the JIT, before we get there
why :-(
timotimo m: my int $foo = 0; while $foo < 10_000_000 { $foo++ }; say now - INIT now
camelia rakudo-moar 0a61b9: OUTPUTĀ«6.1351965ā¤Ā»
timotimo m: my int $foo = 0; while $foo < 10_000_000 { $foo = $foo + 1 }; say now - INIT now 16:29
camelia rakudo-moar 0a61b9: OUTPUTĀ«0.0661555ā¤Ā»
timotimo oh, just a hundred times
lexical references passed to operators are currently preventing inlining in both the static and the dynamic optimizer
for ... some reason
m: sub dotheloop(int $foo is rw) { while $foo < 10_000_000 { $foo = $foo + 1 } }; my int $bar = 0; dotheloop($bar); say now - INIT now 16:30
camelia rakudo-moar 0a61b9: OUTPUTĀ«0.349984ā¤Ā»
timotimo wowza
[Coke] JimmyZ: whoops, ww.
timotimo look at that, it's 5 times slower with the intlexref 16:31
however, i have no clue if that slowness impacts my JSON::Fast times at all
or if it's other stuff
brrt timotimo: i was thinking of writing, for the perl6 advent calendar, a post describing how to write performant perl6 code 16:36
in fact, i was thinking of writing a msgpack module
timotimo do you really want to tell people "yeah, just put 'use nqp' at the top and throw away all the nice operators we have. also, don't use variables anywhere!"? :) 16:37
brrt not because msgpack is any good, it isn't, but because it uses binary stuff rather nicely
hmmm
good point
how well do native types work these days?
timotimo "if you can, write your loops as SEQ( ... ) while ..." :P
they work rather well. especially now that we can pass native vars around as "is rw"
brrt seq? 16:38
well, hmm...
timotimo basically what do { .. } does, but without a lexical scope
and without an invocation or anything
brrt oh really
timotimo i used it to reduce the number of BOOTCode allocations in nom-ws
wasn't worth terribly much, because nom-ws only takes a small part of the complete time 16:39
and there's still the CATCH in there to catch what nqp::ordat does when it reaches beyond EOS
hm. perhaps it'd be performant to put an actual bounds check there.
AFK for a bit 16:40
i'm not against a post "writing performant code", but there are these caveats :(
hoelzro o/ #moarvm 16:41
brrt good * #moarvm 16:42
eh hoelzro
hoelzro o/ brrt 16:43
timotimo found the answer to my question about assign_i: of course we're not doing that extremely well. otherwise it'd be a sp_bind_i64 or a p6obind_i 17:11
probably the former
brrt aye 17:20
17:20 kjs_ joined
brrt diakopter: i'm trying to install windows 10 + vs2015 now... not sure what i'll need, but i'll keep you posteed 17:21
i'm not supposed to like it, but windows 10 is actually quite nice
timotimo oh, sp_bindi64 isn't right; there needs to be a pointer deref in the middle. so new spesh ops are needed 17:35
TimToady needs to rename SEQ to avoid confusion... 17:49
since "sequence" is already overloaded two ways without that
timotimo tell me when that happens :) 17:51
or perhaps have a deprecation cycle? or is SEQ really not meant to be for end-users at all?
TimToady we never specced it... 17:58
at a time when we were still trying to spec everything :)
it doesn't occur in roast, so it's not officially Perl 6... :P
maybe we need to put in all the C operators as C|| C<< C, and such... 17:59
timotimo MVMInt64 *target = *((MVMInt64 *)((char *)o + GET_UI16(cur_op, 2))); 18:00
*target = GET_REG(cur_op, 4).o;
i *think* this is what i mean when i say:
TimToady but now this is language design, so OT :)
[Coke] at this point, we should probably gut everything in advance of a release that is officially deprecated, and not ship v6.c with deprecations baked in.
timotimo at the offset "cur_op, 2" there is a pointer to an MVMInt64. i want to set the target of the pointer to the value "cur_op, 4"
except that needs to end in .i64
i think the * after the target = may be wrong 18:01
i know that if i put an & there i get the address of the pointer i wanted to follow. that's not the right thing. 18:02
if i just put the thing there, will C assign the address of the RHS into the LHS, too? or would that require a & there? 18:03
i think assigning a pointery thing to a pointer variable just updates the pointer to point at the same thing
oh, brrt left 18:07
i was about to ask him to implement that in the jit, please :D
poor him
18:13 pyrimidine joined 18:25 diakopter joined 18:47 domidumont joined 18:48 diakopter joined
timotimo the implementation seems wrong 19:00
at least i'm getting quite wrong values
shows what i know about pointer arithmetic and such :) 19:01
19:03 diakopter joined
TimToady timotimo: is SEQ actually being used in the ecosystem? 19:12
timotimo only in JSON::Fast since the very latest commit 19:13
TimToady because I'm gonna break it...
timotimo and perhaps tadzik just merged that commit in :)
TimToady it'll rename itself to STATEMENT_LIST
timotimo ah, not in panda yet
TimToady well, it'll fail with an obvious message :)
timotimo it'll rename itself? that's nice, so i don't have to do anything? :) 19:14
TimToady blames the french... 19:17
dalek arVM/spesh_nativeref_assign_decont: c7706c4 | timotimo++ | / (6 files):
A spesh op like sp_bind/get_i64 with an extra pointer deref
 19:48
arVM/spesh_nativeref_assign_decont: de68134 | timotimo++ | src/ (2 files):
Allow NativeRef to spesh assign_i and decont_i

this uses the op the previous commit introduced.
arVM/spesh_nativeref_assign_decont: 6a95b60 | timotimo++ | src/jit/ (2 files):
implement sp_deref_bind/get_i64/n in the JIT
 20:15
timotimo i implemented stuff in the jit and ... it got slower?! 20:19
[Coke] timotimo: more switching between jit and non jit? 20:21
21:00 synbot6 joined
timotimo nah 21:32
these frames in question were jit compilable before, then became non-jit-compilable when i introduced sp_bind_i64 and friends and then became jit-compilable again when i implemented them 21:34
jnthn If you're trying to mesaure changes at that level, you probably need something that can tell you stuff like how many instructions were retired 21:36
And maybe cache stats
timotimo that'd be a better metric, i agree. 21:37
but i was hoping the change would be noticable 21:38
since assign_i and decont_i weren't even going through the REPRop devirtualization yet
hmm. 14.5 vs 16.2 21:41
12.65 was the time earlier today 21:42
before i started touching moar. and now that same task costs 14.5?!
21:50 diakopter_______ joined
diakopter_______ timotimo: jitting is expensive! 21:53
what are the units there
22:14 diakopter_______ joined
timotimo seconds for the file i'm parsing with JSON::Fast 22:15
diakopter_______ eek
I was hoping you'd say microseconds
timotimo hahahaha 22:16
yeah, right
not this year, my friend
22:30 kjs_ joined
diakopter_______ timotimo: hoping, for the code's sake, I mean 22:33
timotimo oh, like ... if it ain't microseconds, it'll get to spend a lot more time under my thumb 22:39
22:44 njmurphy_ joined
lizmat another P6W: p6weekly.wordpress.com/2015/11/30/...ly-splits/ 22:55
diakopter_______ lizmat++ 22:57
jnthn lizmat: nice! :) 22:59
lizmat++
diakopter_______ here's a gem from the reddit comments linked: "Rakudo's had more testing since it's been around forever but MoarVM is where my hopes lie." 23:02
er, I mean HN comments
here's another "Want to get Perl 6 running on the .Net CLR? Implement an NQP interpreter (which is supposed to be fairly easy) and you're 99% done (at least that's my understanding)." 23:03
.oO( have you ever squelched a laugh so hard you cried silently?? )
 23:04
jnthn "fairly easy" :D
timotimo lizmat: did you also post it on #perl6? :)
lizmat yes 23:07
but I think it got snowed under there
diakopter_______ this one makes me cry in other ways: "Show me the more advanced parts of the language, are they transducers, monads, functors, natural transformations, auto-compilers, self-replicating systems, high AI in action, ML, NLP. What is the honey spot for this new language?" 23:09
timotimo i wish it had said "MLP" instead 23:16
but damn! they found out perl6 does nothing in particular excellently! nooooooo my only weakness! 23:17
23:22 diakopter_______ joined
diakopter_______ anyone have an interest in making a port of MoarVM/rakudo for seL4? sel4.systems/Info/Docs/seL4-manual-2.0.0.pdf 23:45

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!