Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-12-21

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
02:05 dalek MoarVM/tommy-hash: b78149c | diakopter++ | / (35 files):
02:05 dalek MoarVM/tommy-hash: experimental replacement of hash library; builds but segfaults. do not use
02:05 dalek MoarVM/tommy-hash: review: https://github.com/MoarVM/MoarVM/commit/b78149c3ff
02:32 dalek Heuristic branch merge: pushed 66 commits to MoarVM/tommy-hash by diakopter
03:06 vendethiel joined #moarvm
04:21 dalek MoarVM/tommy-hash: 691b539 | diakopter++ | / (3 files):
04:21 dalek MoarVM/tommy-hash: [experimental] build tommy stuff
04:21 dalek MoarVM/tommy-hash: review: https://github.com/MoarVM/MoarVM/commit/691b539cfb
05:07 TimToady joined #moarvm
06:23 cognominal joined #moarvm
07:27 FROGGS joined #moarvm
08:28 brrt joined #moarvm
08:28 brrt \o
08:28 brrt timotimo; i may have some fixes in your assembly
08:28 brrt diakopter; sorry for not fixing msvc yet
08:28 brrt things should work on mingw
08:29 brrt things should also work with msvc2013
08:32 diakopter np; I'm hoping the two rakudo nativecall tests that still fail (even with no-jit) aren't a big deal
08:32 brrt hmmpf
08:32 brrt it shouldn't fail
08:33 diakopter I dondt' think it's jit related
08:34 diakopter I'm having fun experimenting with replacing the hash library
08:36 diakopter NMAKE : fatal error U1073: don't know how to make '3rdparty\tommy\tommy.lib'
08:36 diakopter hmm :) I guess I compiled it manually before I switched platforms
09:34 rurban_ joined #moarvm
09:44 BinGOs_ joined #moarvm
09:45 arnsholt_ joined #moarvm
09:45 sivoais_ joined #moarvm
09:55 sivoais joined #moarvm
09:59 bonsaikitten joined #moarvm
10:05 sivoais joined #moarvm
10:14 BinGOs joined #moarvm
10:15 sivoais joined #moarvm
10:19 brrt anyway, timotimo, i noticed some field-size issues, and that might be a reason for tripping ups
10:23 diakopter boy this new msvc cl.exe is stricter
10:24 brrt people want to make c++ safe, apparantly
10:25 sivoais joined #moarvm
10:35 sivoais joined #moarvm
10:45 sivoais joined #moarvm
10:47 dalek MoarVM/timos-jit-patch: d28c48f | brrt++ | src/ (4 files):
10:47 dalek MoarVM/timos-jit-patch: Revert "Work around performance regression in the jit."
10:47 dalek MoarVM/timos-jit-patch:
10:47 dalek MoarVM/timos-jit-patch: This reverts commit bd56e2e33bbe16bbb542cc34f37f4004be2da976.
10:47 dalek MoarVM/timos-jit-patch: review: https://github.com/MoarVM/MoarVM/commit/d28c48f1ea
10:47 dalek MoarVM/timos-jit-patch: 4993c55 | brrt++ | src/jit/emit_x64.dasc:
10:47 dalek MoarVM/timos-jit-patch: Fixed comparison and sized reads in jit
10:47 dalek MoarVM/timos-jit-patch:
10:47 dalek MoarVM/timos-jit-patch: cmp a, a always yields true (it's a sub with zero-check); needs
10:47 dalek MoarVM/timos-jit-patch: to be test a, a to check for zeroness
10:47 dalek MoarVM/timos-jit-patch:
10:47 dalek MoarVM/timos-jit-patch: MVMStorageSpec->bits is a uint16, so are MVMArgProcContext->num_pos
10:48 * brrt should like to test this
10:48 brrt what was the performance problem, anyway
10:48 lizmat a factor of 1.5 to 3x slowdown
10:48 lizmat spectest 1.5, test-t (Tux's test) 3x
10:49 lizmat the latter being heavy on the loops
10:55 sivoais joined #moarvm
10:56 brrt aha
10:57 brrt hmm, ok, that will be tricky to detect
11:01 brrt ooh, testsuite does feel slow
11:05 sivoais joined #moarvm
11:13 brrt nativecall tests are awefully slow at any rate
11:15 sivoais joined #moarvm
11:25 sivoais joined #moarvm
11:26 diakopter mystifying
11:35 sivoais joined #moarvm
11:37 lizmat typical spectest with jit broken: Files=1092, Tests=51316, 335 wallclock secs (15.40 usr  4.00 sys + 2206.75 cusr 170.43 csys = 2396.58 CPU)
11:37 lizmat typical spectest with jit working: Files=1092, Tests=51353, 265 wallclock secs (14.10 usr  3.82 sys + 1798.37 cusr 151.49 csys = 1967.78 CPU)
11:38 lizmat so it seems the 1.5 was overstated...
11:39 lizmat test-t was at 13 seconds last week, it was at 48 seconds before the jit fix
11:45 sivoais joined #moarvm
11:55 sivoais joined #moarvm
12:05 sivoais joined #moarvm
12:15 sivoais joined #moarvm
12:54 virtualsue joined #moarvm
13:09 rurban_ joined #moarvm
13:44 cygx joined #moarvm
13:46 dalek joined #moarvm
13:49 cygx diakopter: if you do think it's the jit that makes your windows build fail, you might try replacing the check for __MINGW32__ with _WIN32 in https://github.com/MoarVM/MoarVM/blob/master/src/platform/setjmp.h
14:12 timotimo noticing problems like that in assembly code is ... quite a challenge to me, who just cargo-cults code from other functions ...
14:36 brrt joined #moarvm
14:38 brrt good *
14:38 brrt timotimo: it's no problem :-)
14:41 timotimo i'm so glad we have you ...
14:42 timotimo at some point i ought to learn x86_64 assembly "correctly"
14:42 timotimo like, from the beginning
14:42 timotimo were you able to time something with that change?
14:42 timotimo it could well be that a bogus value for objprimbits would send the multi cache into coo-coo town
14:48 timotimo omg! brrt!
14:48 timotimo your patch fixes the performance regression!
14:48 timotimo (in that one benchmark i was using)
14:48 brrt whatisit
14:49 brrt \o/
14:49 brrt yay
14:49 brrt really odd that this lead to a performance issue rather than a segfault
14:49 timotimo i expect we currently only use the result of objprimbits to decide on a specific candidate to call or something like that?
14:50 brrt quite possibly
14:50 timotimo you think i can merge this? i probably should ask others to verify the speedup's back first ...
14:50 timotimo lizmat: can i ask you to check out moarvm/timos-jit-patch and do the spec test timing again? :)
14:51 brrt Tux also said it fixed it for him
14:51 brrt so yeah, please some more tests, and then a merge
14:51 timotimo oh, i didn't see that
14:51 timotimo i shall spec test, too.
14:53 brrt thanks :-)
14:56 timotimo i'll have a hard time getting a good timing for spec tests, though
14:56 timotimo i'll try it anyway
14:59 lizmat as long as the CPU of the spectest is not suddenly 20% more, it should be ok
14:59 timotimo OK, good
15:09 sivoais joined #moarvm
15:16 timotimo well, that timing is now useless, as i didn't look over to see throttle has been sitting idle for who-knows-how-long
15:16 lizmat CPU is important
15:16 lizmat when throttle hangs, it doesn't take CPU
15:16 timotimo right
15:17 timotimo 862.72user 61.07system 17:19.52elapsed 88%CPU (0avgtext+0avgdata 1730172maxresident)k
15:17 timotimo running "the other" spec test now
15:17 lizmat for the whole spectest?
15:17 lizmat ah. ok
15:21 sivoais joined #moarvm
15:22 timotimo with test jobs set to 3
15:23 hoelzro o/ #moarvm
15:24 timotimo so much backlog ...
15:26 timotimo 847.19user 60.61system 8:44.38elapsed 173%CPU (0avgtext+0avgdata 1722308maxresident)k
15:26 timotimo killed throttle.t a whole lot sooner this time
15:27 timotimo that's probably the reason for the cpu percentage to be so much higher
15:32 sivoais joined #moarvm
15:34 timotimo lizmat: so ... is the first one better or the second one? :\
15:34 timotimo m: say (8 * 60 + 44) * 1.73; say (17 * 60 + 19) * 0.88
15:34 camelia rakudo-moar f1226f: OUTPUT«906.52␤914.32␤»
15:35 lizmat I would say the 2nd one used less CPU
15:35 lizmat but with 2% better, close to noise levels
15:36 timotimo oh, wait. i'm not looking for "much better", i'm just looking for "not 20% worse"
15:36 timotimo so this is fine
15:36 timotimo the first one is timos-jit-patches, btw
15:36 lizmat ok
15:36 timotimo and in my say invocation, i switched both around
15:36 timotimo to create some of the much-needed confusion around here
15:36 lizmat so that would mean we lose 2% ?
15:39 lizmat m: my $a = 10; $a ^= 2; say $a.WHAT  # is that expected ?
15:39 camelia rakudo-moar f1226f: OUTPUT«(Junction)␤»
15:42 sivoais joined #moarvm
15:48 timotimo yeah, it is
15:48 timotimo ^ is the junction xor operator
15:50 timotimo lizmat: i kind of hope it doesn't mean we actually lose 2% :|
15:50 * lizmat too
15:51 lizmat does it make sense to make a junction in which the junction itself is a part ?
15:51 lizmat feels to me that |= and ^= have no need, and could be verboten ?
15:52 diakopter heh, #moarvm as the refuge from the backlog deluge
15:52 sivoais joined #moarvm
15:52 lizmat actually, I was just asking questions on the wrong channel
15:53 diakopter well, it's a natural thing if no one can get a word in on #perl6 :D
15:54 timotimo you can totally put a junction inside a junction
15:55 timotimo it makes the most sense for combining any, all, and one junctions
15:55 timotimo m: say 1 ^ 2
15:55 camelia rakudo-moar 79303b: OUTPUT«one(1, 2)␤»
15:55 timotimo ah, ^ is one, not "xor"
15:56 timotimo nesting "one" junctions inside "one" junctions makes as little sense as nesting "any" in "any", or nesting "all" in "all"
15:56 timotimo but combining the different ones is fine. which you can do with ^=, &= and |=
16:02 sivoais joined #moarvm
16:10 lizmat timotimo: can you make an example that doesn't hang ?
16:11 timotimo i didn't realize ^= hangs; it probably wrongly tries to evaluate the junction before/during the assignment
16:11 timotimo i'd have to investigate, but right now i'm very distracted
16:12 sivoais joined #moarvm
16:14 lizmat don't worry
16:14 lizmat was just seeing there would be an easy fix to #126961
16:17 timotimo maybe we just want to change the signature of the metaop assign things we generate to handle Mu rather than Any.
16:18 cygx https://github.com/MoarVM/MoarVM/pull/318
16:22 sivoais joined #moarvm
16:27 zakharyas joined #moarvm
16:30 lizmat timotimo: not sure whether that would help, as "my $a = 10; $a = $a | 2; say $a" also hangs
16:30 lizmat dinner&
16:32 timotimo oh
16:32 timotimo well, that's just bad in that case :)
16:32 sivoais joined #moarvm
16:42 sivoais joined #moarvm
16:52 sivoais joined #moarvm
16:57 sivoais joined #moarvm
17:17 dalek MoarVM: 8fe4aef | cygx++ | src/io/fileops.c:
17:17 dalek MoarVM: fix bug that made win32 throw on deleting nonexistent files
17:17 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8fe4aef243
17:17 dalek MoarVM: 0317e25 | (Jimmy Zhuo)++ | src/io/fileops.c:
17:17 dalek MoarVM: Merge pull request #318 from cygx/fix-unlink
17:17 dalek MoarVM:
17:17 dalek MoarVM: fix bug that made win32 throw on deleting nonexistent files
17:17 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0317e25720
18:20 vendethiel joined #moarvm
18:29 lizmat not sure whether applicable for Moar, but there you go: http://conf.researchr.org/event/ismm-2015/ismm-2015-papers-supermalloc-a-super-fast-multithreaded-malloc-for-64-bit-machines
18:31 cognominal joined #moarvm
18:46 diakopter lizmat: nonetheless, cool
18:48 diakopter yes, looks like it's MIT/gplv3 dual licensed https://github.com/kuszmaul/SuperMalloc
18:50 diakopter lizmat: it's possibly worth an experimental comparison to Moar's fixed size allocator (for the things that do reference counting, namely, frames)
18:50 JimmyZ hmm, looks like better than jemalloc
19:11 FROGGS joined #moarvm
19:18 FROGGS joined #moarvm
19:48 dalek MoarVM/even-moar-jit: 64826fe | brrt++ | / (94 files):
19:48 dalek MoarVM/even-moar-jit: Merge remote-tracking branch 'origin/master' into even-moar-jit
19:48 dalek MoarVM/even-moar-jit:
19:48 dalek MoarVM/even-moar-jit: Some conflicts in src/jit/graph.c, which is the result of
19:48 dalek MoarVM/even-moar-jit: the factoring out of the jit-graph-builder.
19:48 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/64826fe982
19:49 dalek MoarVM: d28c48f | brrt++ | src/ (4 files):
19:49 dalek MoarVM: Revert "Work around performance regression in the jit."
19:49 dalek MoarVM:
19:49 dalek MoarVM: This reverts commit bd56e2e33bbe16bbb542cc34f37f4004be2da976.
19:49 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d28c48f1ea
19:49 dalek MoarVM: 4993c55 | brrt++ | src/jit/emit_x64.dasc:
19:49 dalek MoarVM: Fixed comparison and sized reads in jit
19:49 dalek MoarVM:
19:49 dalek MoarVM: cmp a, a always yields true (it's a sub with zero-check); needs
19:49 dalek MoarVM: to be test a, a to check for zeroness
19:49 dalek MoarVM:
19:49 dalek MoarVM: MVMStorageSpec->bits is a uint16, so are MVMArgProcContext->num_pos
19:49 dalek MoarVM: and MVMArgProcContext->arg_count, so we should read them as words,
19:49 dalek MoarVM: and zero-extend as necessary
19:51 timotimo <3
19:51 timotimo thank you, brrt
20:50 rurban_ joined #moarvm
21:24 TimToady joined #moarvm
23:15 virtualsue joined #moarvm
23:56 rurban_ joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary