00:13 japhb joined
timotimo maybe i'll look into jitting newexception, bindexpayload, bindexcategory and throwdyn 00:30
then THROW could be jitted
for now, i'm going to go to bed
and tomorrow i'll investigate what costs us the most in the recursion-based benchmark 00:31
00:44 vendethiel joined 00:49 colomon joined
timotimo nqp::ordat currently only does the "if it's an NFG synthetic, look up its base character" thing in the interp, but not in the jitted version i'm afraid. we'll need to fix that soon. 01:07
01:12 vendethiel joined 01:24 colomon joined 02:19 vendethiel joined
TimToady back home, after driving through yosemite, great time of year to see the waterfalls, despite the drought 05:34
[Coke] Welcome back. 05:56
06:56 FROGGS joined
FROGGS jnthn: do you remember that I said that the current RESTRICTED setting should be improved by disallowing certain nqp ops directly 07:00
jnthn: that's what digged into yesterday... and since re-registering nqp ops is not enough because of the precompiled setting itself, I implemented a safety mode for MoarVM 07:02
jnthn: ops get annotated as ':unsafe' in oplist, and if we are running in safe mode we bail out when such an op is hit
07:03 jepeway joined
FROGGS jnthn: I'll probably push to a branch today, though, I need to get restricted stuff lexically correct too, so that one can EVAL in safe mode 07:04
07:10 vendethiel joined
FROGGS hmmm, I wonder if it makes more sense to remove the annotations from oplist, and add a macro to the unsafe ops in interp.c directly 07:10
so we dont have to check safe ops every time 07:11
not that there is a major slowdown atm, but still 07:13
07:37 zakharyas joined
jnthn FROGGS: I agree the VM is the right place to put restrictions 07:41
nwc10 jnthn: better luck with coffee this morning?
jnthn nwc10: yes :) 07:43
FROGGS well, this works, though it is a little bit too late for a setting: 07:50
m: use nqp; use QAST:from<NQP>; BEGIN { QAST::MASTOperations.add_core_op('openpipe', -> | { die "!!!" }) }; nqp::openpipe("wc -l")
camelia rakudo-moar c2a57e: OUTPUTĀ«===SORRY!===ā¤!!!ā¤Ā»
FROGGS but if we have ops like: nqp::unsafedisable() and nqp::unsafeenable, we can forbid in user code
forbuid these*
hmpf 07:51
jnthn We need to figure out how static/dynamic this is meant to be
Scoping wise, I mean
FROGGS I hope we can make this lexically work 07:52
ohh, I see
jnthn Well, it's not that simple
FROGGS aye
that's what I figured :o)
jnthn 'cus of course the Perl 6 open sub will be lexically fine
FROGGS yeah
08:07 vendethiel joined 08:48 Ven joined 09:23 vendethiel joined 09:33 arnsholt joined 09:35 nwc10 joined 09:42 zakharyas joined 10:02 zakharyas joined 10:30 vendethiel joined 11:13 Ven joined 11:35 zakharyas joined
FROGGS $ MVM_UNSAFE_DISABLE=1 perl6 -e 'pipe("wc -l").close' 11:51
Operation 'openpipe' is unsafe you useless lump!
in block <unit> at -e:1
gist.github.com/FROGGS/8800bcf38edca105618c
though, that does not cover the case where we want to disable unsafe ops in a given scope 11:54
timotimo hm, so do we implement the proper locking for lazy deserialization while jnthn recovers? 12:03
dalek arVM: af16b82 | timotimo++ | src/jit/graph.c:
a bunch of reprops were missing from op_to_func.

thanks, smls++		 12:27
arVM: ce0d3eb | timotimo++ | src/jit/graph.c:
implement ordfirst in the jit
12:37 travis-ci joined
travis-ci MoarVM build failed. Timo Paulssen 'a bunch of reprops were missing from op_to_func. 12:37
travis-ci.org/MoarVM/MoarVM/builds/64244752 github.com/MoarVM/MoarVM/compare/5...16b8206e52
12:37 travis-ci left 12:43 travis-ci joined
travis-ci MoarVM build failed. Timo Paulssen 'implement ordfirst in the jit' 12:43
travis-ci.org/MoarVM/MoarVM/builds/64244767 github.com/MoarVM/MoarVM/compare/a...0d3eb3576b
12:43 travis-ci left 12:57 FROGGS joined
timotimo hm 12:58
dalek arVM: 41b5dd2 | timotimo++ | src/ (3 files):
add missing reprconv functions for the jit
 13:10
13:19 travis-ci joined
travis-ci MoarVM build passed. Timo Paulssen 'add missing reprconv functions for the jit' 13:19
travis-ci.org/MoarVM/MoarVM/builds/64250128 github.com/MoarVM/MoarVM/compare/c...b5dd2616db
13:19 travis-ci left
timotimo phew. 13:21
sorry for keeping moarvm dead for an hour >_> 13:22
i really should have tried building before pushing
when will i learn?!
13:25 brrt joined
brrt \o 13:25
timotimo
we need a better solution, i think, for op_to_func
maybe a precompiled table
timotimo that sounds sensible 13:26
brrt hmmmm 13:27
if you'd have a string, you could encode enough information on what arguments to pass, even
you could do something like 13:28
timotimo such an approach would surely reduce code size 13:30
brrt for MoarVM, or from the JITted code?
brrt would think for the former
timotimo yes, only the former 13:32
brrt say, wval, would have { &MVM_sc_get_sc_object, "TCl1l2:P0" }; meaning first TC, then first register as a small literal, second register as a small literal, and the result as a pointer to the register indicated at 0 13:33
eh not first register, first constant value 13:34
first opcode parameter :-)
i'm confused
maybe it's better as:
"TC l1 l2:P0" - why not add spaces all the time
timotimo yeah 13:35
we have ourselves a little interpreter
maybe we should JIT that!
brrt don't get carried away :-P
but we loop anyway
and this adds for a much more concise encoding
*allows
timotimo also a bit harder to see if something wrong ... or maybe easier? 13:36
brrt harder, yes
timotimo well, it's less noise 13:37
brrt hmm
the question is also whether we can nicely encode all possiblities in a readable manner 13:38
and some things, of course, don't fit, and won't
timotimo right.
Your test run exceeded 50 minutes. 13:43
;( 13:44
brrt wow
many non-wow
timotimo oh 13:45
that was meant for #perl6
that's from perl6-examples
god damn it, those gen2 roots 13:47
masak's "send-more-money-subs" benchmark does 23233 collections
it starts out at 17782 gen2 roots (after the initial 2 GC runs that are a bit more intense) and 6.72ms 13:48
it goes up to 86264 gen2 roots taking 27.37ms
brrt uhm 13:49
that is quite a bit
timotimo yes 13:50
i don't really know what kinds of things end up getting a gen2 root 13:51
but still; GC only accounts for 22.5% of the run time of that program
brrt thinks perl6 needs tracing before it will perform properly
timotimo and we run 7% of all frames interpreted and 36% spesh'd 13:52
meaning 57% jitted
brrt why? because tracing can turn this stuff into jumps
timotimo not to speak of the 5.6% frames that get deopted
brrt 5,6% on a program like that?
wow
timotimo "this stuff"?
17833667 entries to gimme, 4.62% exclusive time spent there, about 4/5th or so interpteted 13:53
of course, the topmost four routines are from CORE.setting around line 10k, which is where ListIter's stuff lies 13:54
brrt 'this stuff' => cross-frame control flow stuff
which is *surprisingly* common in perl6
timotimo anon, anon, anon, gimme, anon, bind, bind_one_param, reify, map, FOR, find_method, WHICH, map
that's the order of routines by exclusive time
after that comes another reify
bind_one_param accounts for 4.09% at 33764537 entries 13:55
and is 100% interpreted
brrt bind_one_param is probably param_*_* isn't it?
timotimo i don't know, tbh
you mean "gets bailed by"? 13:56
brrt yes, and also 'mostly consists of such calls'
timotimo i'm now waiting for chrome to let me into the OSR/Deopt tab
you can find bind_one_param in BOOTSTRAP inside rakudo
brrt masak++ for giving us work to do
timotimo ISTR seeing iscont_* in there, too; i don't think we jit that yet
oh holy wow
the king of deopts is a BUILD, at 4838400 deopts 13:57
um ... that's from Enum ?!?
method BUILD($!key, Mu $!value) { self }
brrt huh 13:58
you sure we don't JIT iscont_*?
timotimo not sure
another one is MapIter's BUILD, at m-CORE.setting:10062 13:59
masak whu'? I've given this channel work to do as well? :) 14:06
oh, GC stuff. 14:07
well. you're welcome.
timotimo :) 14:09
brrt: FWIW, the "dynamic optimization" times usually turn up in the 0.* % range
so making the jit much faster isn't worth that much at this point, i suppose
though ... i don't know about the start-up time of short scripts 14:10
brrt ah, well, that's good to know 14:11
so i can just hang llvm in there and it'll be ok? :-P
brrt already knows LLVM will get a special slide in his presentation (if any) 14:12
the question is
how on earth to add 'art' to a talk about JITs
timotimo :P 14:13
art as in art?
brrt art as in art + engineering
timotimo mhm
brrt right
timotimo good question
brrt not art as in the last 3 letters of my name 14:14
i don't think that'll do
timotimo :)
now i ran -e 'say "hello!"' and profiled the compilation of that and dynamic optimization takes 5% of the compilation time 14:15
masak brrt: if making a JIT isn't a completely mechanical, robotic process, there's art in there somewhere. you just have to expose it to us, the audience. 14:16
brrt well... but i've been able to hide my robotic nature for so long 14:17
but i see your point 14:18
:-)
masak is reminded that he should submit a YAPC::EU talk too 14:22
timotimo will it be something specifically about perl6, or are you going to trick people into seeing a perl6 related talk? :P 14:32
masak: i'd still love to get a timing of send-more-money-loop with latest rakudo :) 14:33
i think i'll bump MOAR_REVISION and NQP_REVISION to get the op_to_func fixes into rakudo 14:34
nwc10 timotimo: please do a full build and spectest *before* commit that 14:35
because for me currently the spectest hangs on MoarVM head, for 3 tests
timotimo oh? 14:36
damn >_<
nwc10 oh yes.
timotimo ah, yes, the async tests that are waiting for jnthn's lazy deserialization fix 14:37
do you think i should revert the nqp MOAR_REVISION bump, too? 14:38
masak timotimo: patience, grasshopper. 14:42
timotimo mhm
masak need to decommute first :)
timotimo i'm a bit impatient in general, aren't i?
on the other hand, i sort of tend to take a looong time to do stuff i announce or speculate about :)
feels a bit like a double standard 14:43
brrt well... that's just open source, isn't it 14:44
:-)
timotimo hm 14:50
anyway, walk &
brrt see you :-) 14:51
15:21 zakharyas1 joined 15:32 brrt left 16:12 vendethiel joined 16:50 vendethiel joined
timotimo is back 17:01
17:40 FROGGS joined, brrt joined
masak too 17:45
timotimo: ok, so just build latest rakudo and re-run version A? 17:46
timotimo yes
no versiom b
i did not touch A 17:47
masak: i expect the problem that makes A so terrifyingly slow is GLR-related 18:03
masak oki 18:04
timotimo and those blasted gen2 roots that i haven't put any time into understanding 18:07
though ihave no actual evidence tthat it's more than just corellation 18:08
masak "correlation" ;) 18:11
hm, are there other roots than gen2 roots? 18:12
or are all roots gen2 roots?
timotimo nah, those are the inter-generational roots 18:15
18:16 Peter_R joined
timotimo er, i think so at least 18:16
masak timotimo: wohoo! 18:26
timotimo: down from 22 seconds to 15! \o/
FROGGS is there something in moarvm that carries information along a call chain... but is not a dynamic variable in P6 land? 18:32
something cheap?
jnthn 'fraid not 18:33
FROGGS :/
jnthn Though we do cache dynamic variables to decrease their cost 18:34
FROGGS yes, that's what I was about to ask
jnthn Somebody in backlog mentioned picking up on my serialization race fix 18:57
gist.github.com/jnthn/75c041af8f6a13bf5638 is as far as I got
Unfortunately, the patch hangs Rakudo at startup and noms loads of memory
Uh, and there's some communt out lines 18:58
nwc10 in C99 style
jnthn Anyway, anyone is free to pick it up and explore
nwc10: Yeah, I use those 'cus MSVC tolerates them and they stand out enough in review that I don't accidentally commit them :) 18:59
nwc10 that was roughly my assumption - they're "XXX"-like comments
it works well
19:00 brrt joined
brrt uses those comments in dynasm because dynasm is otherwise frustrated 19:08
oh, and what is more 19:09
we do jit iscont_*
20:33 colomon joined
timotimo brrt: would you like to whip up something to fix up ordat and ordfirst? 20:35
ah, good
brrt sorry, what, i wasn't paying attention 20:36
timotimo i wonder if we spesh iscont_*, too
brrt whats wrong with ordat and ordfirst
they're just function calls, aren't they?
timotimo ordat and ordfirst have to check if the result is negative, and if so, get the base of the synthetic grapheme
they have been "enhanced" recently
brrt ah
i see
timotimo i was thinking about just making a for-the-jit function that does what the interpreter does at that point
but maybe we can make something cheap inside graph.c 20:37
brrt yes, i wonder about that
it would be quite handy to have 'go to completion' in emacs
eh go to definition
what, why do we upcast MVM_string_get_grapheme_at_nocheck and then downcast it again 20:41
that costs us.. nothing on x64, though 20:42
anyway
we can hack up something cheap, yes
let me get my sketchpad first 20:43
nope, i'm wrong 20:45
oh, no, i'm right
hmmm
i'm confused
is what i am
argh 20:46
lizmat timotimo: fwiw, I made next/last/redo even simpler multi's 20:47
brrt i need one extra register
lizmat and I just made THROW a multi
brrt then i can do a graph version
now i need to change them into primitives
(i can't get extra registers for free just like that :-() 20:48
because JIT_RV_DEREF, which I don't think we *ever* use, can just read the base 20:49
lizmat tries to pun a register
brrt long story short 20:55
you can do it from graph.c
it is a hack
i'm not 100% sure it will hold, because of label logic
it's not very difficult to write in ASM
brrt should probably check how label logic is implemented again 20:56
ok, labels should not be a problem 20:58
timotimo thank you for looking into it :) 21:00
brrt thats what i'm for :-) 21:08
well, not all i'm for
but you get the point
emacs has semantic mode 21:11
many wow
(like whitespace-mode, i wonder how i never heard of that)
tech analysts, where 20% year over year growth is called 'stalling' 21:12
in env sci, 20% yoy growth is called 'a disaster' 21:13
brrt bbiab 21:17
21:47 vendethiel joined 21:57 colomon joined 22:31 vendethiel joined 23:00 vendethiel joined
timotimo brrt, is there anything in our way for jitting "throw"? 23:29
throwdyn, that is. 23:30
throwdyn isn't marked :throwish, i wonder why? 23:31

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!