| Geth | MoarVM/collation-arrays: 9 commits pushed by (Samantha McVey)++
|
00:25 | |
|
01:52
ilbot3 joined
|
|||
| samcv | was confused at why this particular test was failing. i guess we have incorrect property value for 2B81E. | 01:54 | |
| m: 0x2B81E.uniprop('Unified_Ideograph').say | |||
| camelia | True? | ||
| samcv | at least the unicode site says that should be False | ||
| ahh | 01:57 | ||
| 2B740..2B81D ; Unified_Ideograph | |||
| m: 0x2B81F.uniprop('Unified_Ideograph').say | |||
| camelia | True? | ||
| samcv | hmm i wonder how many we have that incorrect | ||
| hmm not sure what i did with the C macro. turning it into a function for now just so no errors | 03:46 | ||
| Geth | MoarVM/collation-arrays: 8dd36c2ad5 | (Samantha McVey)++ | src/strings/unicode_ops.c Create is_unified_ideograph() and use func for gen. coll values Use functions to simplify things. I was going to make them macros but the C preprocessor did not seem to like it. Add is_unified_ideograph() because there are some incorrect values for this value in the MVM data. |
03:50 | |
|
05:36
AlexDaniel joined
06:17
domidumont joined
06:47
domidumont joined
06:48
brrt joined
|
|||
| brrt | good * #moarvm | 06:48 | |
|
06:50
domidumont joined
|
|||
| brrt | lizmat++ for p6weekly | 06:54 | |
| samcv | good * brrt | 07:02 | |
| brrt | ohai samcv | ||
| ehm, have you seen the perl conference schedule? | |||
| stuff looks weird | 07:03 | ||
| talks splitted | |||
| samcv | i haven't yet | ||
| i couldn't find my 2nd talk on Thursdays page hmm. but it says so if i look on my page | 07:05 | ||
| brrt | yeah, it's on thursday | 07:07 | |
| Geth | MoarVM: a052a3338b | (Jimmy Zhuo)++ | 3rdparty/tinymt/tinymt64.c Update TinyMT to version 1.1 BUG fix of floating point conversion. In version 1.0.3 tinymt64_generate_double() may return 1.0 |
07:32 | |
|
07:40
zakharyas joined
07:53
FROGGS joined
08:38
robertle joined
|
|||
| jnthn | morning o/ | 08:52 | |
| brrt | moarning jnthn | 09:04 | |
| jnthn | hi brrt | 09:05 | |
| You'll be glad to know that the JIT Just Worked after being moved to a background thread :) | 09:06 | ||
| Hopefully it'll be the same story for the expr JIT | |||
| brrt | i am glad to know that | ||
| jnthn | Also hope the merge won't be hell... :) | ||
| brrt | for the expr jit, or for the spesh worker? | 09:07 | |
| jnthn | Good news is that some of the more gnarly guards are gone | ||
| brrt | \o/ | ||
| jnthn | Oh, for spesh worker into master it'll be easy | ||
| For master with spesh-worker merged then into expr jit is what I meant :) | |||
| brrt | yeah, makes sense | ||
| jnthn | If it's really ugly I can look at it, but hopefully... :) | ||
| brrt | well, i'm not super worried as the branch is reasonably up to date | 09:08 | |
| the only big mistake i made was to refactor some parts of the jit graph builder in expr jit but not in master | |||
| which means i need to patch that up when i merge | |||
| jnthn | ah, OK | 09:09 | |
| I didn't do any significant changes to the JIT, just minor bug fixes | |||
| Most of which weren't spesh-worker related anyway | |||
| Just uncovered by it | |||
| brrt | alright. when are you planning to merge? | 09:10 | |
| wrt the expr jit, i was going to say, 'lets merge this month', but i'm a little less confident now that i've found bugs in the win64 version | 09:11 | ||
| jnthn | brrt: I'm happy with the branch now in terms of it not having bugs (I suspect it's got less spesh bugs than master) | 09:12 | |
| brrt | hehe | ||
| jnthn | brrt: I'm less happy that CORE.setting compilation time is 15% longer on the branch :/ | 09:13 | |
| samcv | m: say 31/190377 * 100 | ||
| camelia | 0.0162835? | ||
| samcv | so i've achieved 0.016% failing tests with my collation-arrays branch :) | ||
| jnthn | samcv++ | ||
| brrt | progress, yay | ||
| jnthn, any idea why? synchronization overhead? | 09:14 | ||
| samcv | got proper recursion implemented as well so it passes back to the same function nonmatching codeponits | ||
| jnthn | brrt: I don't think it'd be that | 09:15 | |
| samcv | so right now i'm working on rewriting the code that generates the extra collation data. interestingly there were lots of errors in it. things like i'd watch the debug printing | ||
| would see it go from A->B in the nodes. then check the unicode raw data. then notice that doesn't exist | |||
| but it must have pushed the collation data for A+B onto it even though it wasn't a sequence. | |||
| jnthn | brrt: Or at least, nothing suggests that in profile data | 09:16 | |
| samcv | i still can't figure out how the hell that happened. but rewriting that code and making decent progress on that as well | ||
| i mean it's complicated enough that i had a not perfectly tidy piece of code and got it only failing 120/190377. then threw out a ton of code | 09:17 | ||
| since i knew even though it passed pretty well it didn't have actual recursion. it would just "fake it" and get the naive values of single codepointns and not do actual recursion | |||
| and got it generating data for many Tangut, Unified Ideograph, Unified Ideograph and in in one of two particular blocks. plus an unassigned one for unassigned codepoints | 09:18 | ||
| so we have wrong data for Unified_Ideograph property. i'm not sure how but it extends too far | 09:19 | ||
| and i checked the data. so there's something wrong in the current UCD. may not get to a whole rewrite of the unicode database for this grant. but i may do it after the grant is complete in my own time. it's something i don't really want to rush anyway | 09:20 | ||
| and replacing it won't have as big a user facing impact as these other things | |||
| nine | jnthn: correctness trumps speed, doesn't it? | ||
| brrt | correctness++ | 09:21 | |
| jnthn | nine: Yes, which is why I spent the last days getting it correct before looking into the speed thing :) | ||
| brrt | (also, when I read samcv++s unicode work, i kind of feel how some of you must feel when i'm rambling about the JIT :-)) | 09:22 | |
| samcv | that's how i feel reading about JIT heh | ||
| though i'd love to learn how the JIT works sometime :-) | |||
| after my current project at least | |||
| also. i will have collation working for a demo at the conference. which is neat. i had been trying to make sure i had a working full UCA implementation | 09:23 | ||
| so feel pretty great about that | |||
| hopefully other people will think it's amazing that you can sort æ with ae and ? with ffi | 09:24 | ||
| <fri a ? dri z ffi>.collate.say # (a dri ffi ? fri z) | 09:27 | ||
| amazing | |||
| nine | samcv: it is :) | ||
| samcv | jnthn, so compiling the CORE.setting is slower with JIT in a background thread — but it's faster when you actually run things? y/n | 09:30 | |
| brrt | (well, drop by my talk, and you'll know everything ;-)) | ||
| samcv | yay | ||
| jnthn | samcv: Didn't do enough measurements to say conclusively yet, tbh | ||
| Though certainly I've seen cases where, because it's done on a background thread, the foreground one just completes the work before the opt is ready, which is likely a win :) | 09:31 | ||
| Well, seems the issue isn't that the JIT inserts the SC write barrier checks at least, tossing those out to try it doesn't help | 09:36 | ||
| dogbert17 ran a stresstest with latest spesh-worker, looks good, only t/spec/S17-promise/nonblocking-await.t causes problems (MoarVM panic: Adding item to past fromspace to GC worklist). | 09:44 | ||
| jnthn | Yeah, that one is flappy in master too | 09:45 | |
| dogbert17 | and there's already an issue for it. I guess it has nothing to do with spesh | ||
| jnthn | No | ||
| heh, decided to callgrind the CORE.setting compilation to see if I get more useful data than perf | 09:46 | ||
| This is taking a little time :) | |||
| jnthn notes that with the spesh worker on a background thread we now always have user threads | 09:48 | ||
| So could save the checks on that in a few places since the answer is always "yes" now | 09:49 | ||
| Hm, if valgrind's right then the long-standing GC sync-up issue is part of it | 09:56 | ||
| Though it's hard to tell how much of that is/isn't its due to how valgrind serializes things onto one thread | 09:57 | ||
| Also a lot of time in the (slow) get_attribute which makes we wonder if we're somehow doing a less good job of lowering those | 09:58 | ||
|
10:03
brrt joined
|
|||
| Geth | MoarVM/spesh-worker: 0930889d10 | (Jonathan Worthington)++ | 3 files We always have threads now; skip checks. The spesh worker thread counts as a thread, since it uses the fixed size allocator. So, the paths for "not threaded" are never taken any more. Toss those and the checks that go with them, which at least gets rid of the branching cost. |
10:04 | |
| MoarVM/spesh-worker: 564b2fd593 | (Jonathan Worthington)++ | src/spesh/worker.c Log time waiting for logs. |
|||
| brrt | jnthn: since we currently still need perl for a fresh build anyway, and since strawberry perl ships a competent gcc environment anyway.... | 10:59 | |
| we couild consider dropping support for msvc | |||
| without loss of windows support | 11:01 | ||
| not saying we should | |||
|
11:29
JimmyZ joined
|
|||
| JimmyZ | brrt: not everyone uses strawberry perl :) | 11:30 | |
| dogbert17 | tested a multi threaded program against current MoarVM and spesh-worker, there's a 10+ percent performance loss | 11:31 | |
| JimmyZ | brrt: maybe use activeperl | ||
| dogbert17 is still on 32 bit ... | |||
|
11:33
brrt1 joined
|
|||
| brrt1 | JimmyZ, dogbert17: well, you're just wrong :-P | 11:33 | |
| Geth | MoarVM/spesh-worker: 9bdff8d4e0 | (Jonathan Worthington)++ | 10 files Add non-logging variants of ops and use them. For the case where we can't JIT the frame. This keeps us from needing to check if we need to log every time. |
11:35 | |
| MoarVM/spesh-worker: f4cce975a9 | (Jonathan Worthington)++ | src/core/frame.c Don't take entry logging path when no spesh log. This could impede data collection for some frames by bumping the logged entries counter up when not actually logging data. |
|||
| MoarVM/spesh-worker: 0c7b13239e | (Jonathan Worthington)++ | src/spesh/log.h From measurement, fewer but larger logs are better 8192 is a notable improvement for 4096, and 16384 is a little better still. At that size, 2 logs outstanding seems to be better than 1, and about tied with 3, so may as well take the better memory use and drop it down to 2. |
|||
| brrt1 | i mean, in seriousness | ||
| we continue to invest a lot of effort into working arround msvc, which basically doesn't care about the language we're using | 11:36 | ||
| moritz | doesn't jnthn develop with msvc? | 11:37 | |
| nine | brrt: would it be possible to compile the code in C++ mode? AFAIK that supports modern C much better | ||
| brrt | that would still leave us with a makefile that has to work arround nmake | 11:38 | |
| but yes, we could try that | |||
| and istr that jnthn does his work in a linux vm these days | |||
|
12:00
stmuk joined
|
|||
| timotimo | nine: if by "in c++ mode" you mean "use msvc++ instead", then ... maybe | 12:06 | |
| jnthn | When I do work on Windows, though, it's with MSVC | 12:14 | |
| Largely 'cus I know the tools well, and like the debugger | |||
| It's not likey I'll do windows dev at all if we drop MSVC support. | 12:15 | ||
| timotimo | any particular reason to stay with msvc instead of msvcpp? | 12:16 | |
| JimmyZ | MSVC does have a good debugger UI :) | ||
| timotimo | microsoft keeps telling people who complain about msvc to use msvcpp instead, i believe? | ||
| JimmyZ | but still have nmake | 12:18 | |
| timotimo | at least it lets us put variable declarations in for loop headers | ||
| JimmyZ | even you use msvcpp | ||
| so someone hates nmake and someone hates variable declaration? | 12:19 | ||
| jnthn | timotimo: msvcpp | 12:24 | |
| oops | |||
| timotimo: msvcpp could be worth a try though if it makes us wrap everything in extern C or something... | |||
| timotimo | i don't think it will | 12:25 | |
| i'd expect you can give it .c files and it'll behave itself | |||
| jnthn | Well, worth a try if somebody fancies :) | 12:26 | |
| timotimo | i don't have a msvcpp :) | ||
| JimmyZ | I did have but nmake does'nt support -j | 12:27 | |
| timotimo | of course it doesn't | ||
| but you can "set CL=/MP" so it "will use all the CPU cores" | 12:28 | ||
|
12:28
domidumont joined
|
|||
| jnthn | win 23 | 12:28 | |
| buggable | jnthn, Thank you for entering Accidental /win Lottery! The next draw will happen in 6 days, 11 hours, 31 minutes, and 7 seconds | ||
| timotimo | but that seems to require that you put many .c files into the same commandline | 12:29 | |
| whereas we have one invocation of the compiler for .o file we want to create | |||
|
12:30
domidumont1 joined
|
|||
| dogbert17 | spesh-worker and --profile seems to be a less than optimal combination atm | 12:42 | |
| brrt | oh, what is worse, is linking though | 12:53 | |
| jnthn | dogbert17: How so? | 12:57 | |
| The profiler is certaily gonna be out of date with regard to some things though, I susepct | |||
| For one, there's no spesh time any more since it's done on a background thread. | |||
| dogbert17 | jnthn: immediate SEGV | 13:03 | |
| setting MVM_SPESH_DISABLE=1 restores functionality | 13:04 | ||
| e.g. the following SEGV's, perl6 --profile -e 'say "Hello World!"' | 13:05 | ||
| here's the gist of the matter, gist.github.com/dogbert17/13246b92...56ad910d68 | 13:13 | ||
| Geth | MoarVM/spesh-worker: 6ff2b3c525 | (Jonathan Worthington)++ | 4 files Simplify our dealings with the thread list. Just take a lock for the cases where we need to update or snapshot it. This eliminates a low-benefit, and diffult to reason about, lock-free appraoch in the GC orchestration, making for far simpler code there. It also disentangles it a bit from the GC start flag handling, which will be getting a refactor shortly to try to improve its resource usage. |
13:40 | |
| jnthn | It's apparently difficult to type difficult... | 13:41 | |
| dogbert17 | appraoch :) | 13:42 | |
| jnthn | bah | ||
| Geth | MoarVM/spesh-worker: 5e2ac66028 | (Jonathan Worthington)++ | 4 files Simplify our dealings with the thread list. Just take a lock for the cases where we need to update or snapshot it. This eliminates a low-benefit, and difficult to reason about, lock-free approach in the GC orchestration, making for far simpler code there. It also disentangles it a bit from the GC start flag handling, which will be getting a refactor shortly to try to improve its resource usage. |
13:43 | |
| jnthn | It's my branch and I can force if I want to... :P | ||
| I've figured I'll take on the GC orchestration changes now | 13:44 | ||
| Because every time I try to callgrind something concurrent it distorts it a good bit | |||
| Plus it really does cause performance issues | 13:45 | ||
| Possibly accounting for some of the slowdown we're seeing | |||
|
13:53
zakharyas joined
13:59
zakharyas joined
14:38
FROGGS joined
|
|||
| Geth | MoarVM/spesh-worker: 4 commits pushed by (Jonathan Worthington)++ | 14:52 | |
|
14:52
zakharyas joined
|
|||
| jnthn | There we go | 14:53 | |
| yoleaux | 13:51Z <zengargoyle> jnthn: is that concurrency talk/slides supposed to be not shared around? | ||
| jnthn | Unfortunately, not much difference to see in CORE.setting build time, though wins back a bit on make spectest. Will surely win something off various more real-world threading code that I've seen end up paying a lot in the GC orchestration. | 14:55 | |
| Hopefully the callgrind output will be more sensible also | |||
| Recording some now | |||
|
15:06
AlexDani` joined
|
|||
| jnthn | Yeah, looks rather better | 15:07 | |
|
15:08
brrt joined
|
|||
| [Coke] | jnthn++ | 15:11 | |
|
15:14
zakharyas joined
|
|||
| jnthn | Some intesting hotspots, though none really shining a light on the spesh changes | 15:46 | |
| Leaving a callgrind run going, anyways, so I'll have a complete one to look at in the morning | |||
| Also one local change to try and make a things a bit better, but inconclusive so far | 15:47 | ||
|
16:16
AlexDani` joined
|
|||
| timotimo | here's something i find a bit puzzling | 16:35 | |
| the statistics for lower_signature | |||
| almost every offset has two different things it might have logged: | |||
| a) some kind of QAST:: node | |||
| b) a BOOTCode | 16:36 | ||
| apparently always in exact same amounts each | |||
| is something wonky with regards to logging? | 16:37 | ||
| something very similar happens in install_lexical_symbol. this time it's observable across a whole bunch of Type Tuples | 16:48 | ||
| gist.github.com/timo/374ae300d4abd...1be5e4131a | 16:49 | ||
| the more i look the more often i see these bootcode pieces sprinkled around | 16:50 | ||
|
17:18
zakharyas joined
17:46
zakharyas joined
18:38
domidumont joined
|
|||
| jnthn | timotimo: Is it a BOOTCode value and a QAST::Node type ooc? | 18:50 | |
| iirc invoke logs the return type and the invoked value | 18:51 | ||
|
19:11
brrt joined
|
|||
| timotimo | ooooh | 19:13 | |
| well, then that's it, and not as surprising as i thought | |||
|
20:24
zakharyas joined
20:32
camelia joined,
eater joined
|
|||
| samcv | good * | 20:32 | |
| timotimo | good | ||
| samcv | * | 20:38 | |
|
20:42
robertle joined
|
|||
| jnthn | o/ samcv | 20:42 | |
|
21:18
jpf4 joined
22:37
TimToady joined
|
|||