MasterDuke timotimo: interesting. stage parse now panics when trying to build normally (but with FSA_SIZE_DEBUG still on) but succeeds under valgrind 01:31
MasterDuke timotimo: i just ran a couple builds with /usr/bin/time and i got significantly less variability with MVM_SPESH_BLOCKING=1 02:30
Geth MoarVM: 27c72f7d55 | (Samantha McVey)++ | src/strings/ops.c
join: special case 8bit flat pieces/separator. 3x faster

Special case when pieces or separators are flat 8-bit representations of strings. This improves speed 3x when joining 10 100,000 grapheme flat 8-bit pieces.		 03:43
MasterDuke timotimo: gist updated with latest valgrind output. not sure what's wrong, the buffer it's complaining about github.com/MasterDuke17/MoarVM/blo...tf8.c#L183 seems like it should be good at the end of the function 04:23
Geth MoarVM: samcv++ created pull request #716:
join: simplify some conditionals and factor out some code		 05:00
samcv MasterDuke, if you can check out my PR. wanted to check with you since you wrote the code 05:01
er or maybe not this code. anyway.
shortens MVM_string_join by 63 lines 05:03
moritz Hashirama: yes, if it's in a place where YAML allows a multi-line string 06:34
eeks, wrong channel, wrong day 06:35
nwc10 good *, moritz 06:36
but it *is* morning :-)
moritz yes *yawn* 06:37
yesterday I submitted my manuscript for the Perl 6 Regexes and Grammars book
brrt \o/ 06:42
good * moritz, ncw10, #moarvm 06:43
Geth MoarVM: a08113ef5e | (Samantha McVey)++ | src/strings/ops.h
Speed up `codes` op by 10% for synthetic graphemes

Use a grapheme iterator instead of a codepoint iterator, since all we need is to get the synthetic information for how many codes are in the synthetic.		 07:56
samcv good * brrt
lizmat good *, #moarvm
talk about a weird flapper: 07:57
Stage start : 0.000
Stage parse : make: *** [CORE.setting.moarvm] Bus error: 10
next make worked fine without change
samcv bus error... never got that before
brrt oh, hmm 08:01
lizmat, can you retry that with a MVM_JIT_EXPR_DISABLE=1 08:02
what platform are you on
lizmat macOS 08:06
brrt: as I said, it was a flapper
couldn't reproduce
brrt should not happen though 08:07
lizmat agree :-)
BTW, I did some tests wrt to the mainline of the core setting: running the mainline takes about 16 milliseconds 08:09
total startup time for me is now about 146 msecs 08:10
which is about 14 msecs up from before the new JIT merge
make spectest for me is up from 353 seconds to 387 seconds 08:12
so it looks like the JIT is not bringing us any performance improvements just yet
OTOH, it did run the whole spectest clean :-)
brrt hmm, that's more than i'd thought 08:16
lizmat yeah... anyways, will be offline for most of the day 08:18
&
dogbert2 tests 38 and 39 in t/spec/S17-promise/lock-async.t are quite slow 11:34
is this another case of, if you don't have 10+ cores then you're out of luck? 11:35
dogbert2 only has six
if I fiddle with github.com/perl6/roast/blob/master...sync.t#L75 i get 11:37
xx 4 => real 1m17.912s , xx 3 => real 0m53.481s, xx 2 => real 0m2.017s and xx 1 => real 0m0.872s 11:38
dogbert2 wonders if the above tests are in need of some more threads, i.e. github.com/rakudo/rakudo/commit/6e...b092d8fc7c 21:04
jnthn How many cores do you have, ooc? 21:05
dogbert2 jnthn: six 21:06
jnthn dogbert2: Run with RAKUDO_SCHEDULER_DEBUG=1 to see how many threads it starts 21:08
dogbert2 is that an env var? 21:09
jnthn Yes
lizmat jnthn: on the subject of attribute default values: if the thunk has a compile time value, would it make sense to generate the BUILDALL with a WVal of that compile time value ? 21:10
dogbert2 tests ...
jnthn lizmat: If the thunk produces one, or? 21:11
afaik the thunk itself is a compile time value
lizmat if the thunk produces one
jnthn Yeah, that'd save a bit of work 21:12
dogbert2 [SCHEDULER] Supervisor thinks there are 6 CPU cores
lizmat ok, then I'll investigate that tomorrow
afk, it was a long tiring day, with another tiring day coming up tomorrow
dogbert2 ok 37 - And can unlock it again 21:13
[SCHEDULER] Added a general worker thread
[SCHEDULER] Added a general worker thread 21:14
the first was started right away, but it took quite some time before the second and third ones
jnthn Ho, interesting...
jnthn Given it thinks about whether to do so 100 times a second... 21:15
dogbert2 feels like it waits ~15 secs before starting the second one (tried to count => unreliable) 21:16
using a clock it's more like +20s 21:18
samcv someone broke windows. src/jit/x64/emit.c 21:47
this line: #line 1 "src/jit/x64/emit.dasc"
line 4
i think our scripts are changing the '/' to \
i guess. they don't even actually need to do that due to C standards though right? 21:48
japhb timotimo: How would I go about showing the actual assembly generated for an NQP or Perl 6 code snippet? Concretely, how would I see the assembly for 'my $i = 1; $i *= 2 while $i < 1000;' for instance? 22:02
timotimo you set the env var MVM_JIT_BYTECODE_DIR 22:05
samcv there's so many ENV vars 22:06
we need documentation on all of them
in one list
timotimo moar --help has them :P 22:07
and perl6 --help
hm, i'm not getting it to output that from the jit 22:09
samcv not all of them though
oh maybe i'm wrong
timotimo okay, i had to run it really often
and then objdump -D -b binary -m i386:x86-64 -M intel jitbytecode/moar-jit-0039.bin 22:10
(i only know this because of my shell history)
japhb "run it really often"? 22:11
Do you mean "wrap it in a loop"? 22:12
timotimo yeah 22:13
i put the code you gave into a sub "test"
and ran test for ^10_000
i might also have turned the number in the code itself up to 10k
it helps to have a jitlog, too, i.e. MVM_JIT_LOG=jitlog.txt 22:15
japhb OK, so: `MVM_JIT_BYTECODE_DIR=./jitbytecode perl6 -e 'for ^10_000 { my $i = 1; $i *= 2 while $i < 10_000; }' && objdump -D -b binary -m i386:x86-64 -M intel jitbytecode/moar-jit-0039.bin`
Ack re: MVM_JIT_LOG
japhb is building all the things 22:16
timotimo well, the exact number for the moar-jit-*.bin you'll find in the jit-map.txt
that lands in the bytecode dir, too
japhb OK ... this is begging to be turned into a mini-tool, methinks 22:17
timotimo oh, you're building something? :) 22:29
it'd be very cool, but at the moment hardly possible, to link which bytecode goes with which part of the assembly 22:30
the tiling of the tree can make that rather messy i imagine
i.e. code belonging to multiple moar instructions getting intermixed
japhb Woah. That's a lot of mov's. Picking a couple .bin files to look at, I'd say around 5 of every 8 instructions are 'mov'. 23:15
I mean sure, that's better than the 2/3 you'd get from doing every 3-arg operation as the sequence 'mov rax, A; op rax, B; mov C, rax' -- but only by ~4%. 23:18
I'd have hoped the tiler would be a bigger win.
Wishlist: jit-map.txt containing enough source location info to be able to look up the correct .bin file for any point in the input. 23:20
timotimo many of the movs probably exist because of the exprjit ending its work in some spot 23:21
and of course also when the exprjit doesn't do parts 23:22
MasterDuke timotimo: did you see my comments about MVM_SPESH_BLOCKING=1 significantly reducing the variability in maxrss reported when building the core setting? 23:28
yoleaux 18:47Z <AlexDaniel> MasterDuke: maybe RT #123926 is for you
synopsebot RT#123926 [new]: rt.perl.org/Ticket/Display.html?id=123926 [BUG] LTA error message without Levenshtein distance suggestion when mistyping enum value in signature in Rakudo
timotimo oh, yes 23:33
that's helpful
i haven't done any more measurements of my fsa tuning branch since i last reported on it
MasterDuke sure, just thought it would be good to know that helps 23:34
timotimo it is!
samcv .tell brrt i think your even_moar_jit branch merge broke the windows build 23:46
yoleaux samcv: I'll pass your message to brrt.
samcv yoleaux, thank you 23:47

Powered by Cro and the Raku® Programming Language.

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

Thank you!