|
02:55
greppable6 joined
02:57
ilbot3 joined
04:12
tbrowder joined
04:16
SmokeMachine joined
06:12
yoleaux joined
06:14
AlexDaniel joined
|
|||
| AlexDaniel | squashable6: next | 06:16 | |
| squashable6 | AlexDaniel, ⚠🍕 Next SQUASHathon in ≈3 hours (2018-03-03 UTC-12⌁UTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day | ||
|
06:44
domidumont joined
06:52
domidumont joined
07:15
domidumont joined
07:36
robertle_ joined
07:48
AlexDaniel joined
07:56
benchable6 joined
08:15
domidumont joined
09:17
zakharyas joined
09:19
zakharyas joined
09:32
zakharyas joined
09:57
Geth joined
10:05
brrt joined
|
|||
| brrt | . | 10:06 | |
| it may be the case that the bug we're seeing, is bindlex not respecting a write barrier | 10:07 | ||
| (the bug in box_s/box_i) | |||
|
10:10
reportable6 joined
10:11
bisectable6 joined
10:18
domidumont joined
10:24
brrt joined
|
|||
| brrt | now I will look at the decompose-object-conditional thing | 10:25 | |
| (i'm wondering if I should have a 'named template' thing where the expr template compiler outputs a constant that refers to the template index) | 10:26 | ||
| Geth | MoarVM: bfccd35c74 | (Bart Wiegmans)++ | 3 files Bindlex needs a write barrier I recall this being a bug for the lego JIT as well, a long time ago. This unbreaks building rakudo with templates for box_s / box_i (but at the cost of building somewhat smaller blocks, unfortunately). |
||
| MoarVM: d7f4387d07 | (Bart Wiegmans)++ | src/jit/core_templates.expr Enable box_i and box_s templates Now that bindlex for objects / strings is disabled, this is no longer a problem (until maybe we re-enable them with a write barrier). |
|||
| brrt | the named template thing, I think that could help with writing a write-barrier template, which is otherwise quite finicky | 10:30 | |
|
10:34
domidumont joined
11:01
zakharyas joined
11:09
Ven`` joined
11:10
Ven` joined
11:17
MasterDuke joined
11:58
AlexDaniel joined
12:05
unicodable6 joined
13:10
shareable6 joined
13:27
greppable6 joined
14:03
zakharyas joined
14:08
zakharyas joined
14:22
Ven`` joined
14:29
mtj_ joined
14:34
zakharyas joined
14:39
Ven`` joined
15:09
Ven`` joined
16:43
Kaypie joined
16:49
Kaiepi joined
17:19
domidumont joined
17:52
zakharyas joined
18:22
nativecallable6 joined,
bisectable6 joined
18:31
unicodable6 joined
18:36
zakharyas joined
19:42
Kaiepi joined
19:55
Kaypie joined,
greppable6 joined
20:10
ZofBot joined
20:31
zakharyas joined
20:35
japhb joined,
zakharyas joined
21:49
Kaiepi joined
21:51
Kaypie joined
|
|||
| Geth | MoarVM: MasterDuke17++ created pull request #812: If no start time set, don't end a spesh log |
22:03 | |
| MasterDuke | hm, anyone see a problem with this template? `(template: ishash (flagval (all (nz $1) (eq (^getf (^repr $1) MVMREPROps ID) (const ("E MVM_REPR_ID_MVMHash) int_sz)))))` | 22:43 | |
| it's throwing a NYI MVM_oops from src/jit/x64/tiles.dasc, `MVM_JIT_TILE_DECL(cast_load_addr) { MVM_oops(tc, "NYI"); }` | 22:44 | ||
| Geth | MoarVM: ffd752235a | (Timo Paulssen)++ | src/profiler/instrument.c remove debugging output from profiler runs |
22:48 | |
|
22:57
travis-ci joined
|
|||
| travis-ci | MoarVM build failed. Timo Paulssen 'remove debugging output from profiler runs' | 22:57 | |
| travis-ci.org/MoarVM/MoarVM/builds/348462286 github.com/MoarVM/MoarVM/compare/d...d752235a97 | |||
|
22:57
travis-ci left
|
|||
| Geth | MoarVM: 6952c69242 | (Timo Paulssen)++ | src/profiler/instrument.c delete left-over line breaking compilation |
23:03 | |
| timotimo | so i'm wondering: should identical call graphs from different threads be merged by the profiler before feeding it to the nqp code that writes out the html or sql data? | 23:13 | |
| or maybe it ought to be done by the frontend where it can also decide "is this a worker thread from a thread pool scheduler?" | |||
| jnthn | Probably both views can be useful, so I'd lean towards preserving information | 23:14 | |
| timotimo | the json-fast test file 09-race.t is currently writing its html profiler data and it's already reached 170 megs | 23:16 | |
| 200 | |||
| stopped just shy of 400 megs | 23:18 | ||
|
23:22
travis-ci joined
|
|||
| travis-ci | MoarVM build passed. Timo Paulssen 'delete left-over line breaking compilation' | 23:22 | |
| travis-ci.org/MoarVM/MoarVM/builds/348467884 github.com/MoarVM/MoarVM/compare/f...52c6924214 | |||
|
23:22
travis-ci left
|
|||
| timotimo | 348 for equivalent workload - except what if the supervisor thread decided differently for this one | 23:26 | |
| changed the sql output code to put lots of pieces into an array and then join them before printing them out | 23:38 | ||
| that should make things a bit faster, i believe | |||
| kind of wish i could benefit more from the fact that a bunch of these strings are constant/literal | |||
| so some of them could be encoded only once, if the pieces before and after such pieces are guaranteed to "end properly" | 23:39 | ||
| MasterDuke | timotimo: i was thinking about that, given how long it took to write out the data for profiling the build | 23:52 | |
| but i think that's what we did originally, and i changed it to write out each piece, because otherwise the memory use was even higher than it is now | 23:53 | ||
| that = put lots of pieces into an array and then join them before printing them out | |||
| timotimo | hm, how many did you collect before printing? | 23:56 | |
| putting a reference to the same string in, for example, ought to be relatively cheap | |||
| also, in theory, we could write that stuff out multi-threaded :) | 23:57 | ||
| MasterDuke | hm, i'm looking back through the NQP git log for src/vm/moar/HLL/Backend.nqp and i don't see anything quite like that from me | 23:59 | |
| but 1c4e73ea2f0432602a6e94719cf6a31532c0a998 does look relevant | |||