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! |