ilmari src/platform/threads.h:5:35: warning: implicit declaration of function ‘pthread_yield’ 00:00
00:17 ShimmerFairy joined 02:24 FROGGS_ joined
konobi blog.8thlight.com/colin-jones/2015...-slow.html 03:03
"Ask DTrace: Why are my tests so slow?"
03:37 vendethiel joined 07:13 kjs_ joined 07:34 domidumont joined 07:40 domidumont joined 07:57 FROGGS joined, kjs_ joined
nwc10 good *, #moarvm 08:02
JimmyZ \o/ nwc10
FROGGS o/ 08:22
jnthn ilmari: Feel free to send a PR for it, if you have time. 08:30
08:35 zakharyas joined
jnthn teaching & 08:46
nwc10 spots in blog.8thlight.com/colin-jones/2015...-slow.html -- And our $LOAD_PATH, like those in many other Rails projects, is pretty big: ... So every time whatever-it-is looks for these shared library files, it might have to look in 236 * 6 = 1416 places before finding the file it's looking for. 09:18
09:23 lizmat joined 09:25 kjs_ joined 10:07 domidumont joined
japhb nwc10: Yeah, there are a fair number of lessons in there. For one, "Brute force looks good enough until you multiply it by a large number." For another "Locking your patch levels is not a panacea -- now you have to manually decide which future patches you need to pull." 10:27
10:38 kjs_ joined 10:41 zakharyas joined
rjbs Why don't Ruby projects that use this strategy build merged link trees so avoid combinatorial explosions? 12:40
nwc10 because they don't think like sysadmins?
13:05 kjs_ joined 13:07 kjs_ joined
llfourn .tell timotimo you are probably asleep by now. Just poking you for benchmarks :D. No rush. 13:20
sorry wrong chan :( 13:21
rjbs nwc10: So if I write the code but give it a punchy name, maybe I can make my fame and fortune? :) 13:24
nwc10 you'd need a logo too, and a pastel coloured website 13:25
13:33 domidumont1 joined 15:09 domidumont joined 16:12 zakharyas joined, harrow joined, JimmyZ joined, flussence joined, BinGOs joined, dalek joined, timotimo joined, avar joined, leedo joined, tadzik joined, nwc10 joined, ShimmerFairy joined, colomon joined, llfourn joined, flaviusb joined, ggoebel7 joined, synbot6 joined, diakopter joined, pyrimidine joined, nebuchadnezzar joined, Util_ joined, ashleyde1 joined, moritz joined, arnsholt joined, ilmari joined, domidumont joined 16:28 rjbs joined, hoelzro joined, japhb joined, [Coke] joined, mtj_ joined, bonsaikitten joined, TimToady joined, camelia joined, btyler joined, psch joined, konobi joined 16:47 zakharyas joined, harrow joined, JimmyZ joined, flussence joined, BinGOs joined, dalek joined, timotimo joined, avar joined, leedo joined, tadzik joined, nwc10 joined, domidumont joined, ilmari joined, arnsholt joined, moritz joined, ashleyde1 joined, Util_ joined, nebuchadnezzar joined, pyrimidine joined, diakopter joined, synbot6 joined, ggoebel7 joined, flaviusb joined, llfourn joined, colomon joined, ShimmerFairy joined 16:50 camelia joined 16:51 ilbot3 joined 16:57 sivoais joined 16:58 lizmat joined 17:04 ChanServ joined
hoelzro o/ #moarvm 17:05
timotimo yo ro 17:31
dalek arVM/spesh_nativeref_assign_decont: a83b3cd | timotimo++ | src/spesh/facts.c:
teach our guard op generator about NativeRef
17:32
timotimo jnthn: ^- does that look okay-ish, semantically?
m: say "with this series of patches, doing 500M +1's on an rw lexical takes { 5.4 / 10.1 }x as much time as without the patches" 17:48
camelia rakudo-moar 704c58: OUTPUT«with this series of patches, doing 500M +1's on an rw lexical takes 0.534653x as much time as without the patches␤»
timotimo how does that sound?
jnthn timotimo: I think the patch is correct 17:50
timotimo sweet 17:52
i'm doing another measurement now to see the impact it has on ++ 17:53
if any
diakopter timotimo++
TimToady well, we'd like ++ to be 100x faster or so... 17:54
timotimo yes, ideally
jnthn That'll need some rather involved patching of the inliner :)
japhb TimToady: prefix, postfix, or "yes"?
timotimo that'll get faster via in...yes
japhb: yes
TimToady prefix always, postfix in sink
jnthn But it's fraught enough to do right I'm kinda actively discouraging trying this side of 6.c 17:55
TimToady postfix in non-sink can be a bit slower
in that case we should AOT optimize ++a to a = a + 1
jnthn (Also 'cus I think doing it well probably has architectural implications for how spesh works overall)
TimToady after optimizing a++ to ++a in sink 17:56
japhb Does postfix:<++> convert to prefix:<++> in sink only for the CORE version?
timotimo turning $a++ into ++$a might not be worth as much as you think 17:59
as long as we don't inline, that's drowned out so strongly by the invocation overhead
TimToady it's more valuable currently for natives, not much difference for non-natives
timotimo aye 18:00
TimToady maybe it's already doing the opt for non-natives
haven't checked
timotimo it probably does inlining there
jnthn Yeah, it can do
Native refs are designed to often be optimized out totally, but it's just not done yet. 18:01
timotimo there's even more win to be had from turning lexical $n into local_n in sub do-loop(int $n is rw) { while $n < 100_000_000 { $n = $n + 1 } }
because right now we do two getlex in a row for that and both times do a guard against its type
that's pure overhead, as we bind the value of that lexical from argument 0 and never change it ever and it doesn't escape, either 18:02
but spesh doesn't know that, and the static optimizer in rakudo isn't smart enough yet
TimToady CSE is such a modern notion :P
timotimo :)
well, lexicals could change out of nowhere in some cases 18:03
18:03 domidumont1 joined
timotimo so lexicals are still "HOT HOT DON'T TOUCH" in spesh's eyes 18:03
mostly, anyway
dalek arVM: c7706c4 | timotimo++ | / (6 files):
A spesh op like sp_bind/get_i64 with an extra pointer deref
18:04
arVM: de68134 | timotimo++ | src/ (2 files):
Allow NativeRef to spesh assign_i and decont_i

this uses the op the previous commit introduced.
arVM: 6a95b60 | timotimo++ | src/jit/ (2 files):
implement sp_deref_bind/get_i64/n in the JIT
arVM: a83b3cd | timotimo++ | src/spesh/facts.c:
teach our guard op generator about NativeRef
timotimo spec tests are quite noisy, but they already were without my patches
jnthn Wsa gonna say, with lexicals we have to be really careful on memory model issues 18:05
TimToady we defined parameters to be readonly by default partly with the intention that we could optimize low-level stuff to is-copy like C does
jnthn anyway, bbiab :)
timotimo this isn't about parameters, though
in this case the parameter comes in "via a local" that then gets bound into the lexical 18:06
have another itty bitty local patch that cuts down on the number of spesh slots by re-using spesh slots for these guards 18:08
diakopter surely someone could write an ircbot in p6 by Christmas to replace the functionality of (p5) dalek & (p5) camelia & (ruby) yoleaux
timotimo but that's for a bit later.
sauna time! \o/
TimToady diakopter: maybe you should do that for your advent post :) 18:11
diakopter TimToady: the current IRC module (Net::IRC::Bot) says this, which doesn't bode well for its current usefulness: 18:23
It's currently in active development, but it is mostly stable until perl 6 implements either threads or async I/O so it can work correctly as a bot (timed events and things that block the runtime are not possible yet.)
that's from the README which hasn't been updated in 3 years 18:24
[Coke] Yes, there are yaks to shave, which is why no one has written that bot yet. 18:27
TimToady
.oO(Shave a yak, go to sheol.)
18:31
diakopter seems an advent slot opened for ... tomorrow 18:34
18:44 sivoais joined 18:45 Peter_R joined 19:03 vendethiel joined 19:14 FROGGS joined 19:20 sivoais joined 19:35 domidumont joined 19:52 brrt joined
brrt good * #moarvm 19:53
timotimo hey brrt! :)
brrt hey timotimo 19:54
timotimo did you see i was able to get $foo = $foo + 1 to become faster! <3
184519 camelia │ rakudo-moar 704c58: OUTPUT«with this series of patches, doing 500M +1's on an rw lexical takes
│ 0.534653x as much time as without the patches␤»
brrt oh, very good! 20:00
i did not see
timotimo \o/ 20:01
brrt i'd complain about your barbaric indentation, but that would serve noone :-)
timotimo in my patch or in the thing i pasted? 20:02
brrt patch, but it doesn't matter 20:03
cool
very cool
timotimo++
timotimo oh no what did i do
oh, perhaps the multiline if?
i haven't found a good solution to how to do these :( 20:04
brrt hmm, i think emacs indents them directly to the parentheses of the if
but like i said, doesn't matter :-)
timotimo yeah, but then won't it be the exact same position as the code in the ifs code block? 20:06
brrt hmm, yes 20:09
good point
timotimo that's why i put the extra 4 spaces
20:14 zakharyas joined
dalek arVM/even-moar-jit: b15b90a | brrt++ | / (7 files):
Allow tiler table generator to specify args

This is actually a complete refactor of the tiler table generator to support arguments in tiles, to not use a plethora of global variables, and to compute the optimum rule given a ruleset more completely. (Which is unfinished, but I think I know how to complete it). As a result, small changes throughout the tiler and tile implementations were necessary. eq/lt/gt and friends have also been reduced to a single cmp tile implementation.
20:21
brrt anyway, as far as i know that commit unblocks the work on the tiler linearisation 20:22
timotimo neato!
glad to hear you're coming along :)
brrt and, importantly, that commit still works with nqp :-)
jnthn brrt++ # perserverance :)
timotimo nice!
jnthn uh, I'm sure I spelt that wrong :) 20:23
brrt :-)
timotimo it doesn't look wrong to me
better to have perseverance than to have preserverance
or having to preserve rants
brrt or to have to increase your font because these words all look too much alike
i'll be off now :-)
moritz has got to preserve france
jnthn Have a nice evening o/ 20:24
moritz or so :-)
brrt you too o/
20:44 dalek joined
[Coke] perseverates. 20:45
21:05 leont joined
timotimo jnthn: do you think you can spot something wrong with the no_atomic_if_single_threaded branch? it's just a single commit and it makes multi-threaded tests in the spec test suite livelock 21:30
21:34 colomon joined
timotimo using "my int $n = 0; while $n < 50_000_000 { $n++ }" for a benchmark, it goes from 21.1s to 19.4s with the patch 21:40
m: say "not using atomics for frame refcounts gets us to { 19.4 / 21.1 }x as much time spent" 21:41
camelia rakudo-moar 704c58: OUTPUT«not using atomics for frame refcounts gets us to 0.919431x as much time spent␤»
timotimo 8% time improvement; not the biggest win, but can surely be felt
i wonder if the improvement gets bigger if deeper call stacks are involved 21:43
as dereferencing a frame derefs the caller pointer, too. and that can recurse 21:44
21:45 domidumont joined
jnthn timotimo: There's already a function for checking if there are threads, fwiw 21:48
It'd be better to use that
timotimo oh, can do!
jnthn fixedsizealloc.c calls it in the free at safepoint function, for example
21:50 Peter_R joined
timotimo ah, i see it 21:53
i'm not sure why, but that seems to indeed fix the problem 22:03
damn, that's sweet
jnthn :) 22:04
timotimo have permission to merge? and someone a bit cleverer can look at MVM_frame_acquire_ref getting a no-atomic version, too
jnthn Can you push an updated patch for me to glance over? 22:05
timotimo mind if i force-push, or just add on top of it?
22:06 lizmat joined
jnthn force is fine 22:06
timotimo urgh, i have a merge situation going on locally because too many changes in working copy %) 22:08
dalek arVM/no_atomic_if_single_threaded: c65ea1b | timotimo++ | src/core/frame.c:
cheaper access to ref counts if only 1 thread exists.

MVM_frame_acquire_ref also ought to be enhanced like this
22:10
timotimo that's rebased onto master and melded the old commit and the MVM_has_user_thread function change into one commit 22:11
jnthn timotimo: Holy code dupe...
I think that
- while (MVM_decr(&frame->ref_count) == 1) { 22:12
Wants to be replaced with while (some_static_fnction(tc, frame) == 1) {
timotimo oh, that'd be kind of better 22:13
jnthn Where that static function does the if
timotimo MVM_STATIC_INLINE?
jnthn If you mark it MVM_INLINE_STATIC then it'll get inlined
timotimo that's the one
actually, mine's the one
hmm. freeing something at a safe point ... isn't that only relevant if we have multiple threads? 22:14
jnthn yes, thus why if we're in single threaded mode we free it right away 22:15
timotimo ah, indeed! 22:16
very good
leont spend much of the past week dealing with refcounting issues (in a different project). Ran into some fun issues where the reference was thread safe, but the referee wasn't :-/. 22:17
timotimo ugh
diakopter well you need the MVM_decr in there *somewhere* (in the slow path) 22:33
22:33 colomon joined
diakopter I don't know why you'd take it out entirely 22:33
oh, I see what you're saying, put the branch in a function 22:34
gotha
jnthn Right :)
timotimo why was i confident about the branch before? it seems to hang some multi-threaded tests again 22:54
leont Sounds like my entire week! 22:56
diakopter timotimo: push the branch and I'll look at the diff? 22:57
timotimo sure
dalek arVM/no_atomic_if_single_threaded: ca20e3c | timotimo++ | src/core/frame.c:
cheaper access to ref counts if only 1 thread exists.

MVM_frame_acquire_ref also ought to be enhanced like this
22:58
timotimo i git push -f'd over it again, because i'm naughty like that
diakopter lol ok
timotimo detecting force-pushes could be a thing that dalek does ... it'd probably be a bit of work, though 22:59
diakopter you need a ! in the function's check 23:00
if (!MVM_instance_have_user_threads(tc)) {
or swap the branches, of course
timotimo ha!
thank you! that's excellent! 23:01
diakopter you're eggsellent
timotimo man, you have such a fresh pair of eyes
diakopter the better to eat you with
timotimo you want to eat your fresh pair of eyes as a side dish to go with tasty timo flesh? 23:03
diakopter that too
23:04 pyrimidine joined
timotimo if we're single-threaded, do it slow. if we're multi-threaded, do it unsafe! what a flawless plan! 23:05
diakopter actually wait 23:06
timotimo actually waits
do you want to say we should totally multi-thread dereferencing of frames? 23:07
diakopter frames are also released during GC cleanup, which happens in another thread 23:08
timotimo wait. it does? 23:09
i didn't know we actually do that?
i know we wanted to have a second thread that handles things that require "free" to be called
diakopter find all the places that call MVM_frame_dec_ref 23:12
timotimo sure will 23:13
nothing in the gc, but things in the reprs
diakopter anything from gc_free ? 23:14
timotimo oddly enough, no 23:16
where did you find something?
diakopter well is your branch working now? 23:19
timotimo yeah 23:20
diakopter so push it :D
er, merge it
timotimo there's a few things that explode in the spec tests but tthat doesn't seem like my fault
like, t/spec/S17-scheduler/at.rakudo.moar dies with Method 'cancel' not found for invocant of class 'Any'
diakopter hm well do they explode using master
timotimo not ok 24 - multiple occurence for named array param 23:21
for t/spec/S06-other/main-usage.rakudo.moar
t/spec/S32-array/adverbs.t fails test 21, but only if run in the test harness
diakopter sigh 23:22
timotimo t/spec/S32-io/IO-Socket-Async.t only fails in the harness, too
t/spec/S32-hash/adverbs.t is the same as the array one
t/spec/S32-io/socket-recv-vs-read.t also only fails in the harness
crashes in the harness, that is.
lizmat timotimo: so how do you not it actually crashes? 23:32
timotimo lizmat: perl6 filename; exit code's 0 :) 23:35
lizmat timotimo: but then it doesn't run under the harness ??
timotimo yeah. if i run it under the harness, i.e. make spectest, it fails 23:38
i.e. exitcode != 0
diakopter nine was seeing tests silently fail under the harness when TEST_JOBS > 1... I wonder if it's related
timotimo huh 23:39
silently fail? what does silently in this case mean?
i'll run a spec test with 1 test job
diakopter they "passed" when run with TEST_JOBS > 1, but failed otherwise
timotimo um ... what? 23:40
that's ... different :o
lizmat: when you run spec tests, are they clean? they aren't for me. neither on moar's master nor on moar's no_atomic_if_single_threaded ... 23:41
lizmat timotimo: they haven't been clean for over a week for me 23:42
timotimo OK, good to know
lizmat I'll have an up-to-date list for you shortly
timotimo i would ticket + fudge something, but then the tests run to completion without failure when i run them individually ...
diakopter sounds like it's using a different lib or binary 23:44
timotimo i made extra sure to "make install" before
but i can double-check once this spec test run is finished 23:45
diakopter hrm
but are you running from the install location?
timotimo nah, from inside rakudo/
i think that's the same thing "make spectest" does
lizmat timotimo: gist.github.com/lizmat/b1be7dce17c5e639625b # spectest status 23:46
diakopter well, the perl6-m script in rakudo/ runs all the things from the putative install location
exec /home/mwilson/src/rakudo/install/bin/moar --execname="$0" --libpath="/home/mwilson/src/rakudo/install/share/nqp/lib" --libpath="." /home/mwilson/src/rakudo/perl6.moarvm "$@" 23:48
well, the nqp things
timotimo lizmat: that looks just a bit different from mine :|
lizmat timotimo: I'm not getting the same every time... lemme run one again
timotimo yeah. me neither :( 23:49
diakopter me nyether
timotimo github.com/coke/perl6-roast-data/c...4ebf5L4785 23:53
cokes roast data also has something to say
lizmat hmmm.. second one identical to first 23:54
timotimo oh hey! 23:56
this time only at.rakudo.moar, main-usage.rakudo.moar, and both adverbs.t failed! 23:57
that's fewer than all my last runs!