01:18 FROGGS_ joined 02:09 colomon joined 03:46 ingy joined 07:03 zakharyas joined 07:15 avuserow joined
sergot o/ 07:45
nwc10 \o 08:37
09:02 kjs_ joined 09:50 woolfy joined, anon joined 10:02 ggoebel11111119 joined 10:17 Ven joined
dalek arVM/moritz/debian: de6fc0d | moritz++ | debian/ (22 files):
Add pristine debian/ dir, as generated by dh-make
 10:19
arVM/moritz/debian: 55c2d43 | moritz++ | debian/source/format:
[debian], no, not quilt
arVM/moritz/debian: 7f9f2d5 | moritz++ | debian/changelog:
[debian] changelog
arVM/moritz/debian: ed85c08 | moritz++ | debian/control:
[debian] fill out control file
anon moritz: how about dir is ports/debian ? 10:26
moritz anon: debian packaging tools expect the data to be in debian/
anon: but I want to keep it in a separate branch, and after a release, merge the release tag into the branch
anon oh 10:27
moritz: I saw parrot has a ports/debian dir 10:28
but I don't know debian packaging tools :P
dalek arVM/moritz/debian: 608e77d | moritz++ | debian/rules:
[debian] try to flesh out rules file
 10:37
arVM/moritz/debian: 4263f81 | moritz++ | debian/copyright:
[debian] fill out copyright file
 10:44
moritz is thorougly confused by the way debian packages are built 10:51
nwc10 they use specially aligned mirrors to herd smoke into bottles?
moritz coherent smoke, it seems
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:52
moritz it's called SASEMS (Smoke Amplification by Stimulate Emission of Moar Smoke) 10:58
does anybody else get modified: 3rdparty/dyncall (untracked content) in Moar? 11:01
when doing 'git status' in MoarVM, that is
nwc10 yes
timotimo yes
probably due to the build and not complete coverage of gitignore?
moritz yes 11:02
timotimo yeah, it points out lots of Makefiles that are not tracked
moritz ok, I'll try to .gitignore them 11:05
timotimo do we "own" that repository?
ah. yes, we do. 11:09
dalek arVM: d94d7b8 | moritz++ | 3rdparty/dyncall:
bump to a dyncall version with more complete .gitignore
 11:10
11:22 Ven joined 11:35 brrt joined
brrt o/ 11:35
nwc10 brrt: valgrind FAQ on JITted code: PostgreSQL 11:39
aarg
valgrind.org/docs/manual/faq.html#faq.java 11:40
*that* there.
anyway, I don't think that we hit the problem about reused code *yet*
but they mention VALGRIND_DISCARD_TRANSLATIONS and I have no idea what that is
but it might become relevant
11:42 brrt joined
brrt \o again 11:43
11:54 anon_ joined
jnthn evening, #moarvm 12:57
nwc10 heresy! :-) 12:58
anon evening, jnthn :) 12:59
jnthn nwc10: It's certainly evening here :) 13:01
I would say it's dark outside, but so neon... :) 13:02
13:07 brrt joined 13:08 anon_ joined
brrt jnthn: one more thing to do it seems, which is upload code 13:09
have we agreed on uploading a git log -p style patchlog?
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
i... dunno really
i've seen talk about submitting patches and the likes
jnthn brrt: Otherwise, just go for src/jit/ :)
brrt yeah, that's possible too
except that misses the difficult parts ;-)
and ehm, i thought about removing the huge dasm output files because they obscure the real changes 13:12
jnthn *nod*
Yeah, both good points.
brrt did you get to take a look at the misspesh in bug 127? 13:13
i didn't yet
:-)
brrt is clearly going to miss his SoC time this year :-( 13:14
13:24 jnap joined
jnthn brrt: At least that means it was enough fun to miss... 13:29
brrt yeah that is true 13:30
how was your flight btw? :-)
jnthn Fine overall. A small delay. Besides that, just long. 13:32
brrt yeah, i can imagine 13:35
jnthn Then a few hours to do airport => hotel.
Though that was still better than a 3-hop flight to get to a closer airport...
13:36 JimmyZ_ joined 13:37 JimmyZ__ joined
brrt was already quite tired from a single flight + train 13:39
japhb jnthn: Are you back home? Or did you go somewhere different after YAPC::EU? 14:32
jnthn japhb: Somewhere else, for $dayjob assignment.
japhb Ah, is this the "month away" that you've mentioned before? 14:34
What country are you in now?
jnthn Yes. China. 14:35
Thus the long trip :) 14:36
japhb Woah. Yeah, that would do it. 14:38
[Coke] Nǐ huì shuō pǔtōnghuà ma? 14:47
jnthn Bu hui :(
Though I suspect I'll pick some basics up. :)
[Coke] that is almost literally all the mandarin I can speak. :) 14:48
Got stuck after the first cd. :)
brrt :-o 15:15
brrt hopes to look at the misspesh thingy tonight, but isn't quite sure if he'll have energy left 15:19
15:37 JimmyZ joined
JimmyZ jnthn: Which city are you in? 15:38
dalek Heuristic branch merge: pushed 43 commits to MoarVM/moritz/debian by moritz 16:17
arVM/moritz/debian: 44b5097 | moritz++ | debian/rules:
[debian] tweak rules

still does not work at all :(		 16:31
TimToady div between two native ints doesn't jit yet; anyone know why, offhand? 16:32
I've got 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
otherwise, I think it'd run considerably faster
though we're stilll about 50 times sloer than D on this
*w 16:37
the tight loop ought all fit into registers, I'd think, eventually 16:38
*oughta
16:44 Util joined
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:48
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:50
profile says div takes 20% of the time, but I suspect it's really more 16:51
16:51 jnap joined 16:57 tadzik joined 17:04 tadzik joined, Util joined 17:09 Util joined 17:15 tadzik joined
moritz TimToady: maybe the semantics of div with negative numbers doesn't match the machine instructions, thus no JITting yet? 17:18
TimToady eh, div should just be 2's complement semantics; how could it not match the machine instructions? 17:22
17:23 tgt joined
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
in any case, I'm only using positive nubmers
not to mention numbers
or maybe spesh hasn't figured out that both sides of the div are always int 17:25
well, but it says div itself is speshed in the profile
timotimo: you know anything about that? 17:26
are we supposedly jitting div yet?
(on int) 17:27
timotimo i can have a look
it's usually helpful to get a MVM_JIT_LOG to see what ops it bails on
TimToady the gist above should manifest the issue 17:28
timotimo ah
well, look at the way div_i is implemented in src/core/interp.c on line 331
TimToady it's an nqp version of the RC entry I just did
timotimo (i think i wrote that code)
ah, this is for nqp?
TimToady no, P6 calling nqp:: 17:29
timotimo yes, now that i actually *looked*, it's very obvious
... ah yes
the last for loop shows that
TimToady but the tight loop is *almost* all jitted except for div, according to profile
timotimo well, the problem could begin as soon as trying to inline the body of div into that loop 17:30
however
div_I isn't mapped on the jit yet
TimToady I is Int rather than int?
TimToady doesn't think he's using Int there 17:31
timotimo i shall --target=optimize that and see what exactly it calls
TimToady $n and $ten are both declared int, and there's no intermediate values
timotimo - QAST::Op(callstatic &infix:<div>) div 17:32
interestingly it doesn't inline that at QAST time
FROGGS TimToady: the uppercase *_I ops are about bigints, aye
TimToady something to do with catching div-by-0 perhaps?
timotimo div_i and mod_i turn into an idiv assembly instruction 17:33
oh 17:34
yes, the div subroutine begins with a "fail if ...", which might cause bails in multiple places
perhaps that also causes the jit to not want to inline/jit it 17:35
can you try removing that line?
FROGGS commenting it out and recompiling rakudo will just take a minute, so one could just check that :o)
timotimo another thing you can do is to just write nqp::div_i instead of infix-div 17:36
i'll be AFK for maybe an hour now
TimToady thanks
timotimo you're most welcome :)
TimToady nqp::div_i makes it run *twice* as fast, nearly 17:37
timotimo you know ...
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
that'll still give us the div by zero exception, but possibly make it more inline-friendly
TimToady is all in favor of faster as long as it's correct
timotimo .o( and the jit might want to learn about div by zero, too ... )
TimToady profile shows the div is now jitted
timotimo "now" is "after removing the fail", yes? 17:39
TimToady so the remaining factor of 25x or so has gotta be suboptimal assembly
using nqp::div_i instead
timotimo ah
TimToady does that have a fail?
TimToady presumes not
timotimo Int.pm line 157 is the one i meant 17:40
TimToady m: say nqp::div_i(42,0)
camelia rakudo-moar 8af523: OUTPUT«Division by zero␤ in block <unit> at /tmp/1tBRzrrJCr:1␤␤»
timotimo nqp::div_i doesn't; except it has a check + throw_adhoc in interp.c
TimToady something catches it
timotimo line 331 in moarvm's src/core/interp.c
TimToady wouldn't've thought it would look that complicated... 17:43
17:51 Ven joined 18:26 Ven joined 18:45 kjs_ joined 18:48 Ven joined 18:55 brrt joined
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:00
TimToady there could be multiple current ops if you're running concurrent 19:01
FROGGS I dont think I do 19:02
is just invokes v5 with an empty v5 block
TimToady just sayin' there ain't gonna be a handy global containing it
brrt i'm going to see why div doesn't jit 19:03
or rather
if div doesn't jit]
TimToady timotimo++ was looking at it
brrt oh ok :-) just as well
TimToady he thought it was the fail if
putting nqp::div_i in place of infix:<div> makes it jit though 19:04
at least, if I read the profile right
FROGGS I think I recompile with CGOTO enabled an just add a printf to the runloop...
TimToady that one thing makes it run twice as fast
but you'd think spesh could narrow it down to nqp::div_i 19:05
so not sure what the problem is
brrt hmm
oh, div is p6 isn't it 19:06
TimToady yes
brrt hmm :-) 19:08
ok, i can tell you that i've indeed implemented the naive integer div already
so that isn't the problem
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?
FROGGS is there an easy way in C to check how long a program is running?
TimToady well, not an actual floor call
FROGGS then I could print a backtrace and exit after 20s or so
TimToady man times(2) 19:10
FROGGS thanks :o)
brrt oh, it may be floor
TimToady just emulating floor for negatives, at least in interp.c
brrt but ehm, i can't find the reference to infix<div> or anything like that in the spesh log
oh, i've found it
it bails on div_I 19:11
TimToady but both args are int, not Int
and there's no intermediate value
brrt well, that may be so, but the NQP compiler emits a div_I instruction 19:12
and spesh doesn't know - and i don't think it can represent - lowering from bigints to integers 19:13
or the perl6 compiler, i don't know which :-)
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
TimToady there are no bigints in that part of the program
brrt lemmesee how infix<div> is defined
TimToady maybe there's no int/int candidate 19:15
brrt could well be 19:16
TimToady but there is an int/int candidate, which calls div_i
brrt uh, yeah
TimToady mysterious
brrt what is more 19:17
that is actually the speshed candidate
(which i know from adding file-and-line numbers to the spesh log)
TimToady is the fail wedging it somehow? 19:18
brrt hmmm 19:20
its.. weird, i think the line number may be wrong
or not
it actually does fall down to div_i 19:21
but somehow it calls a method called sink? i just don't get it
FROGGS TimToady: works well, I think I know where I have to look now :o) gist.github.com/FROGGS/9e244524f94c524f15e2 19:23
brrt hmm i'm wong about this
div is actually JITted it seems
the int, int version 19:25
the Int, Int version is not
TimToady maybe it's just not inlining for some reason
though you'd think profile would report the non-inlined routine as jitted, not just speshed 19:26
19:28 donaldh joined, njmurphy joined
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
FROGGS so the question is more like: why does it pick the Int,Int candidate?
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
*mized
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
in particular, the op is now in charge of allocating the resulting bigint object, not the interpreter
19:32 tadzik joined
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
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
TimToady profile is definitely reporting the int,int version as speshed (but not jitted) 19:34
timotimo but not inlined, yeah?
TimToady apparently not
19:35 nick` joined
timotimo i still blame the fail instruction :) 19:35
19:35 njmurphy left, nick` left, njmurphy joined 19:36 Util joined
TimToady the ids routine is otherwise entirely green, and stays green with nqp::div_i, so it must be the inlining 19:37
timotimo i wonder if we can successfully inline the fail multi sub 19:40
TimToady I never tried to comment it yet 19:41
timotimo fail does getlexcaller
that's probably at least not jittable.
TimToady yes, commenting the fail lets it inline and jit it 19:43
19:44 Util joined
timotimo excellent 19:44
19:44 tadzik joined
TimToady it still traps Division by zero if you comment it, and that error is trappable with try 19:45
so maybe we should just leave out the fail?
timotimo well, there's still the difference between die and fail 19:46
TimToady trooo 19:47
maybe we need to find a jittable way to fail
timotimo did you look at why fail does getlexcaller?
it looks for a symbol named RETURN 19:48
that's gotta be the mechanism that does the "return an unthrown exception" piece
TimToady would a "return" also mess up an inline?
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
i don't think so 19:49
return should be fine
(but it might be simpler if it's just the last statement)
(last-statement-return instead of return-return)
TimToady 'use fatal' semantics to turn a fail into a die could be enforced on either the caller or callee end 19:50
it's lexically scoped on the caller end, so something to be said for doing it there
timotimo though ... we already have an opt that turns return-as-last-statement into no-explicit-return
TimToady but this one isn't the last statement, it's before the div_i
timotimo yeah 19:51
but you can turn it into an if that encapsulates both things
shouldn't that be fine?
TimToady ya'd think 19:52
timotimo oh, right ... this is performance-critical code
nothing is as you'd think :)
TimToady trying ??!! 19:53
timotimo WHAT ARE YOU TRYING??!! 19:54
TimToady no inline from $b ?? nqp::div_i($a, $b) !! fail X::Numeric::DivideByZero.new; 19:55
FROGGS 'fail' is too exotic me thinks 19:56
locating the RETURN for example
19:57 kjs_ joined
timotimo yes. 19:58
we can't really pass RETURN as a positional arg either, as fail has a *@msgs candidate 19:59
TimToady other problem is that we can't compile a Failure.new at that spot in the setting, seems to loop the compiler 20:04
timotimo ah, and just adding class Failure { ... } before that doesn't work either 20:06
?
TimToady yes, that works, and lets it inline: $b ?? nqp::div_i($a, $b) !! Failure.new(X::Numeric::DivideByZero.new); 20:09
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
well, anyway, I think we have a better handle on what's going on now
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
timotimo how is Int arithmetic going to work out when we have -Inf and Inf as Int?
TimToady we had a long discussion of that on #perl6 a few days ago 20:12
timotimo ah good
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
but I had some reason for wanting Inf overloaded, which I've forgotten
er, I keep typing Int when I mean Inf, duh
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:14
that's about as far as we got on it 20:15
m: say [min]()
camelia rakudo-moar 8af523: OUTPUT«Inf␤»
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:16
Inf is more of a concept in Perl 6, and IEEE Inf is just how it's represented in Num 20:17
that's what the original intent was, dunno if we can get there
timotimo ah 20:18
TimToady especially since I need a nap now
timotimo it does sound sane at first
good nop!
TimToady more important to sound sane at last :)
TimToady --> zzz &
brrt sleep well
timotimo heyo brrt 20:19
i'm glad you added line number annotations to spesh output :)
brrt hey timotimo :-)
glad to help :-) i needed them, too 20:21
have you seen issue 127 perchance
i'm going to log off now, see you tomorrow 20:23
20:23 brrt left
timotimo have not, will look 20:25
ah, 127 20:26
this one is puzzling :)
20:36 itz_ joined 20:44 itz joined 20:59 kjs_ joined 21:21 Ven joined 21:28 donaldh joined 21:33 woolfy1 joined 22:04 kjs_ joined 22:17 woolfy joined 22:50 ilbot3 joined 23:00 colomon joined 23:16 colomon 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!