|
00:00
lizmat joined
01:29
zakharyas joined
|
|||
| 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 | |
|
01:55
ilbot3 joined
02:09
geekosaur joined
|
|||
| 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 | |
|
03:17
lizmat joined
|
|||
| 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 | |
|
04:23
lizmat joined
04:27
Ven`` joined
04:49
nativecallable6 joined,
evalable6 joined,
quotable6 joined,
committable6 joined,
bloatable6 joined,
bisectable6 joined,
unicodable6 joined,
greppable6 joined,
benchable6 joined,
releasable6 joined,
coverable6 joined,
squashable6 joined,
statisfiable6 joined
|
|||
| 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 | ||
|
05:31
domidumont joined
05:38
domidumont joined
06:05
brrt joined
06:21
domidumont joined
06:32
leont_ joined
|
|||
| 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 | ||
|
06:46
lizmat joined
07:40
patrickz joined
|
|||
| 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 | |||
|
08:03
evalable6 joined
|
|||
| 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 | |
| & | |||
|
10:13
dogbert2 joined
10:50
brrt joined
11:06
robertle joined
11:32
d4l3k_ joined,
synopsebot joined
|
|||
| 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 | ||
|
12:36
Geth joined
14:07
yoleaux joined
14:12
zakharyas joined
15:16
SourceBaby joined
15:28
zakharyas joined
16:32
buggable joined
16:47
robertle joined
17:16
Ven`` joined
17:18
lizmat joined
18:47
zakharyas joined
19:00
weabot joined
19:06
[Coke] joined
20:54
zakharyas joined
|
|||
| 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... | ||
|
21:15
evalable6 joined
|
|||
| 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 | |
|
22:22
evalable6 joined
|
|||
| 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 | |
|
23:56
geekosaur left
|
|||