Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-08-26

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

All times shown according to UTC.

Time Nick Message
01:18 FROGGS_ joined #moarvm
02:09 colomon joined #moarvm
03:46 ingy joined #moarvm
07:03 zakharyas joined #moarvm
07:15 avuserow joined #moarvm
07:45 sergot o/
08:37 nwc10 \o
09:02 kjs_ joined #moarvm
09:50 woolfy joined #moarvm
09:50 anon joined #moarvm
10:02 ggoebel11111119 joined #moarvm
10:17 Ven joined #moarvm
10:19 dalek MoarVM/moritz/debian: de6fc0d | moritz++ | debian/ (22 files):
10:19 dalek MoarVM/moritz/debian: Add pristine debian/ dir, as generated by dh-make
10:19 dalek MoarVM/moritz/debian: review: https://github.com/MoarVM/MoarVM/commit/de6fc0df90
10:19 dalek MoarVM/moritz/debian: 55c2d43 | moritz++ | debian/source/format:
10:19 dalek MoarVM/moritz/debian: [debian], no, not quilt
10:19 dalek MoarVM/moritz/debian: review: https://github.com/MoarVM/MoarVM/commit/55c2d4357d
10:19 dalek MoarVM/moritz/debian: 7f9f2d5 | moritz++ | debian/changelog:
10:19 dalek MoarVM/moritz/debian: [debian] changelog
10:19 dalek MoarVM/moritz/debian: review: https://github.com/MoarVM/MoarVM/commit/7f9f2d5aa8
10:19 dalek MoarVM/moritz/debian: ed85c08 | moritz++ | debian/control:
10:19 dalek MoarVM/moritz/debian: [debian] fill out control file
10:19 dalek MoarVM/moritz/debian: review: https://github.com/MoarVM/MoarVM/commit/ed85c0880b
10:26 anon moritz: how about dir is ports/debian ?
10:26 moritz anon: debian packaging tools expect the data to be in debian/
10:26 moritz anon: but I want to keep it in a separate branch, and after a release, merge the release tag into the branch
10:27 anon oh
10:28 anon moritz: I saw parrot  has a ports/debian dir
10:28 anon but I  don't know debian  packaging tools :P
10:37 dalek MoarVM/moritz/debian: 608e77d | moritz++ | debian/rules:
10:37 dalek MoarVM/moritz/debian: [debian] try to flesh out rules file
10:37 dalek MoarVM/moritz/debian: review: https://github.com/MoarVM/MoarVM/commit/608e77d263
10:44 dalek MoarVM/moritz/debian: 4263f81 | moritz++ | debian/copyright:
10:44 dalek MoarVM/moritz/debian: [debian] fill out copyright file
10:44 dalek MoarVM/moritz/debian: review: https://github.com/MoarVM/MoarVM/commit/4263f810ac
10:51 * moritz is thorougly confused by the way debian packages are built
10:51 nwc10 they use specially aligned mirrors to herd smoke into bottles?
10:51 moritz coherent smoke, it seems
10:52 nwc10 oh, very special magic smoke? So like the way a laser plus regular smoke makes pretty lines, this smoke plus regular lights makes pretty lines?
10:58 moritz it's called SASEMS (Smoke Amplification by Stimulate Emission of Moar Smoke)
11:01 moritz does anybody else get modified:   3rdparty/dyncall (untracked content) in Moar?
11:01 moritz when doing 'git status' in MoarVM, that is
11:01 nwc10 yes
11:01 timotimo yes
11:01 timotimo probably due to the build and not complete coverage of gitignore?
11:02 moritz yes
11:02 timotimo yeah, it points out lots of Makefiles that are not tracked
11:05 moritz ok, I'll try to .gitignore them
11:05 timotimo do we "own" that repository?
11:09 timotimo ah. yes, we do.
11:10 dalek MoarVM: d94d7b8 | moritz++ | 3rdparty/dyncall:
11:10 dalek MoarVM: bump to a dyncall version with more complete .gitignore
11:10 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d94d7b86b3
11:22 Ven joined #moarvm
11:35 brrt joined #moarvm
11:35 brrt o/
11:39 nwc10 brrt: valgrind FAQ on JITted code: PostgreSQL
11:39 nwc10 aarg
11:40 nwc10 http://valgrind.org/docs/manual/faq.html#faq.java
11:40 nwc10 *that* there.
11:40 nwc10 anyway, I don't think that we hit the problem about reused code *yet*
11:40 nwc10 but they mention  VALGRIND_DISCARD_TRANSLATIONS and I have no idea what that is
11:40 nwc10 but it might become relevant
11:42 brrt joined #moarvm
11:43 brrt \o again
11:54 anon_ joined #moarvm
12:57 jnthn evening, #moarvm
12:58 nwc10 heresy! :-)
12:59 anon evening, jnthn :)
13:01 jnthn nwc10: It's certainly evening here :)
13:02 jnthn I would say it's dark outside, but so neon... :)
13:07 brrt joined #moarvm
13:08 anon_ joined #moarvm
13:09 brrt jnthn: one more thing to do it seems, which is upload code
13:09 brrt have we agreed on uploading a git log -p style patchlog?
13:10 jnthn brrt: Do they accept that?
13:10 brrt (if i'm cranky today, it is 100% to do with being forced into $dayjob again
13:10 brrt i... dunno really
13:10 brrt i've seen talk about submitting patches and the likes
13:10 jnthn brrt: Otherwise, just go for src/jit/ :)
13:10 brrt yeah, that's possible too
13:10 brrt except that misses the difficult parts ;-)
13:12 brrt and ehm, i thought about removing the huge dasm output files because they obscure the real changes
13:12 jnthn *nod*
13:12 jnthn Yeah, both good points.
13:13 brrt did you get to take a look at the misspesh in bug 127?
13:13 brrt i didn't yet
13:13 brrt :-)
13:14 * brrt is clearly going to miss his SoC time this year :-(
13:24 jnap joined #moarvm
13:29 jnthn brrt: At least that means it was enough fun to miss...
13:30 brrt yeah that is true
13:30 brrt how was your flight btw? :-)
13:32 jnthn Fine overall. A small delay. Besides that, just long.
13:35 brrt yeah, i can imagine
13:35 jnthn Then a few hours to do airport => hotel.
13:35 jnthn Though that was still better than a 3-hop flight to get to a closer airport...
13:36 JimmyZ_ joined #moarvm
13:37 JimmyZ__ joined #moarvm
13:39 * brrt was already quite tired from a single flight + train
14:32 japhb jnthn: Are you back home?  Or did you go somewhere different after YAPC::EU?
14:32 jnthn japhb: Somewhere else, for $dayjob assignment.
14:34 japhb Ah, is this the "month away" that you've mentioned before?
14:34 japhb What country are you in now?
14:35 jnthn Yes. China.
14:36 jnthn Thus the long trip :)
14:38 japhb Woah.  Yeah, that would do it.
14:47 [Coke] Nǐ huì shuō pǔtōnghuà ma?
14:47 jnthn Bu hui :(
14:47 jnthn Though I suspect I'll pick some basics up. :)
14:48 [Coke] that is almost literally all the mandarin I can speak. :)
14:48 [Coke] Got stuck after the first cd. :)
15:15 brrt :-o
15:19 * brrt hopes to look at the misspesh thingy tonight, but isn't quite sure if he'll have energy left
15:37 JimmyZ joined #moarvm
15:38 JimmyZ jnthn: Which city are you in?
16:17 dalek Heuristic branch merge: pushed 43 commits to MoarVM/moritz/debian by moritz
16:31 dalek MoarVM/moritz/debian: 44b5097 | moritz++ | debian/rules:
16:31 dalek MoarVM/moritz/debian: [debian] tweak rules
16:31 dalek MoarVM/moritz/debian:
16:31 dalek MoarVM/moritz/debian: still does not work at all :(
16:31 dalek MoarVM/moritz/debian: review: https://github.com/MoarVM/MoarVM/commit/44b50978fa
16:32 TimToady div between two native ints doesn't jit yet; anyone know why, offhand?
16:36 TimToady I've got https://gist.github.com/TimToady/50673b486f09e836ff1e down to running in 4 seconds by using nqp ops, but the div in the tight loop only speshes, doesn't jit
16:36 TimToady otherwise, I think it'd run considerably faster
16:36 TimToady though we're stilll about 50 times sloer than D on this
16:37 TimToady *w
16:38 TimToady the tight loop ought all fit into registers, I'd think, eventually
16:38 TimToady *oughta
16:44 Util joined #moarvm
16:48 * TimToady wonders how much of that 50x is going back to the interpreter to do div, and how much of it is not using registers as well as we might...
16:50 TimToady does the profiled timing of div count the switch into and out of interpreter time, or is that attributed to the surrounding jitted code?
16:51 TimToady profile says div takes 20% of the time, but I suspect it's really more
16:51 jnap joined #moarvm
16:57 tadzik joined #moarvm
17:04 tadzik joined #moarvm
17:04 Util joined #moarvm
17:09 Util joined #moarvm
17:15 tadzik joined #moarvm
17:18 moritz TimToady: maybe the semantics of div with negative numbers doesn't match the machine instructions, thus no JITting yet?
17:22 TimToady eh, div should just be 2's complement semantics; how could it not match the machine instructions?
17:23 tgt joined #moarvm
17:24 TimToady unless someone's been hiding from me that Intel architecture is really 1's complement, or does all its integer math using floating point...
17:24 TimToady in any case, I'm only using positive nubmers
17:24 TimToady not to mention numbers
17:25 TimToady or maybe spesh hasn't figured out that both sides of the div are always int
17:25 TimToady well, but it says div itself is speshed in the profile
17:26 TimToady timotimo: you know anything about that?
17:26 TimToady are we supposedly jitting div yet?
17:27 TimToady (on int)
17:27 timotimo i can have a look
17:27 timotimo it's usually helpful to get a MVM_JIT_LOG to see what ops it bails on
17:28 TimToady the gist above should manifest the issue
17:28 timotimo ah
17:28 timotimo well, look at the way div_i is implemented in src/core/interp.c on line 331
17:28 TimToady it's an nqp version of the RC entry I just did
17:28 timotimo (i think i wrote that code)
17:28 timotimo ah, this is for nqp?
17:29 TimToady no, P6 calling nqp::
17:29 timotimo yes, now that i actually *looked*, it's very obvious
17:29 timotimo ... ah yes
17:29 timotimo the last for loop shows that
17:29 TimToady but the tight loop is *almost* all jitted except for div, according to profile
17:30 timotimo well, the problem could begin as soon as trying to inline the body of div into that loop
17:30 timotimo however
17:30 timotimo div_I isn't mapped on the jit yet
17:30 TimToady I is Int rather than int?
17:31 * TimToady doesn't think he's using Int there
17:31 timotimo i shall --target=optimize that and see what exactly it calls
17:31 TimToady $n and $ten are both declared int, and there's no intermediate values
17:32 timotimo - QAST::Op(callstatic &infix:<div>) div
17:32 timotimo interestingly it doesn't inline that at QAST time
17:32 FROGGS TimToady: the uppercase *_I ops are about bigints, aye
17:32 TimToady something to do with catching div-by-0 perhaps?
17:33 timotimo div_i and mod_i turn into an idiv assembly instruction
17:34 timotimo oh
17:34 timotimo yes, the div subroutine begins with a "fail if ...", which might cause bails in multiple places
17:35 timotimo perhaps that also causes the jit to not want to inline/jit it
17:35 timotimo can you try removing that line?
17:35 FROGGS commenting it out and recompiling rakudo will just take a minute, so one could just check that :o)
17:36 timotimo another thing you can do is to just write nqp::div_i instead of infix-div
17:36 timotimo i'll be AFK for maybe an hour now
17:36 TimToady thanks
17:36 timotimo you're most welcome :)
17:37 TimToady nqp::div_i makes it run *twice* as fast, nearly
17:37 timotimo you know ...
17:38 timotimo if we use an #!if moar block, we can catch the exception that the div_i opcode throws and use that to return a fail object instead
17:38 timotimo that'll still give us the div by zero exception, but possibly make it more inline-friendly
17:38 * TimToady is all in favor of faster as long as it's correct
17:38 timotimo .o( and the jit might want to learn about div by zero, too ... )
17:38 TimToady profile shows the div is now jitted
17:39 timotimo "now" is "after removing the fail", yes?
17:39 TimToady so the remaining factor of 25x or so has gotta be suboptimal assembly
17:39 TimToady using nqp::div_i instead
17:39 timotimo ah
17:39 TimToady does that have a fail?
17:39 * TimToady presumes not
17:40 timotimo Int.pm line 157 is the one i meant
17:40 TimToady m: say nqp::div_i(42,0)
17:40 camelia rakudo-moar 8af523: OUTPUT«Division by zero␤  in block <unit> at /tmp/1tBRzrrJCr:1␤␤»
17:40 timotimo nqp::div_i doesn't; except it has a check + throw_adhoc in interp.c
17:40 TimToady something catches it
17:40 timotimo line 331 in moarvm's src/core/interp.c
17:43 TimToady wouldn't've thought it would look that complicated...
17:51 Ven joined #moarvm
18:26 Ven joined #moarvm
18:45 kjs_ joined #moarvm
18:48 Ven joined #moarvm
18:55 brrt joined #moarvm
19:00 FROGGS is there a way to print what op is currently being executed in moar? I've got an infiniloop and don't know how to debug further...
19:01 TimToady there could be multiple current ops if you're running concurrent
19:02 FROGGS I dont think I do
19:02 FROGGS is just invokes v5 with an empty v5 block
19:02 TimToady just sayin' there ain't gonna be a handy global containing it
19:03 brrt i'm going to see why div doesn't jit
19:03 brrt or rather
19:03 brrt if div doesn't jit]
19:03 TimToady timotimo++ was looking at it
19:03 brrt oh ok :-) just as well
19:03 TimToady he thought it was the fail if
19:04 TimToady putting nqp::div_i in place of infix:<div> makes it jit though
19:04 TimToady at least, if I read the profile right
19:04 FROGGS I think I recompile with CGOTO enabled an just add a printf to the runloop...
19:04 TimToady that one thing makes it run twice as fast
19:05 TimToady but you'd think spesh could narrow it down to nqp::div_i
19:05 TimToady so not sure what the problem is
19:05 brrt hmm
19:06 brrt oh, div is p6 isn't it
19:06 TimToady yes
19:08 brrt hmm :-)
19:08 brrt ok, i can tell you that i've indeed implemented the naive integer div already
19:08 brrt so that isn't the problem
19:09 brrt if there is a problem then it's because i haven't jitted something that's used in div yet
19:09 TimToady is it the chicanery with negatives and floors?
19:09 FROGGS is there an easy way in C to check how long a program is running?
19:09 TimToady well, not an actual floor call
19:09 FROGGS then I could print a backtrace and exit after 20s or so
19:10 TimToady man times(2)
19:10 FROGGS thanks :o)
19:10 brrt oh, it may be floor
19:10 TimToady just emulating floor for negatives, at least in interp.c
19:10 brrt but ehm, i can't find the reference to infix<div> or anything like that in the spesh log
19:10 brrt oh, i've found it
19:11 brrt it bails on div_I
19:11 TimToady but both args are int, not Int
19:11 TimToady and there's no intermediate value
19:12 brrt well, that may be so, but the NQP compiler emits a div_I instruction
19:13 brrt and spesh doesn't know - and i don't think it can represent - lowering from bigints to integers
19:13 brrt or the perl6 compiler, i don't know which :-)
19:14 TimToady perhaps I should try declaring them uint instead...
19:14 brrt and the reason div_I hasn't been implemented yet, as far as i can tell,, is that it's calling convention is different from other bigint calls
19:14 TimToady there are no bigints in that part of the program
19:14 brrt lemmesee how infix<div> is defined
19:15 TimToady maybe there's no int/int candidate
19:16 brrt could well be
19:16 TimToady but there is an int/int candidate, which calls div_i
19:16 brrt uh, yeah
19:16 TimToady mysterious
19:17 brrt what is more
19:17 brrt that is actually the speshed candidate
19:17 brrt (which i know from adding file-and-line numbers to the spesh log)
19:18 TimToady is the fail wedging it somehow?
19:20 brrt hmmm
19:20 brrt its.. weird, i think the line number may be wrong
19:20 brrt or not
19:21 brrt it actually does fall down to div_i
19:21 brrt but somehow it calls a method called sink? i just don't get it
19:23 FROGGS TimToady: works well, I think I know where I have to look now :o) https://gist.github.com/FROGGS/9e244524f94c524f15e2
19:23 brrt hmm i'm wong about this
19:23 brrt div is actually JITted it seems
19:25 brrt the int, int version
19:25 brrt the Int, Int version is not
19:25 TimToady maybe it's just not inlining for some reason
19:26 TimToady though you'd think profile would report the non-inlined routine as jitted, not just speshed
19:28 donaldh joined #moarvm
19:28 njmurphy joined #moarvm
19:29 TimToady and certainly something changes when it uses nqp::div_i direclty, since it's twice as fast
19:29 * TimToady likes N times as faster where N is an integer > 1
19:29 FROGGS so the question is more like: why does it pick the Int,Int candidate?
19:30 TimToady if it was picking the Int,Int candidate, it would never have optimizes the int,int candidate, which I though it did, at least to spesh it
19:30 TimToady *mized
19:31 TimToady which seems to prove it was calling it
19:31 timotimo jnthn was changing the call convention of the bigint ops so that the jit would have an easier time calling them
19:31 timotimo in particular, the op is now in charge of allocating the resulting bigint object, not the interpreter
19:32 tadzik joined #moarvm
19:32 timotimo div_I just didn't get changed because nobody has done it yet
19:32 TimToady but let me double check that --profile is looking at that line in int/int
19:33 timotimo has anybody actually tried to remove the "fail X::DivisionByZero.new if $b == 0" line and see if it's better
19:33 FROGGS I havn't
19:34 TimToady profile is definitely reporting the int,int version as speshed (but not jitted)
19:34 timotimo but not inlined, yeah?
19:34 TimToady apparently not
19:35 nick` joined #moarvm
19:35 timotimo i still blame the fail instruction :)
19:35 njmurphy left #moarvm
19:35 nick` left #moarvm
19:35 njmurphy joined #moarvm
19:36 Util joined #moarvm
19:37 TimToady the ids routine is otherwise entirely green, and stays green with nqp::div_i, so it must be the inlining
19:40 timotimo i wonder if we can successfully inline the fail multi sub
19:41 TimToady I never tried to comment it yet
19:41 timotimo fail does getlexcaller
19:41 timotimo that's probably at least not jittable.
19:43 TimToady yes, commenting the fail lets it inline and jit it
19:44 Util joined #moarvm
19:44 timotimo excellent
19:44 tadzik joined #moarvm
19:45 TimToady it still traps Division by zero if you comment it, and that error is trappable with try
19:45 TimToady so maybe we should just leave out the fail?
19:46 timotimo well, there's still the difference between die and fail
19:47 TimToady trooo
19:47 TimToady maybe we need to find a jittable way to fail
19:47 timotimo did you look at why fail does getlexcaller?
19:48 timotimo it looks for a symbol named RETURN
19:48 timotimo that's gotta be the mechanism that does the "return an unthrown exception" piece
19:48 TimToady would a "return" also mess up an inline?
19:48 timotimo it'd be neat if we had an internals-only version of fail that we'd put as the last statement of the sub
19:49 timotimo i don't think so
19:49 timotimo return should be fine
19:49 timotimo (but it might be simpler if it's just the last statement)
19:49 timotimo (last-statement-return instead of return-return)
19:50 TimToady 'use fatal' semantics to turn a fail into a die could be enforced on either the caller or callee end
19:50 TimToady it's lexically scoped on the caller end, so something to be said for doing it there
19:50 timotimo though ... we already have an opt that turns return-as-last-statement into no-explicit-return
19:50 TimToady but this one isn't the last statement, it's before the div_i
19:51 timotimo yeah
19:51 timotimo but you can turn it into an if that encapsulates both things
19:51 timotimo shouldn't that be fine?
19:52 TimToady ya'd think
19:52 timotimo oh, right ... this is performance-critical code
19:52 timotimo nothing is as you'd think :)
19:53 TimToady trying ??!!
19:54 timotimo WHAT ARE YOU TRYING??!!
19:55 TimToady no inline from     $b ?? nqp::div_i($a, $b) !! fail X::Numeric::DivideByZero.new;
19:56 FROGGS 'fail' is too exotic me thinks
19:56 FROGGS locating the RETURN for example
19:57 kjs_ joined #moarvm
19:58 timotimo yes.
19:59 timotimo we can't really pass RETURN as a positional arg either, as fail has a *@msgs candidate
20:04 TimToady other problem is that we can't compile a Failure.new at that spot in the setting, seems to loop the compiler
20:06 timotimo ah, and just adding class Failure { ... } before that doesn't work either
20:06 timotimo ?
20:09 TimToady yes, that works, and lets it inline: $b ?? nqp::div_i($a, $b) !! Failure.new(X::Numeric::DivideByZero.new);
20:10 TimToady now the only problem with that is that 'use fatal' will probably not work in the caller, unless it knows to handle failures on that end
20:10 TimToady well, anyway, I think we have a better handle on what's going on now
20:11 timotimo oh btw
20:11 TimToady I've always kind of thought that the burden should be on modules that say 'use fatal', not on everyone else
20:11 timotimo how is Int arithmetic going to work out when we have -Inf and Inf as Int?
20:12 TimToady we had a long discussion of that on #perl6 a few days ago
20:12 timotimo ah good
20:13 TimToady short answer, don't confuse the IEEE concept of Int with the Orderable role's concept of AfterEverythingElse, which might or might not show up with the name "Inf"
20:13 TimToady but I had some reason for wanting Inf overloaded, which I've forgotten
20:13 TimToady er, I keep typing Int when I mean Inf, duh
20:14 TimToady anyway, different types can maintain their own ideas of "off the end", probably, even if we choose to confuse them at a language level
20:15 TimToady that's about as far as we got on it
20:15 TimToady m: say [min]()
20:15 camelia rakudo-moar 8af523: OUTPUT«Inf␤»
20:16 TimToady what type is that, for instance?  what if it's the degenerate case of a string min, or of comparison in some type that is neither numeric nor string
20:17 TimToady Inf is more of a concept in Perl 6, and IEEE Inf is just how it's represented in Num
20:17 TimToady that's what the original intent was, dunno if we can get there
20:18 timotimo ah
20:18 TimToady especially since I need a nap now
20:18 timotimo it does sound sane at first
20:18 timotimo good nop!
20:18 TimToady more important to sound sane at last :)
20:18 * TimToady --> zzz &
20:18 brrt sleep well
20:19 timotimo heyo brrt
20:19 timotimo i'm glad you added line number annotations to spesh output :)
20:19 brrt hey timotimo :-)
20:21 brrt glad to help :-) i needed them, too
20:21 brrt have you seen issue 127 perchance
20:23 brrt i'm going to log off now, see you tomorrow
20:23 brrt left #moarvm
20:25 timotimo have not, will look
20:26 timotimo ah, 127
20:26 timotimo this one is puzzling :)
20:36 itz_ joined #moarvm
20:44 itz joined #moarvm
20:59 kjs_ joined #moarvm
21:21 Ven joined #moarvm
21:28 donaldh joined #moarvm
21:33 woolfy1 joined #moarvm
22:04 kjs_ joined #moarvm
22:17 woolfy joined #moarvm
22:50 ilbot3 joined #moarvm
22:50 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
23:00 colomon joined #moarvm
23:16 colomon joined #moarvm

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