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
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)
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
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 (&QUOTE 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
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
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
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
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!