00:56 TimToady joined 01:27 Ven`` joined 01:54 ilbot3 joined 06:10 domidumont joined 08:25 robertle joined
jnthn morning o/ 08:41
nwc10 good *, jnthn 08:42
08:45 mtj_ joined
lizmat jnthn++ # blog post 08:53
09:20 zakharyas joined
dogbert17 will the new scheduler make an entrance today? 10:20
and/or should we merge the new libuv? 10:22
jnthn dogbert17: New scheduler already merged :) 10:23
And yeah, now is a good time on the new libuv
dogbert17 oh, I missed that merge 10:24
jnthn Yay, I seem to have a working async locking mechanism 10:25
gist.github.com/jnthn/6f4a2258092a...6a982e8003
lizmat dogbert17: also looking forward to new libuv
.oO( newer is betterder, right? )
10:26
jnthn: s/hich/which
dogbert17 lizmat: let's hope so :)
Geth MoarVM: bbfb436f3e | (Jan-Olof Hendig)++ | 3rdparty/libuv
Bump libuv to ver. 1.14.1
MoarVM: 5684e4f366 | (Jonathan Worthington)++ (committed using GitHub Web editor) | 3rdparty/libuv
Merge pull request #682 from dogbert17/update-libuv

Bump libuv to ver. 1.14.1
dogbert17 cool
lizmat dogbert17: should I do an nqp/rakudo bump, or is that too early ? 10:27
dogbert17 wait a bit, I wonder if this went the way I hoped, hmm 10:28
jnthn is doing a local build
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
Onto Rakudo build now 10:29
lizmat jnthn: what is the significance of "= Holder" in "has Holder $!holder = Holder" ?
jnthn N
lizmat: Variables must be explicitly initialized if you use cas
lizmat ah, ok
jnthn Thanks to our various bits of laziness to avoid allocations 10:30
Which makes me wonder if those are really a good idea :P
dogbert17 yeah, I was scared at first, after doing a git pull, and I failed to see the new files
but now they're there :)
jnthn Yeah. spectesting but so far so good 10:31
Rakudo test passed
dogbert17 also spectesting :)
lizmat jnthn: since you're using nqp in the gist, is there a reason you use =:= instead of nqp::eqaddr ?
jnthn 'cus I trust in inlining :P 10:32
dogbert17 jnthn: suspect you have more cores than I have on my $work comp (4)
jnthn Also I find code full of nqp:: ops hard to read
And hard to read is the last thing I want when implementing a lock-free data structure :P
lizmat well, in my experience =:= badly inlines because of its megamorphicness
or has that changed ? 10:33
jnthn It should be better now
In theory at least :)
In practice would have to check :)
dogbert17: spectest ok here 10:34
lizmat Just tested: nqp::eqaddr is about 1.6x faster, but I think that's mainly because it needs do boolification 10:36
*it being =:=
jnthn Yeah
I can live with that for now :) 10:37
dogbert17 jnthn: looks good here in 32 bit land as well :) 10:44
quite a few changes since 1.8, github.com/libuv/libuv/blob/v1.x/ChangeLog 10:45
jnthn Indeed 10:48
dogbert17 wonders if Cygwin will work now 10:49
Geth MoarVM: 6ef763b3a8 | MasterDuke17++ | 2 files
Add MVM_fixed_size_realloc

Also add an _at_safepoint version.
11:01
MoarVM: ece0c5f7c4 | (Jonathan Worthington)++ (committed using GitHub Web editor) | 2 files
Merge pull request #688 from MasterDuke17/add_realloc_to_fsa

Add MVM_fixed_size_realloc
jnthn dogbert17: Maybe, though I don't care to be the person who finds out :-) 11:07
I'm sure somebody will try it :) 11:08
11:17 lizmat joined 11:24 leont joined 12:00 AlexDaniel joined 12:31 travis-ci joined
travis-ci MoarVM build errored. Jonathan Worthington 'Merge pull request #688 from MasterDuke17/add_realloc_to_fsa 12:31
travis-ci.org/MoarVM/MoarVM/builds/276801107 github.com/MoarVM/MoarVM/compare/5...e0c5f7c4b1
12:31 travis-ci left 12:32 buggable joined
jnthn apt install error, it seems 12:37
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
Geth MoarVM: 1afedf5188 | (Jonathan Worthington)++ | src/core/threads.c
Stash native thread ID after GC unblock

Otherwise the thread object inside of the thread context may be an outdated pointer due to an ongoing GC run, and thus the stored native thread ID will be to an invalid location.
16:28
MoarVM: 1959f2ff2e | (Jonathan Worthington)++ | 3 files
Make native callback thread finding more robust

While the bug fixed in the commit prior to this one was the major cause of failing to find the correct thread, there was also a race on looking through the thread list. Fix that here also.
16:36
16:37 Ven`` joined
Geth MoarVM: eeb664ea65 | (Jonathan Worthington)++ | 4 files
Factor out callback thread finding

This means the fixed version is now shared between both the dyncall and libffi codepaths.
16:51
nine Looks quite nice now :) 16:52
16:52 robertle joined
jnthn Shoulda probably have had it factored out that way in the first place :) 16:53
17:03 Ven`` joined
ugexe 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
github.com/MoarVM/MoarVM/blob/df40...ops.c#L122 (note the comment mentions the CopyFile api) 17:07
17:17 Skarsnik joined 17:26 buggable joined 17:43 Skarsnik_ joined
ugexe i am testing such a change on various os 17:50
18:46 buggable joined 18:55 committable6 joined, bloatable6 joined, coverable6 joined, nativecallable6 joined, quotable6 joined, greppable6 joined, releasable6 joined, bisectable6 joined, unicodable6 joined, squashable6 joined, evalable6 joined, benchable6 joined, statisfiable6 joined
AlexDaniel āš  Rakudo SQUASHathon 2017-10-07 github.com/rakudo/rakudo/wiki/Mont...Squash-Day 19:08
Geth_ moarvm.org: a6a039d539 | jnthn++ | 2 files
Update for 2017.09 release
19:15
jnthn Goodness, a lot got done in the last couple of releases. 19:19
jnthn didn't even do very much last month, and still loads got done :D 19:22
Really nice work, everyone <3
lizmat yeah, it really adds up :-)
nine 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:34
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:37
moritz convergence! 19:40
nine I just love these moments when things come together so beautifully :)
lizmat lights a cigar 19:41
www.youtube.com/watch?v=XwozVKOkzz4 19:42
nine lizmat: exactly :) 19:43
jnthn nine: Yes :-) 19:44
Geth MoarVM/jit_nativecall: 48a5823b31 | (Stefan Seifert)++ | 4 files
Bring back JITing of ncinvoke_o

Since at this stage the code calling the ncinvoke_o op cannot change anymore, we can access the WORK registers directly, saving the copying of those to tc->cur_frame->args.
19:46
nine 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:47
moritz heh, for me it's astronomy :-) 19:48
[Coke] numberphile and twitch, here. :) 19:51
moritz www.youtube.com/playlist?list=PL8d...yiSFuh0mIL if anybody needs inspiration :-) 19:55
nine Ok, numbers look the same as the previous version for 10000 iterations and apparently better than before for 100000. 20:12
Actually I measured 100_000 vs. 1000_000 iterations 20:15
timotimo any benchmarks to see how pre vs post jit-nativecall performance is? 20:18
nine 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:19
Skarsnik it's something ^^ 20:20
timotimo what does your benchamrk look like? csv with inline::perl5?
nine timotimo: yes, csv-ip5xs.pl
Skarsnik 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
nine 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.
Skarsnik hm will be Str
timotimo that's a big percentage of 'em
if by pointers you include structs for example 20:23
nine 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.
jnthn wonders what this'll do to IO::Socket::Async::SSL perf :)
Skarsnik hm why Str can't be JIT? 20:24
timotimo just won't do it yet
jnthn Skarsnik: I think it's just "not done yet", not "can't be" :)
Skarsnik Hoo alright
nine 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.
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
timotimo 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
even though i think it should have been able to use a sp_p6oget_o or what it's called for it
jnthn 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 ;)
*:)
timotimo right
huh, 0 flags 20:30
nine 47.397s without JITing. So JITing gives a 7 % speedup. 20:32
timotimo sp_getarg_o r9(2), liti16(0)
r9(2): usages=1, flags=13 KnTyp Dcntd Concr DeadWriter
that doesn't fit, does it?
the other registers that get their values from this one don't have DeadWriter 20:34
oh, could it be ... 20:35
r0(3) is being merged together by, among others, itself
we probably don't have anything in the code for that to not say "oh, we know nothing about this!"
well, that certainly did nothing at all 20:43
we would pobably have to iterate to a fix point to get phi merged facts proper in jump-backwards-situations? 20:44
Geth MoarVM/jit_nativecall: 18 commits pushed by (Stefan Seifert)++
review: github.com/MoarVM/MoarVM/compare/4...0d162dbf1c
20:50
timotimo 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:52
except we have the writers directly available right then and there 20:53
timotimo rolls up imaginary sleeves 20:54
ugexe 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:01
on linux. on osx it results in "A" 21:02
samcv i can't seem to compile moarvm on freebsd 21:05
it's failing when trying to compile libatomic
timotimo maybe we need a version bump in libatomic for that? 21:06
samcv yeah hold on. trying to build again without -j
ok it didn't fail that. i get undefined reference to uv__hrtime 21:07
looks like it was a build parallization issue on freebsd with libatomic. but i am getting it not linking properly 21:08
Skarsnik I wonder if google has arm VM x) 21:11
lizmat and yet another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2017/09/18/...me-booked/ 21:41
samcv lizmat++ 21:44
lizmat samcv: any thoughts about Reini's blog posr re Perl 6 ? 21:46
it feels he's not up to date with all of your latest work 21:47
samcv yeah 21:51
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 :)
lizmat well, please tell him :-) You're the person of authority here :-)
jnthn Given Perl 6 normalizes everything at input, I'm not sure why it'd not be doing this right 21:54
MasterDuke i.imgur.com/9YzmQ1F.png heaptrack report for that script that had high memory use a little while ago 22:07
imgur.com/zD2CfJm ~10 days ago to compare 22:09
jnthn Nice reduction :) 22:12
New scheduler can be thanked for starting less threads :)
MasterDuke yeah, quite dramatic 22:13
AlexDaniel: ^^^, might be time to rebuild rakudo on the *able server 22:14
jnthn rest time o/ 22:28
Geth MoarVM: 43d6af05db | (Samantha McVey)++ | .appveyor.yml
Try and enable and build matrix with Appveyor
22:35
MoarVM: 2824dcf8fc | (Samantha McVey)++ | .appveyor.yml
Trigger Appveyor build
22:41
samcv yay it works!
ci.appveyor.com/project/samcv/moarvm-35u74
msvc 2015 and 2017 x64 and x86 matrix 22:42
\o/
MasterDuke nice 22:45
samcv uh windows is failing as well linking libuv 22:47
freebsd too 22:50
yeah reverting the libuv bump fixes building on freebsd 22:56
MasterDuke that sucks. anything in libuv release notes about freebsd? 22:58
samcv well it fails on windows too 23:05
AlexDaniel MasterDuke: botacalypse again? I just did that todayyā€¦ 23:06
MasterDuke think of the ram savings! 23:07
AlexDaniel are you thinking that things like this will not leak anymore
c: eonhuotueh say 42 23:08
committable6 AlexDaniel, Ā¦eonhuotueh: Ā«Cannot find this revision (did you mean ā€œKarlsruheā€?)Ā»
AlexDaniel c: eonhuotueh say 42
committable6 AlexDaniel, Ā¦eonhuotueh: Ā«Cannot find this revision (did you mean ā€œKarlsruheā€?)Ā»
AlexDaniel c: eonhuotueh say 42
committable6 AlexDaniel, Ā¦eonhuotueh: Ā«Cannot find this revision (did you mean ā€œKarlsruheā€?)Ā»
MasterDuke leak less
AlexDaniel c: foo say 42
committable6 AlexDaniel, Ā¦foo: Ā«Cannot find this revision (did you mean ā€œallā€?)Ā»
AlexDaniel c: abc242 say 42
committable6 AlexDaniel, Ā¦abc242: Ā«Cannot find this revision (did you mean ā€œb1c412aā€?)Ā»
AlexDaniel c: abc242 say 42
committable6 AlexDaniel, Ā¦abc242: Ā«Cannot find this revision (did you mean ā€œb1c412aā€?)Ā»
AlexDaniel c: abc242 say 42
committable6 AlexDaniel, Ā¦abc242: Ā«Cannot find this revision (did you mean ā€œb1c412aā€?)Ā»
AlexDaniel but even this is no longer leaking
greppable6: password 23:09
greppable6 AlexDaniel, gist.github.com/a6099a830ea3271c64...894a987a51
AlexDaniel greppable6: password
greppable6 AlexDaniel, gist.github.com/ea12f53147bae44a26...e65ad3fdd9
AlexDaniel OK, this does.
samcv libuv compiles fine if i cd into 3rdparty/libuv and run ./autogen.sh and then ./configure then make 23:10
ugexe windows fix looks easy enough 23:13
samcv did they add a new file or something? 23:16
looks like i need to add a file for bsd 23:17
23:17 quotable6 joined, coverable6 joined, nativecallable6 joined 23:18 greppable6 joined, releasable6 joined, bloatable6 joined, committable6 joined, bisectable6 joined, evalable6 joined, statisfiable6 joined, unicodable6 joined, squashable6 joined, benchable6 joined 23:19 committable6 joined, greppable6 joined
AlexDaniel MasterDuke: I see no change 23:19
at least nothing noticeable to human eye
Geth MoarVM: ugexe++ created pull request #694:
Pass user32 lib to build on windows
23:22
MoarVM: dfbf9df7b6 | (Samantha McVey)++ | build/Makefile.in
Fix FreeBSD build by adding new libuv file to Makefile.in

FreeBSD build broke after bumping libuv. Add the new file to Makefile.in
samcv yay bulid fixed
going thing i decided to install freebsd
MasterDuke samcv: heaptrack thinks MVM_string_join (src/string/ops.c:1704) leaks. see anything obvious? 23:32
samcv uh
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?
MasterDuke 1704 is where heaptrack thinks it's happening
samcv well that gets attached to a string. maybe the GC just hasn't reclaimed it yet? idk 23:35
MasterDuke hm. i was using --full-cleanup, but i guess i can try adding some nqp::force_gc()'s and see if that changes anything
ugexe github.com/MoarVM/MoarVM/pull/694 fixes the windows build 23:36
Geth MoarVM: cabfefe2f2 | (Nick Logan)++ (committed using GitHub Web editor) | build/setup.pm
Pass user32 lib to build on windows

  See: github.com/libuv/libuv/commit/e514...6d1408aR62
23:39
MoarVM: eabfc24273 | (Samantha McVey)++ (committed using GitHub Web editor) | build/setup.pm
Merge pull request #694 from ugexe/patch-1

Pass user32 lib to build on windows
samcv cool. thanks ugexe
samcv --with-ffi fails on freebsd. need to fix that 23:55