dalek arVM/tommy-hash: b78149c | diakopter++ | / (35 files):
experimental replacement of hash library; builds but segfaults. do not use
 02:05
Heuristic branch merge: pushed 66 commits to MoarVM/tommy-hash by diakopter 02:32
03:06 vendethiel joined
dalek arVM/tommy-hash: 691b539 | diakopter++ | / (3 files):
[experimental] build tommy stuff
 04:21
05:07 TimToady joined 06:23 cognominal joined 07:27 FROGGS joined 08:28 brrt joined
brrt \o 08:28
timotimo; i may have some fixes in your assembly
diakopter; sorry for not fixing msvc yet
things should work on mingw
things should also work with msvc2013 08:29
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
it shouldn't fail
diakopter I dondt' think it's jit related 08:33
I'm having fun experimenting with replacing the hash library 08:34
NMAKE : fatal error U1073: don't know how to make '3rdparty\tommy\tommy.lib' 08:36
hmm :) I guess I compiled it manually before I switched platforms
09:34 rurban_ joined 09:44 BinGOs_ joined 09:45 arnsholt_ joined, sivoais_ joined 09:55 sivoais joined 09:59 bonsaikitten joined 10:05 sivoais joined 10:14 BinGOs joined 10:15 sivoais joined
brrt anyway, timotimo, i noticed some field-size issues, and that might be a reason for tripping ups 10:19
diakopter boy this new msvc cl.exe is stricter 10:23
brrt people want to make c++ safe, apparantly 10:24
10:25 sivoais joined 10:35 sivoais joined 10:45 sivoais joined
dalek arVM/timos-jit-patch: d28c48f | brrt++ | src/ (4 files):
Revert "Work around performance regression in the jit."

This reverts commit bd56e2e33bbe16bbb542cc34f37f4004be2da976.		 10:47
MoarVM/timos-jit-patch: 4993c55 | brrt++ | src/jit/emit_x64.dasc:
MoarVM/timos-jit-patch: Fixed comparison and sized reads in jit
MoarVM/timos-jit-patch:
MoarVM/timos-jit-patch: cmp a, a always yields true (it's a sub with zero-check); needs
MoarVM/timos-jit-patch: to be test a, a to check for zeroness
MoarVM/timos-jit-patch:
MoarVM/timos-jit-patch: MVMStorageSpec->bits is a uint16, so are MVMArgProcContext->num_pos
brrt should like to test this 10:48
what was the performance problem, anyway
lizmat a factor of 1.5 to 3x slowdown
spectest 1.5, test-t (Tux's test) 3x
the latter being heavy on the loops 10:49
10:55 sivoais joined
brrt aha 10:56
hmm, ok, that will be tricky to detect 10:57
ooh, testsuite does feel slow 11:01
11:05 sivoais joined
brrt nativecall tests are awefully slow at any rate 11:13
11:15 sivoais joined 11:25 sivoais joined
diakopter mystifying 11:26
11:35 sivoais joined
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
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)
so it seems the 1.5 was overstated... 11:38
test-t was at 13 seconds last week, it was at 48 seconds before the jit fix 11:39
11:45 sivoais joined 11:55 sivoais joined 12:05 sivoais joined 12:15 sivoais joined 12:54 virtualsue joined 13:09 rurban_ joined 13:44 cygx joined 13:46 dalek joined
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 github.com/MoarVM/MoarVM/blob/mast...m/setjmp.h 13:49
timotimo noticing problems like that in assembly code is ... quite a challenge to me, who just cargo-cults code from other functions ... 14:12
14:36 brrt joined
brrt good * 14:38
timotimo: it's no problem :-)
timotimo i'm so glad we have you ... 14:41
at some point i ought to learn x86_64 assembly "correctly" 14:42
like, from the beginning
were you able to time something with that change?
it could well be that a bogus value for objprimbits would send the multi cache into coo-coo town
omg! brrt! 14:48
your patch fixes the performance regression!
(in that one benchmark i was using)
brrt whatisit
\o/ 14:49
yay
really odd that this lead to a performance issue rather than a segfault
timotimo i expect we currently only use the result of objprimbits to decide on a specific candidate to call or something like that?
brrt quite possibly 14:50
timotimo you think i can merge this? i probably should ask others to verify the speedup's back first ...
lizmat: can i ask you to check out moarvm/timos-jit-patch and do the spec test timing again? :)
brrt Tux also said it fixed it for him 14:51
so yeah, please some more tests, and then a merge
timotimo oh, i didn't see that
i shall spec test, too.
brrt thanks :-) 14:53
timotimo i'll have a hard time getting a good timing for spec tests, though 14:56
i'll try it anyway
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
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
when throttle hangs, it doesn't take CPU
timotimo right
862.72user 61.07system 17:19.52elapsed 88%CPU (0avgtext+0avgdata 1730172maxresident)k 15:17
running "the other" spec test now
lizmat for the whole spectest?
ah. ok
15:21 sivoais joined
timotimo with test jobs set to 3 15:22
hoelzro o/ #moarvm 15:23
timotimo so much backlog ... 15:24
847.19user 60.61system 8:44.38elapsed 173%CPU (0avgtext+0avgdata 1722308maxresident)k 15:26
killed throttle.t a whole lot sooner this time
that's probably the reason for the cpu percentage to be so much higher 15:27
15:32 sivoais joined
timotimo lizmat: so ... is the first one better or the second one? :\ 15:34
m: say (8 * 60 + 44) * 1.73; say (17 * 60 + 19) * 0.88
camelia rakudo-moar f1226f: OUTPUTĀ«906.52ā¤914.32ā¤Ā»
lizmat I would say the 2nd one used less CPU 15:35
but with 2% better, close to noise levels
timotimo oh, wait. i'm not looking for "much better", i'm just looking for "not 20% worse" 15:36
so this is fine
the first one is timos-jit-patches, btw
lizmat ok
timotimo and in my say invocation, i switched both around
to create some of the much-needed confusion around here
lizmat so that would mean we lose 2% ?
m: my $a = 10; $a ^= 2; say $a.WHAT # is that expected ? 15:39
camelia rakudo-moar f1226f: OUTPUTĀ«(Junction)ā¤Ā»
15:42 sivoais joined
timotimo yeah, it is 15:48
^ is the junction xor operator
lizmat: i kind of hope it doesn't mean we actually lose 2% :| 15:50
lizmat too
does it make sense to make a junction in which the junction itself is a part ? 15:51
feels to me that |= and ^= have no need, and could be verboten ?
diakopter heh, #moarvm as the refuge from the backlog deluge 15:52
15:52 sivoais joined
lizmat actually, I was just asking questions on the wrong channel 15:52
diakopter well, it's a natural thing if no one can get a word in on #perl6 :D 15:53
timotimo you can totally put a junction inside a junction 15:54
it makes the most sense for combining any, all, and one junctions 15:55
m: say 1 ^ 2
camelia rakudo-moar 79303b: OUTPUTĀ«one(1, 2)ā¤Ā»
timotimo ah, ^ is one, not "xor"
nesting "one" junctions inside "one" junctions makes as little sense as nesting "any" in "any", or nesting "all" in "all" 15:56
but combining the different ones is fine. which you can do with ^=, &= and |=
16:02 sivoais joined
lizmat timotimo: can you make an example that doesn't hang ? 16:10
timotimo i didn't realize ^= hangs; it probably wrongly tries to evaluate the junction before/during the assignment 16:11
i'd have to investigate, but right now i'm very distracted
16:12 sivoais joined
lizmat don't worry 16:14
was just seeing there would be an easy fix to #126961
timotimo maybe we just want to change the signature of the metaop assign things we generate to handle Mu rather than Any. 16:17
cygx github.com/MoarVM/MoarVM/pull/318 16:18
16:22 sivoais joined 16:27 zakharyas joined
lizmat timotimo: not sure whether that would help, as "my $a = 10; $a = $a | 2; say $a" also hangs 16:30
dinner&
timotimo oh 16:32
well, that's just bad in that case :)
16:32 sivoais joined 16:42 sivoais joined 16:52 sivoais joined 16:57 sivoais joined
dalek arVM: 8fe4aef | cygx++ | src/io/fileops.c:
fix bug that made win32 throw on deleting nonexistent files
 17:17
arVM: 0317e25 | (Jimmy Zhuo)++ | src/io/fileops.c:
Merge pull request #318 from cygx/fix-unlink

fix bug that made win32 throw on deleting nonexistent files
18:20 vendethiel joined
lizmat not sure whether applicable for Moar, but there you go: conf.researchr.org/event/ismm-2015/...t-machines 18:29
18:31 cognominal joined
diakopter lizmat: nonetheless, cool 18:46
yes, looks like it's MIT/gplv3 dual licensed github.com/kuszmaul/SuperMalloc 18:48
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 19:18 FROGGS joined
dalek arVM/even-moar-jit: 64826fe | brrt++ | / (94 files):
Merge remote-tracking branch 'origin/master' into even-moar-jit

Some conflicts in src/jit/graph.c, which is the result of the factoring out of the jit-graph-builder.		 19:48
arVM: d28c48f | brrt++ | src/ (4 files):
Revert "Work around performance regression in the jit."

This reverts commit bd56e2e33bbe16bbb542cc34f37f4004be2da976.		 19:49
MoarVM: 4993c55 | brrt++ | src/jit/emit_x64.dasc:
MoarVM: Fixed comparison and sized reads in jit
MoarVM:
MoarVM: cmp a, a always yields true (it's a sub with zero-check); needs
MoarVM: to be test a, a to check for zeroness
MoarVM:
MoarVM: MVMStorageSpec->bits is a uint16, so are MVMArgProcContext->num_pos
MoarVM: and MVMArgProcContext->arg_count, so we should read them as words,
MoarVM: and zero-extend as necessary
timotimo <3 19:51
thank you, brrt
20:50 rurban_ joined 21:24 TimToady joined 23:15 virtualsue joined 23:56 rurban_ joined

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!