|
00:00
TimToady left
00:20
TimToady joined
00:53
Kaiepi joined
02:48
lizmat left
03:10
Kaiepi left
03:11
Kaiepi joined
03:18
lizmat joined
03:23
lizmat left
04:35
AlexDaniel left
05:36
AlexDaniel joined
05:57
Kaiepi left,
Kaypie joined
06:04
domidumont joined
06:08
domidumont left
06:09
domidumont joined
06:37
Merfont joined
06:39
Kaypie left
07:07
robertle joined
07:24
lizmat joined
07:51
Redfoxmoon left,
Redfoxmoon joined,
Redfoxmoon is now known as niom,
niom is now known as Redfoxmoon
08:01
Merfont left
08:03
Kaiepi joined
08:21
zakharyas joined
08:28
zakharyas1 joined
08:30
zakharyas left
08:33
zakharyas1 left,
zakharyas joined
08:39
brrt joined
08:44
AlexDaniel left
|
|||
| brrt | good * | 09:02 | |
| jnthn | o/ | 09:32 | |
| brrt | jnthn: i wanted to know what you think regarding the whole type punning / strict aliasing thing; the context is that I want to union {} the 'node info' array with the 'tree nodes and references' array, since that saves me from having to manually keep them in sync every time the array is changed, which is often in the expression optimizer | 09:45 | |
| my solution was either to have a union of structs, or simply an array-of-unions | |||
| the point is, since that is apparently all problematic under strict aliasing, i'm not sure whether or not to go ahead with it | 09:46 | ||
| jnthn | Hm, I thought unions where part of the correct way to deal with such things? | 09:51 | |
| brrt | it is a vague matter | 10:06 | |
| i thought that as well, but apparently only memcpy is legal | |||
|
10:18
brrt left
10:50
AlexDaniel joined
10:57
brrt joined
11:11
zakharyas left
|
|||
| Geth | MoarVM/pluggable-spesh: 6a022aa1ca | (Jonathan Worthington)++ | 3 files Set facts on spesh plugin resolvee |
11:14 | |
| brrt | oh, now that you're probably online anyay, any thoughts on moving the p6 'extension ops' out of rakudo and into moarvm? | 11:19 | |
| i assume that's orthogonal to your work in pluggable-spesh | |||
|
11:25
Kaiepi left
11:26
lizmat left
11:40
AlexDaniel left
|
|||
| jnthn | brrt: Actually, it's very related, because many of the extension ops relate to assignment, and I'm going to completely redo Scalar and assignment in terms of spesh plugins next week :) | 12:16 | |
| And then I expect a lot of the C code will go away :) | |||
| brrt | <3 | 12:18 | |
| jnthn | Not all of it of course, but some :) | ||
| I'd rather consider the extops one by one and figure out what best to do with them | |||
| brrt | okay. then my simple plan of copy-psting them in the moarvm source tree is redundant | 12:19 | |
| thing is, i'm no longer seeing the point of having them separately maintained | |||
| and having them embedded in the interpreter makes things like a 'fakexecutable' for perl6 somewhat simpler | 12:20 | ||
| jnthn | Yeah, agree | ||
| brrt | but i'll happily await your redo of Scalar | 12:21 | |
| :-) | |||
| plenty to do in the JIT, anyway; one of these days i want to tackle some improvmeents on the register allocator | 12:22 | ||
| jnthn | btw, dunno if you saw the last commit I did in the Rakudo repo, but just wrote the first real spesh plugin and it gets us 6.6x faster private method calls inside of roles :) | 12:23 | |
| brrt | did not see, no | 12:24 | |
| oh, i see | 12:32 | ||
| cool | |||
|
12:36
zakharyas joined
12:53
AlexDaniel joined
|
|||
| jnthn | Currently working on one for $foo.Bar::baz | 13:08 | |
| Hm, blows up in the JIT, for an issue I thought I'd already fixed. | 13:10 | ||
| But with MVM_JIT_DISABLE=1 it's 13.3s -> 2.06s | 13:11 | ||
| Ah :S | 13:15 | ||
| It's about inline | 13:16 | ||
| I get I'm in trouble for taking a single deopt annotation and re-using it over a set of guards | |||
| *I but | |||
| hah, *I bet :) | 13:18 | ||
| Uff, yes. | 13:23 | ||
|
13:25
AlexDani` joined
13:27
AlexDaniel left
|
|||
| jnthn | Cool, after that fix it's 1.07s with the JIT :) | 13:43 | |
| timotimo | wowza, that's a nice improvement | 13:49 | |
| Geth | MoarVM/pluggable-spesh: c1d3f6e09a | (Jonathan Worthington)++ | 3 files Only use a deopt table index once in the graph Re-using them makes for great amounts of confusion when we take some specialized code for inlining and reconstruct the deopt annotations. If two annotations in the original graph shared a position in the table, then we cannot reconstruct both. The result would be a JIT oops if we inlined the specialization of a speshresolve that introduced more than one guard. |
||
| jnthn | Yeah, I thought that was relatively rarely used | 13:50 | |
| Then discovered there's 66 instances of it in CORE.setting | |||
| ah, some spectest fail to look at though :( | 13:51 | ||
| oh, duh | |||
| yes, good, it was just a silly thinko | 13:54 | ||
| I guess I can do this trick for .? too | 14:15 | ||
| brrt | I thank my lucky stars that the JIT is sometimes codes sufficiently defensively | 14:29 | |
| not always unfortunately | |||
| also, jnthn++ | |||
| jnthn | Yeah, some win on the .? case too | 14:36 | |
| Looks like 1.5x - 2.5x though I used rand in the benchmark which is costs something | 14:37 | ||
| So the actual win on the .? itself will be more than that | |||
| It's 1.5x faster in a case that's 50/50 different objects, and 2.5x in a case that's 999/1 different objects | 14:38 | ||
| ('cus in the latter case it's in the sufficiently monomorphic category) | 14:39 | ||
| brrt | :-D | 14:42 | |
| oh, can i subtly point you to MVM_VECTOR(...) - you're free and welcome to keep on writing your own vector management routines, but I find them to be worth the inconvenience of a free() at the end | |||
| which is especially easy to deal with for a spesh graph | 14:43 | ||
| jnthn | Yeah, should probably switch a few things over to that | ||
| timotimo | :D | 14:50 | |
| i should be using that more often, indeed | |||
| i wonder if compiling guard tables will give another juicy win here | 14:52 | ||
| btw, have we ever considered jitting nfas? or are they not costly enough at the moment after the last improvement? | 14:55 | ||
| jnthn | Well, in the monomorphic case we don't look at the guard table at all | 14:57 | |
| timotimo | right | ||
| i was refering to one of the last sentences in the commit message | 14:58 | ||
| jnthn | Did occur to me that we can consider compiling them in the other case | ||
| Dunno how much of a win it'd be | |||
| timotimo | the guard table is already rather compact in memory, i believe | 14:59 | |
| jnthn | Yeah | ||
| To really get a win we'd need to do more sophisticated splitting, I suspect | |||
| (e.g. explode the dependent code so we can inline the two options, for example) | 15:00 | ||
| timotimo | mhm | ||
| jnthn | brrt: Can something of the form `x = some_integer ? y : z` compile into something nice when we know x and y are simple constants, not expressions (e.g. some kind of conditional move)? | 15:08 | |
| oops, when we know y and z | |||
|
15:09
brrt left
15:11
domidumont left
|
|||
| Geth | MoarVM/pluggable-spesh: bf60f5feff | (Jonathan Worthington)++ | src/spesh/plugin.c Allow recursive use of nqp::speshresolve Would be quite unusual, but could happen in meta-programming. |
15:42 | |
|
15:45
zakharyas left
|
|||
| Geth | MoarVM/pluggable-spesh: 7ea08c9a35 | (Jonathan Worthington)++ | src/spesh/plugin.c Fix a memory leak |
15:46 | |
| jnthn | Alright, I think I can merge this thing :) | 15:47 | |
|
15:47
Kaiepi joined
|
|||
| timotimo | ooooooh | 15:47 | |
| jnthn | I've still got the attribute case to go, but no reason not to have this in already | ||
| Geth | MoarVM/master: 27 commits pushed by (Jonathan Worthington)++ review: github.com/MoarVM/MoarVM/compare/c...a08c9a352c |
15:48 | |
| timotimo | and at some point scalars | ||
| jnthn | The Scalars need that bit | ||
| I meant "of things directly relating to the plugin mechanism" though :) | |||
| timotimo | i'm not entirely sure how scalars will be changed; we'll resolve a FETCH or STORE if we need to, and otherwise inline a super simple attribute assignment/access? | 15:49 | |
| jnthn | See gist.github.com/jnthn/e51a06c6882f...0a3dd373e6 for my notes on it | ||
| timotimo | ah, i forgot about half the stuff already :D | 15:50 | |
| jnthn | (near the bottom) | ||
|
16:03
lizmat joined
16:13
robertle left
16:16
Kaiepi left
16:56
brrt joined
|
|||
| brrt | jnthn: yes, we can, but it is not necessarily an obvious win | 16:58 | |
| well, hmm, now that i think of it, i can think of a cute way to compile that | 16:59 | ||
| you'd have to do a mov r1, const1; mov r2, const2; test condition; cmovz r1, r2; (or something like that) | 17:02 | ||
| i recall there being arguments that this wasn't ideal though | |||
| although it is shorter in code | |||
|
17:29
domidumont joined
17:48
robertle joined
17:49
robertle left
18:04
brrt left
18:17
Kaiepi joined
18:20
lizmat left
|
|||
| japhb | Noticed as I was browsing the merge -- github.com/MoarVM/MoarVM/commit/0e...162aa6ae7b does the opposite of what its commit message says. Accidental revert? | 18:57 | |
|
19:00
domidumont left
19:06
AlexDani` is now known as AlexDaniel
|
|||
| jnthn | japhb: No, the commit is correct, then the commit message is wrong | 19:12 | |
| d'oh | |||
| japhb | Ah, gotcha. | 19:19 | |
|
19:48
Kaiepi left,
Kaiepi joined
|
|||
| timotimo | the moarvm fuzzing work has found its last unique crash 2 days, 15 hours ago | 20:56 | |
| i wonder when i should terminate it | |||
| MasterDuke | ah ha, that's another thing that should be automated! | 20:57 | |
| timotimo | hack.p6c.org/~timo/moar-fuzzing-stuff.tar.xz - 561ca412d9e53c7b09871e3a6eb825c8ae40a92ca3a7fbcf233528d442bd5938 | ||
| MasterDuke | and code coverage reports | 20:58 | |
| i have so many good idea | |||
| timotimo | it's just below 500 kilobytes big, but extracts to about 320 megs | ||
| MasterDuke | timotimo: you know where the bug is? | ||
| timotimo | what bug? | ||
| MasterDuke | whatever causes the crash? | 20:59 | |
| timotimo | what's "the crash"? | ||
| i'm confused %) | |||
| you mean the crashes that the fuzzer has found? | 21:00 | ||
| MasterDuke | yeah | 21:02 | |
| timotimo | well, it claims to have found 868 unique kinds of crashes | ||
| i have not looked into more than three or four | |||
| MasterDuke | ah | ||
| timotimo | the tar.xz has the .moar files that cause the crashes | 21:03 | |
| more (or less) interesting is the nqp fuzzing, i.e. the fuzzer generates random nqp source code and tries to crash nqp/moar with it | 21:06 | ||
| it claims to have found 107 unique crashes, but none that i tried did anything at all | |||
| the inputs look interesting, like ... | 21:07 | ||
| 00000000: 6865 636b 205d 0d2b 1022 0d0d 0d0d 2321 heck ].+."....#! | |||
| 00000010: 2063 7170 1063 6b74 1022 6f5f 0a3c 2063 cqp.ckt."o_.< c | |||
| 00000020: 68cd 9f0e 512d 72cd 9fcd 9263 0ec5 92cc h...Q-r....c.... | |||
| 00000030: 9f6f cd92 63cd 9220 004b 6b68 626e 41cd .o..c.. .KkhbnA. | |||
| that makes me think it's not being very successful in ifguring out what things do | |||
| huh, one of the files had an MVM environment variable name in it... how did that get there? perhaps i had the launcher script in there, too | 21:09 | ||
|
21:12
AlexDaniel left
21:13
AlexDaniel joined
|
|||
| timotimo | i'll go ahead and minimize the test files a little | 21:13 | |
| MasterDuke | hm. so it claims to have nqp code that crashes moar, but you can't repro? | 21:14 | |
| timotimo | even though it could very well be impossible to change the input file size because it might verify that it's long enough to have all its sections? | ||
| anyway, minimizing the files will still make the files better compressible | 21:16 | ||
| it'll take three quarters of forever | 21:18 | ||
| you want to have a look at the files that it believes makes nqp crash? | |||
| MasterDuke | sure | 21:21 | |
| timotimo | hack.p6c.org/~timo/nqp_crashes.tar.xz - 5993e3e20787db6fb5dac5d53dd713f5f9c8b3d4c237a6fbfdc950de7a8dcb99 | 21:23 | |
| MasterDuke | just run the scripts in nqp_input_raw? | 21:27 | |
| timotimo | cd into nqp_input_raw and run the files in ../findings/crashes/ | ||
| MasterDuke | why cd to nqp_input_raw? | 21:35 | |
| timotimo | because that's where the code was run from | ||
| if any of the files try to access any other files from ./, it'll have to be from there | 21:36 | ||
| MasterDuke | no crashes for me | 21:38 | |
| timotimo | thought so :( | ||
| the moar files should crash so much more reliably | |||
| afl-tmin is fun. it replaces every character in the file that doesn't matter with an ascii 0 | 21:40 | ||
| github's org-mode renderer doesn't understand = | 21:44 | ||
| "Macro parameters are prefixed by =,= (e.g. =,obj=)," | |||
| samcv | so how do you see what ops were not jit'd timotimo | 21:54 | |
|
21:58
lizmat joined
|
|||
| jnthn | samcv: iirc, MVM_JIT_LOG=somefile in the environment, then grep BAIL somefile | 22:02 | |
| Geth | MoarVM: jstuder-gh++ created pull request #872: Define SIGBREAK on WIN32 |
22:13 | |
| MoarVM: cfbfdc130a | (Jeremy Studer)++ | src/io/signals.c Define SIGBREAK on WIN32 SIGBREAK is another signal emulated by libuv on Windows, but is not defined in the platform's signal.h file. Using the same signum provided to it in NodeJS's os.constants.signals object. |
22:41 | ||
| MoarVM: 3d51256c1c | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/io/signals.c Merge pull request #872 from jstuder-gh/new_sig_sigbreak Define SIGBREAK on WIN32 |
|||
| timotimo | releasable6: status | 22:47 | |
| releasable6 | timotimo, Next release in ≈7 days and ≈20 hours. 4 blockers. 0 out of 60 commits logged | ||
| timotimo, Details: gist.github.com/e6c859b62fe5b01671...30cd3ae950 | |||
|
22:50
Kaiepi left
23:21
AlexDaniel left
23:22
AlexDaniel joined
|
|||
| timotimo | test case minimization has reached id:000017 | 23:42 | |