[00:56] *** TimToady joined [01:27] *** Ven`` joined [01:54] *** ilbot3 joined [06:10] *** domidumont joined [08:25] *** robertle joined [08:41] morning o/ [08:42] good *, jnthn [08:45] *** mtj_ joined [08:53] jnthn++ # blog post [09:20] *** zakharyas joined [10:20] will the new scheduler make an entrance today? [10:22] and/or should we merge the new libuv? [10:23] dogbert17: New scheduler already merged :) [10:23] And yeah, now is a good time on the new libuv [10:24] oh, I missed that merge [10:25] Yay, I seem to have a working async locking mechanism [10:25] https://gist.github.com/jnthn/6f4a2258092a7fac7f80056a982e8003 [10:25] dogbert17: also looking forward to new libuv [10:26] .oO( newer is betterder, right? ) [10:26] jnthn: s/hich/which [10:26] lizmat: let's hope so :) [10:26] ¦ MoarVM: bbfb436f3e | (Jan-Olof Hendig)++ | 3rdparty/libuv [10:26] ¦ MoarVM: Bump libuv to ver. 1.14.1 [10:26] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bbfb436f3e [10:26] ¦ MoarVM: 5684e4f366 | (Jonathan Worthington)++ (committed using GitHub Web editor) | 3rdparty/libuv [10:26] ¦ MoarVM: Merge pull request #682 from dogbert17/update-libuv [10:26] ¦ MoarVM: [10:26] ¦ MoarVM: Bump libuv to ver. 1.14.1 [10:26] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5684e4f366 [10:26] cool [10:27] dogbert17: should I do an nqp/rakudo bump, or is that too early ? [10:28] wait a bit, I wonder if this went the way I hoped, hmm [10:28] * jnthn is doing a local build [10:28] It all looks sensible so far: on pull, I ended up with an update to the submodule, and when it built MoarVM it rebuilt libuv [10:29] Onto Rakudo build now [10:29] jnthn: what is the significance of "= Holder" in "has Holder $!holder = Holder" ? [10:29] N [10:29] lizmat: Variables must be explicitly initialized if you use cas [10:29] ah, ok [10:30] Thanks to our various bits of laziness to avoid allocations [10:30] Which makes me wonder if those are really a good idea :P [10:30] yeah, I was scared at first, after doing a git pull, and I failed to see the new files [10:30] but now they're there :) [10:31] Yeah. spectesting but so far so good [10:31] Rakudo test passed [10:31] * dogbert17 also spectesting :) [10:31] jnthn: since you're using nqp in the gist, is there a reason you use =:= instead of nqp::eqaddr ? [10:32] 'cus I trust in inlining :P [10:32] jnthn: suspect you have more cores than I have on my $work comp (4) [10:32] Also I find code full of nqp:: ops hard to read [10:32] And hard to read is the last thing I want when implementing a lock-free data structure :P [10:32] well, in my experience =:= badly inlines because of its megamorphicness [10:33] or has that changed ? [10:33] It should be better now [10:33] In theory at least :) [10:33] In practice would have to check :) [10:34] dogbert17: spectest ok here [10:36] Just tested: nqp::eqaddr is about 1.6x faster, but I think that's mainly because it needs do boolification [10:36] *it being =:= [10:36] Yeah [10:37] I can live with that for now :) [10:44] jnthn: looks good here in 32 bit land as well :) [10:45] quite a few changes since 1.8, https://github.com/libuv/libuv/blob/v1.x/ChangeLog [10:48] Indeed [10:49] * dogbert17 wonders if Cygwin will work now [11:01] ¦ MoarVM: 6ef763b3a8 | MasterDuke17++ | 2 files [11:01] ¦ MoarVM: Add MVM_fixed_size_realloc [11:01] ¦ MoarVM: [11:01] ¦ MoarVM: Also add an _at_safepoint version. [11:01] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6ef763b3a8 [11:01] ¦ MoarVM: ece0c5f7c4 | (Jonathan Worthington)++ (committed using GitHub Web editor) | 2 files [11:01] ¦ MoarVM: Merge pull request #688 from MasterDuke17/add_realloc_to_fsa [11:01] ¦ MoarVM: [11:01] ¦ MoarVM: Add MVM_fixed_size_realloc [11:01] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ece0c5f7c4 [11:07] dogbert17: Maybe, though I don't care to be the person who finds out :-) [11:08] I'm sure somebody will try it :) [11:17] *** lizmat joined [11:24] *** leont joined [12:00] *** AlexDaniel joined [12:31] *** travis-ci joined [12:31] MoarVM build errored. Jonathan Worthington 'Merge pull request #688 from MasterDuke17/add_realloc_to_fsa [12:31] https://travis-ci.org/MoarVM/MoarVM/builds/276801107 https://github.com/MoarVM/MoarVM/compare/5684e4f3668d...ece0c5f7c4b1 [12:31] *** travis-ci left [12:32] *** buggable joined [12:37] apt install error, it seems [13:11] *** buggable joined [13:20] *** buggable joined [14:45] *** erratum joined [15:21] *** buggable joined [15:23] *** buggable joined [15:24] *** Geth_ joined [15:27] *** Geth_ joined [15:29] *** Geth_ joined [15:30] *** Geth_ joined [15:44] *** buggable joined [15:50] *** buggable joined [15:51] *** buggable joined [16:28] ¦ MoarVM: 1afedf5188 | (Jonathan Worthington)++ | src/core/threads.c [16:28] ¦ MoarVM: Stash native thread ID after GC unblock [16:28] ¦ MoarVM: [16:28] ¦ MoarVM: Otherwise the thread object inside of the thread context may be an [16:28] ¦ MoarVM: outdated pointer due to an ongoing GC run, and thus the stored native [16:28] ¦ MoarVM: thread ID will be to an invalid location. [16:28] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1afedf5188 [16:36] ¦ MoarVM: 1959f2ff2e | (Jonathan Worthington)++ | 3 files [16:36] ¦ MoarVM: Make native callback thread finding more robust [16:36] ¦ MoarVM: [16:36] ¦ MoarVM: While the bug fixed in the commit prior to this one was the major [16:36] ¦ MoarVM: cause of failing to find the correct thread, there was also a race on [16:36] ¦ MoarVM: looking through the thread list. Fix that here also. [16:36] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1959f2ff2e [16:37] *** Ven`` joined [16:51] ¦ MoarVM: eeb664ea65 | (Jonathan Worthington)++ | 4 files [16:51] ¦ MoarVM: Factor out callback thread finding [16:51] ¦ MoarVM: [16:51] ¦ MoarVM: This means the fixed version is now shared between both the dyncall [16:51] ¦ MoarVM: and libffi codepaths. [16:51] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/eeb664ea65 [16:52] Looks quite nice now :) [16:52] *** robertle joined [16:53] Shoulda probably have had it factored out that way in the first place :) [17:03] *** Ven`` joined [17:06] looks like libuv 1.14 added a uv_fs_filecopy(), which uses the CopyFile API on windows. Maybe MVM_file_copy could use that? [17:06] er, _copyfile [17:07] https://github.com/MoarVM/MoarVM/blob/df404cab9899bec5ca0cfc174dcfe3596cd38abe/src/io/fileops.c#L122 (note the comment mentions the CopyFile api) [17:17] *** Skarsnik joined [17:26] *** buggable joined [17:43] *** Skarsnik_ joined [17:50] i am testing such a change on various os [18:46] *** buggable joined [18:55] *** committable6 joined [18:55] *** bloatable6 joined [18:55] *** coverable6 joined [18:55] *** nativecallable6 joined [18:55] *** quotable6 joined [18:55] *** greppable6 joined [18:55] *** releasable6 joined [18:55] *** bisectable6 joined [18:55] *** unicodable6 joined [18:55] *** squashable6 joined [18:55] *** evalable6 joined [18:55] *** benchable6 joined [18:55] *** statisfiable6 joined [19:08] ⚠ Rakudo SQUASHathon 2017-10-07 https://github.com/rakudo/rakudo/wiki/Monthly-Bug-Squash-Day [19:15] ¦ moarvm.org: a6a039d539 | jnthn++ | 2 files [19:15] ¦ moarvm.org: Update for 2017.09 release [19:15] ¦ moarvm.org: review: https://github.com/MoarVM/moarvm.org/commit/a6a039d539 [19:19] Goodness, a lot got done in the last couple of releases. [19:22] * jnthn didn't even do very much last month, and still loads got done :D [19:22] Really nice work, everyone <3 [19:22] yeah, it really adds up :-) [19:34] Oh... when ncinvoke_o is JITed, the arg_* ops are pretty much superfluous. They'd just copy registers. I can instead just access the WORK registers directly. Just like my previous implementation did. [19:37] So I'd end up with pretty much the same assembly code as the previous implementation. But now I don't need conventions or special cases in spesh :) [19:40] convergence! [19:40] I just love these moments when things come together so beautifully :) [19:41] * lizmat lights a cigar [19:42] https://www.youtube.com/watch?v=XwozVKOkzz4 [19:43] lizmat: exactly :) [19:44] nine: Yes :-) [19:46] ¦ MoarVM/jit_nativecall: 48a5823b31 | (Stefan Seifert)++ | 4 files [19:46] ¦ MoarVM/jit_nativecall: Bring back JITing of ncinvoke_o [19:46] ¦ MoarVM/jit_nativecall: [19:46] ¦ MoarVM/jit_nativecall: Since at this stage the code calling the ncinvoke_o op cannot change anymore, [19:46] ¦ MoarVM/jit_nativecall: we can access the WORK registers directly, saving the copying of those to [19:46] ¦ MoarVM/jit_nativecall: tc->cur_frame->args. [19:46] ¦ MoarVM/jit_nativecall: review: https://github.com/MoarVM/MoarVM/commit/48a5823b31 [19:47] So what looked like loads of work yesterday turned out to be less than five minutes today. Good thing, cause I spent most of my evening watching youtube videos about theoretical physics ;) [19:48] heh, for me it's astronomy :-) [19:51] <[Coke]> numberphile and twitch, here. :) [19:55] https://www.youtube.com/playlist?list=PL8dPuuaLjXtPAJr1ysd5yGIyiSFuh0mIL if anybody needs inspiration :-) [20:12] Ok, numbers look the same as the previous version for 10000 iterations and apparently better than before for 100000. [20:15] Actually I measured 100_000 vs. 1000_000 iterations [20:18] any benchmarks to see how pre vs post jit-nativecall performance is? [20:19] Indeed, results seem consistent. So far I've got 44.221s for the latest code vs. 45.530s for the cheating one (best runs of several with 1_000_000 iterations) [20:20] it's something ^^ [20:20] what does your benchamrk look like? csv with inline::perl5? [20:20] timotimo: yes, csv-ip5xs.pl [20:21] You could run a parse-html of Gumbo on a big html file (with lot of element) [20:21] there is a function called for each html elements [20:22] Numbers with the new JIT turned off coming up soon. Btw. keep in mind that so far only native calls with arguments that are integers or pointers are JITed. [20:22] No strings and no rw args. [20:22] hm will be Str [20:22] that's a big percentage of 'em [20:23] if by pointers you include structs for example [20:23] Inline::Perl5 uses rw args on several calls (invoke among them) and CSV is about strings. So I guess about half of the calls are actually JIT compiled. [20:23] * jnthn wonders what this'll do to IO::Socket::Async::SSL perf :) [20:24] hm why Str can't be JIT? [20:24] just won't do it yet [20:24] Skarsnik: I think it's just "not done yet", not "can't be" :) [20:24] Hoo alright [20:24] Skarsnik: unmarshalling of strings is more complicated as I need to call C functions. So I can't do it in the middle of setting up arguments for the actual function call. [20:25] So yes, needs some more work. A simple first step would be to support one string argument by simply processing it first, before the other arguments. [20:25] jnthn: should spesh be able to turn wval + getattr_o into a faster op? i was looking at permutations the other day and it refered to $!next a few times and had a whole bunch of code for it each time [20:25] even though i think it should have been able to use a sp_p6oget_o or what it's called for it [20:26] Much of the time it can be turned into a spesh op like that, yes [20:26] Check the facts to see why it can't be in this case, I guess ;) [20:26] *:) [20:26] right [20:30] huh, 0 flags [20:32] 47.397s without JITing. So JITing gives a 7 % speedup. [20:32] sp_getarg_o r9(2), liti16(0) [20:32] r9(2): usages=1, flags=13 KnTyp Dcntd Concr DeadWriter [20:32] that doesn't fit, does it? [20:34] the other registers that get their values from this one don't have DeadWriter [20:35] oh, could it be ... [20:35] r0(3) is being merged together by, among others, itself [20:35] we probably don't have anything in the code for that to not say "oh, we know nothing about this!" [20:43] well, that certainly did nothing at all [20:44] we would pobably have to iterate to a fix point to get phi merged facts proper in jump-backwards-situations? [20:50] ¦ MoarVM/jit_nativecall: 18 commits pushed by (Stefan Seifert)++ [20:50] ¦ MoarVM/jit_nativecall: review: https://github.com/MoarVM/MoarVM/compare/48a5823b31...0d162dbf1c [20:52] hm. a PHI with arguments we have no facts for, but where we know that they are written to by a PHI, those could benefit from doing a full-graph search i think [20:53] except we have the writers directly available right then and there [20:54] * timotimo rolls up imaginary sleeves [21:01] libuv uv_fs_copyfile does not use O_TRUNC on the destination handle, copying a file with "A" into a file with "XXX" results with "AXX" [21:02] on linux. on osx it results in "A" [21:05] i can't seem to compile moarvm on freebsd [21:05] it's failing when trying to compile libatomic [21:06] maybe we need a version bump in libatomic for that? [21:06] yeah hold on. trying to build again without -j [21:07] ok it didn't fail that. i get undefined reference to uv__hrtime [21:08] looks like it was a build parallization issue on freebsd with libatomic. but i am getting it not linking properly [21:11] I wonder if google has arm VM x) [21:41] and yet another Perl 6 Weekly hits the Net: https://p6weekly.wordpress.com/2017/09/18/2017-38-color-me-booked/ [21:44] lizmat++ [21:46] samcv: any thoughts about Reini's blog posr re Perl 6 ? [21:47] it feels he's not up to date with all of your latest work [21:51] yeah [21:52] other than namedropping perl6 it was a good article [21:52] just need to delete one word and then add a paragraph saying perl 6 is the best :) [21:52] well, please tell him :-) You're the person of authority here :-) [21:54] Given Perl 6 normalizes everything at input, I'm not sure why it'd not be doing this right [22:07] https://i.imgur.com/9YzmQ1F.png heaptrack report for that script that had high memory use a little while ago [22:09] https://imgur.com/zD2CfJm ~10 days ago to compare [22:12] Nice reduction :) [22:12] New scheduler can be thanked for starting less threads :) [22:13] yeah, quite dramatic [22:14] AlexDaniel: ^^^, might be time to rebuild rakudo on the *able server [22:28] rest time o/ [22:35] ¦ MoarVM: 43d6af05db | (Samantha McVey)++ | .appveyor.yml [22:35] ¦ MoarVM: Try and enable and build matrix with Appveyor [22:35] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/43d6af05db [22:41] ¦ MoarVM: 2824dcf8fc | (Samantha McVey)++ | .appveyor.yml [22:41] ¦ MoarVM: Trigger Appveyor build [22:41] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2824dcf8fc [22:41] yay it works! [22:41] https://ci.appveyor.com/project/samcv/moarvm-35u74 [22:42] msvc 2015 and 2017 x64 and x86 matrix [22:42] \o/ [22:45] nice [22:47] uh windows is failing as well linking libuv [22:50] freebsd too [22:56] yeah reverting the libuv bump fixes building on freebsd [22:58] that sucks. anything in libuv release notes about freebsd? [23:05] well it fails on windows too [23:06] MasterDuke: botacalypse again? I just did that todayy… [23:07] think of the ram savings! [23:07] are you thinking that things like this will not leak anymore [23:08] c: eonhuotueh say 42 [23:08] AlexDaniel, ¦eonhuotueh: «Cannot find this revision (did you mean “Karlsruhe”?)» [23:08] c: eonhuotueh say 42 [23:08] AlexDaniel, ¦eonhuotueh: «Cannot find this revision (did you mean “Karlsruhe”?)» [23:08] c: eonhuotueh say 42 [23:08] AlexDaniel, ¦eonhuotueh: «Cannot find this revision (did you mean “Karlsruhe”?)» [23:08] leak less [23:08] c: foo say 42 [23:08] AlexDaniel, ¦foo: «Cannot find this revision (did you mean “all”?)» [23:08] c: abc242 say 42 [23:08] AlexDaniel, ¦abc242: «Cannot find this revision (did you mean “b1c412a”?)» [23:08] c: abc242 say 42 [23:08] AlexDaniel, ¦abc242: «Cannot find this revision (did you mean “b1c412a”?)» [23:08] c: abc242 say 42 [23:08] AlexDaniel, ¦abc242: «Cannot find this revision (did you mean “b1c412a”?)» [23:08] but even this is no longer leaking [23:09] greppable6: password [23:09] AlexDaniel, https://gist.github.com/a6099a830ea3271c6458de894a987a51 [23:09] greppable6: password [23:09] AlexDaniel, https://gist.github.com/ea12f53147bae44a265d85e65ad3fdd9 [23:09] OK, this does. [23:10] libuv compiles fine if i cd into 3rdparty/libuv and run ./autogen.sh and then ./configure then make [23:13] windows fix looks easy enough [23:16] did they add a new file or something? [23:17] looks like i need to add a file for bsd [23:17] *** quotable6 joined [23:17] *** coverable6 joined [23:17] *** nativecallable6 joined [23:18] *** greppable6 joined [23:18] *** releasable6 joined [23:18] *** bloatable6 joined [23:18] *** committable6 joined [23:18] *** bisectable6 joined [23:18] *** evalable6 joined [23:18] *** statisfiable6 joined [23:18] *** unicodable6 joined [23:18] *** squashable6 joined [23:18] *** benchable6 joined [23:19] *** committable6 joined [23:19] *** greppable6 joined [23:19] MasterDuke: I see no change [23:19] at least nothing noticeable to human eye [23:22] ¦ MoarVM: ugexe++ created pull request #694: Pass user32 lib to build on windows [23:22] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/694 [23:22] ¦ MoarVM: dfbf9df7b6 | (Samantha McVey)++ | build/Makefile.in [23:22] ¦ MoarVM: Fix FreeBSD build by adding new libuv file to Makefile.in [23:22] ¦ MoarVM: [23:22] ¦ MoarVM: FreeBSD build broke after bumping libuv. Add the new file to Makefile.in [23:22] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/dfbf9df7b6 [23:22] yay bulid fixed [23:22] going thing i decided to install freebsd [23:32] samcv: heaptrack thinks MVM_string_join (src/string/ops.c:1704) leaks. see anything obvious? [23:32] uh [23:33] i don't think it allocates anything that isn't attached to a string afaik [23:33] do we know where it is donig the allocation? [23:33] 1704 is where heaptrack thinks it's happening [23:35] well that gets attached to a string. maybe the GC just hasn't reclaimed it yet? idk [23:35] hm. i was using --full-cleanup, but i guess i can try adding some nqp::force_gc()'s and see if that changes anything [23:36] https://github.com/MoarVM/MoarVM/pull/694 fixes the windows build [23:39] ¦ MoarVM: cabfefe2f2 | (Nick Logan)++ (committed using GitHub Web editor) | build/setup.pm [23:39] ¦ MoarVM: Pass user32 lib to build on windows [23:39] ¦ MoarVM: [23:39] ¦ MoarVM: See: https://github.com/libuv/libuv/commit/e51442bbc9b37dff32430c047844d9181798a9a8#diff-67e997bcfdac55191033d57a16d1408aR62 [23:39] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cabfefe2f2 [23:39] ¦ MoarVM: eabfc24273 | (Samantha McVey)++ (committed using GitHub Web editor) | build/setup.pm [23:39] ¦ MoarVM: Merge pull request #694 from ugexe/patch-1 [23:39] cool. thanks ugexe [23:39] ¦ MoarVM: [23:39] ¦ MoarVM: Pass user32 lib to build on windows [23:39] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/eabfc24273 [23:55] --with-ffi fails on freebsd. need to fix that