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 |