|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:15
AlexDani` joined
00:19
AlexDaniel left,
AlexDani` is now known as AlexDaniel,
AlexDaniel left,
AlexDaniel joined
01:12
Kaypie joined,
Kaiepi left
04:00
pamplemousse joined
06:08
shareable6 left,
committable6 left,
reportable6 left,
AlexDaniel` left,
nine left
06:12
benchable6 left,
coverable6 left
06:17
benchable6 joined,
coverable6 joined
06:18
shareable6 joined,
committable6 joined,
reportable6 joined,
AlexDaniel` joined,
nine joined
06:25
Kaypie left,
Kaypie joined
07:05
Kaypie left
07:08
Kaiepi joined
07:20
robertle left
08:10
Kaypie joined,
Kaiepi left
08:12
AlexDaniel` left
08:17
Kaypie is now known as Kaiepi
08:21
AlexDaniel` joined
09:06
sena_kun joined
09:18
robertle joined
|
|||
| samcv | AlexDaniel, should probably release it sometime tonight i think | 09:29 | |
|
09:56
Kaiepi left
09:59
Kaiepi joined,
Kaiepi left
10:00
Kaiepi joined
10:01
pamplemousse left
10:02
Kaypie joined,
Kaiepi left
10:25
Kaypie is now known as Kaiepi
10:45
Kaiepi left
10:49
Kaiepi joined
10:56
robertle left
11:18
pamplemousse joined
11:37
pamplemousse left
11:43
pamplemousse joined
|
|||
| lizmat | dmitrysoshnikov.com/courses/essenti...ollectors/ | 11:59 | |
|
12:41
robertle joined
12:47
Kaiepi left
12:48
Kaiepi joined
13:02
Kaiepi left
13:03
Kaiepi joined
13:10
Kaiepi left
|
|||
| timotimo | so there's still this case where nqp::if($!foo, ...) will compile the attribute in attributeref context; it's likely that spesh can figure this out, but i'm wondering if it shouldn't be rakudo's static optimizer that should know to change the scope from attrref to attribute in cases like this | 13:16 | |
| i'm just not sure what the reliable set of checks would be to find when that's okay and when it's not | 13:17 | ||
| there's already a little branch for nqp::if($i, ..., ...) when $i is a lexicalref known to be native | 13:22 | ||
| it turns the if into an isne_i with 0 which should be a cheaper check than boolifying the number i guess? | |||
| though perhaps spesh makes the difference go away, too | |||
| MasterDuke | but if we can optimize before it even gets to spesh that's only ever a good thing right? | 13:25 | |
| timotimo | i'd say "it depends" | ||
| if we save time in the optimize stage of compilation, that's code that runs in sequence with other stuff, whereas spesh runs in parallel | |||
| and spesh knows to only optimize code that's actually being run, though optimizing everything is probably worth it when precompiling the core setting at least | 13:26 | ||
|
13:26
Kaiepi joined
|
|||
| MasterDuke | maybe we could be smarter/do more with the static optimization levels. e.g., be more aggressive when pre-compiling, default to less so with the option to turn it back on for command line scripts | 13:29 | |
| timotimo | yeah, i believe the core setting already has a higher default optimization level anyway | 13:30 | |
| just not too many checks for what optimization level is active in the optimizer's code | 13:31 | ||
| anyway, i got a small patch for the lexicalref thing; i've extended it to attributeref, i've removed the requirement that it has to have an else block (but only if it's in void context), and maybe localref can also turn into local here. | 13:33 | ||
| but first, a spectest | |||
| well, it passes all spec tests ATM | 13:46 | ||
| jnthn | timotimo: A lot of the attr => attrref stuff is taken care of in code-gen, I think | 13:53 | |
|
14:10
domidumont joined
14:18
pamplemousse left
14:56
patrickb joined
14:57
sena_kun left,
sena_kun joined
|
|||
| timotimo | OK. it wasn't in this case, but the optimizer now gets it :) | 15:03 | |
| this case refering only to if/unless/while/until | |||
| but only if the attribute/lexical/local is the direct child of the op | 15:04 | ||
| there's many more that have the form "blah while $foo++ > $bar" that this won't catch, though i haven't checked if they also use refs everywhere | 15:05 | ||
|
15:19
pamplemousse joined
15:48
pamplemousse left
16:35
patrickb left
16:36
patrickb joined
16:46
patrickb left
17:12
zakharyas joined
17:18
AlexDaniel left
17:19
AlexDaniel joined
17:33
btyler left
17:52
lucasb joined
17:55
zakharyas left
18:36
domidumont left
|
|||
| MasterDuke | timotimo: huh, looks like i never added smrt_intify support to src/spesh/optimize.c | 19:13 | |
| or was there something you did/were going to do after i added the smrt_intify op? | |||
| timotimo | um, maybe there was | 19:14 | |
| i don't remember now :o | |||
|
19:28
zakharyas joined
|
|||
| MasterDuke | something related to this comment maybe? github.com/MoarVM/MoarVM/blob/mast...#L943-L946 | 19:29 | |
| direct invokes? | |||
|
20:02
brrt joined
|
|||
| brrt | \o | 20:02 | |
| nwc10 | o/ | 20:05 | |
| timotimo | o/ | ||
| brrt | I'm nearly done with floating point comparisons! | 20:10 | |
| timotimo | heck yea | ||
| brrt | I started, for a change, actually reading the intel documentation, and it turned out to be readable | ||
| timotimo | well, it better be | 20:11 | |
| MasterDuke | timotimo: this this looks reasonable? gist.github.com/MasterDuke17/46afe...e85872098e | ||
|
20:12
lucasb left
|
|||
| timotimo | i think the if/elsif with the new_ins->info needs more checks, too | 20:12 | |
| MasterDuke | oh? | 20:13 | |
| timotimo | though not sure what the stuff right before that is, maybe it excudes the possibilities of is_strify on a string register? | ||
| is_numify checks if the register type is num; if so, it becomes set, if not it becomes coerce_in | |||
| MasterDuke | it's annoying, i know i implemented this before. maybe it's sitting in a local branch on my desktop | 20:14 | |
| timotimo | yeah, or perhaps in a stash even | 20:15 | |
| MasterDuke | that code is in the `else if (!is_strify && (REPR(facts->type)->ID == MVM_REPR_ID_VMArray || (REPR(facts->type)->ID == MVM_REPR_ID_MVMHash))) {` branch | 20:16 | |
| timotimo | ah, ok | 20:17 | |
| it's kind of annoying that you can't just "show more context" for patches like that | |||
| ... | |||
| if i have some extra extra time soon, i could perhaps come up with something a userscript could do | |||
| until then, theoretically, linkify could already get you one step closer | 20:18 | ||
| until then, i think the patch looks good? | 20:24 | ||
| MasterDuke | cool. i'm in the middle of a spectest now | ||
| brrt | should LOAD and CONST get a type parameter? | 20:52 | |
| that would probably be enough to type-infer the rest of the operands | 20:53 | ||
| Geth | MoarVM: MasterDuke17++ created pull request #1133: Jit and spesh optimize smrt_intify |
20:57 | |
| MasterDuke | whoops, accidentally had spectests running in two different terminals. no wonder this laptop was dragging... | 20:58 | |
| can captureposarg_n easily be jitted? or is that one of the problematic ones? | 21:01 | ||
| hm, *_i and *_s are jitted, maybe i can just crib from them... | 21:03 | ||
| brrt | you probably can, we store them in a uniform buffer | 21:06 | |
| MasterDuke | huh, there's no MVM_args_get_required_pos_num | 21:08 | |
| brrt: btw, why the difference between github.com/MoarVM/MoarVM/blob/mast...dasc#L1079 and github.com/MoarVM/MoarVM/blob/mast...dasc#L1099 ? | 21:10 | ||
| brrt | MasterDuke: what difference exactly? | 21:12 | |
| MasterDuke | and why is there only MVM_args_get_pos_num, not *_(int|str|obj) ? | ||
| brrt | I'm not sure, they were added a bit haphazardly, I think | ||
| timotimo | that could be for number of arguments, not get a positional num argument? | 21:13 | |
| MasterDuke | the '&' before the function name in one, but not the other | ||
| timotimo | the & is technically redundant | ||
|
21:14
zakharyas left
|
|||
| MasterDuke | looks like MVM_args_get_pos_num takes a "require" parameter, instead of having _require_ and _optional_ versions | 21:15 | |
| timotimo | gnite, maybe | 21:16 | |
| brrt | gist.github.com/bdw/5c942afa18cfdf...a8ccd2a12c | 21:18 | |
| MasterDuke | later. think i'm going to go watch an episode of jessica jones season 3 myself before sleep. will try and come back to captureposarg_n tomorrow | ||
| brrt | can anybody run this and see what result they get | ||
| \o timotimo | |||
| sena_kun | brrt, result is OK for me, any other info you might want? | 21:19 | |
| brrt | NOT OK for me | ||
| timotimo | not ok | ||
| brrt | wtf | ||
| MasterDuke | NOT OK for me | ||
| timotimo | ha | ||
| it uses islt_i for that | |||
| sena_kun | I am on vanilla 03.1 | ||
| brrt | timotimo: what? | ||
| MasterDuke | OK with 2018.12, NOT OK was HEAD | ||
| ugexe | OK for me on blead | 21:20 | |
| timotimo | so everything in nqp is normally num magic, but with a < you'll actually get an int op | ||
| mathic* i guess | |||
| MasterDuke | oh yeah, result my recent merge i guess | ||
| timotimo | use --target=ast or --target=optimize to see it | ||
| brrt | that's... surprising | 21:21 | |
| MasterDuke | OK on HEAD if i use nqp::islt_n(0.125, 0.126) | ||
| brrt has a distinctly unamused face | 21:23 | ||
| MasterDuke: why? | |||
| MasterDuke | i'm going to change what timotimo said to "everything in nqp *used to be* num magic, but now it's int behavior" | 21:24 | |
| brrt: fixes some bugs around nums not being able to represent all valid integers, should be faster, etc. | 21:25 | ||
| brrt | I mean, why don't we 'just' infer the correct type | 21:26 | |
| MasterDuke | does NQP ever infer types like that? | 21:28 | |
| Geth | MoarVM/jit-expr-float: dd9629d01c | (Bart Wiegmans)++ | 8 files [JIT] Support floating point comparisons Needs some debugging, doesn't always give the right answer. |
21:30 | |
| brrt | it could... it's not a hard job | ||
| anyway, that's for another day maybe | |||
| brrt zzz | 21:31 | ||
|
21:31
brrt left
|
|||
| MasterDuke | github.com/perl6/nqp/blob/master/s...r.nqp#L821 i "just" changed the op from `islt_n` to `islt_i` | 21:31 | |
| masak had some thought about detecting the problem situations in rakudo that this caused, maybe that's what he's thinking | 21:32 | ||
| but brrt++, looking forward to the float jitting | 21:33 | ||
|
23:07
sena_kun left
|
|||