Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-07-23

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

All times shown according to UTC.

Time Nick Message
01:32 lizmat joined #moarvm
04:19 Peter_R joined #moarvm
05:26 lizmat joined #moarvm
05:43 Peter_R joined #moarvm
06:12 FROGGS joined #moarvm
06:57 zakharyas joined #moarvm
07:09 brrt joined #moarvm
07:43 timotimo you know ...
07:43 timotimo one of the most amazing achievements of RPython and PyPy is that its traces go very deep into its guts
07:44 timotimo does it make any sense whatsoever to build some representation of what some of our internal functions do so that their insides could be traced as well?
07:45 timotimo that'd be three to five steps ahead of what we currently do when we devirtualize reprops or turn accesses to objects into direct memory offsets
07:45 brrt hmm
07:45 brrt i've thought about that
07:45 brrt there are roughly two ways to go about it
07:45 timotimo build our own C compiler!
07:46 brrt a): read the debugging information
07:46 brrt that'll tell you what-means-what
07:46 brrt b): disassemble the machine code
07:46 brrt c): some combination of a and b perhaps using tcc or something
07:47 timotimo trying to disassemble the machine code gcc, clang and msvc spit out seems like a gigantic task
07:47 timotimo especially since they have a ridiculous amount of cleverness
07:48 timotimo in any case, that idea can most probably be shelved until much, much later
07:49 timotimo if i want to build something helpful, i'd probably best finally build that tool that roughly picks jit/graph.c apart into some re-usable data format
07:49 brrt hmmm
07:49 timotimo and/or perhaps look at the code-gen problem about local/localref where a decont appears out of thin air
07:49 brrt if you would do that, i would be very very very grateful
07:50 brrt it's actually my work, of course :-)
07:50 timotimo and/or figure out what's keeping the if/unless + not_i/so_i from working
07:50 brrt anyway, dissassembling x64 machinecode is tricky but not undoable
07:51 timotimo i'd love to contribute to your work; if i can get rid of some rote work and you can concentrate on architecting and stuff, that'd be great
07:51 timotimo you can't undo it? ;)
07:51 brrt considering that you 'know' which things are calls, branches, returns
07:51 timotimo hm, well, i guess
07:51 brrt you can pretty reliably figure out what constitutes a function
07:51 brrt lol, no, ehm, i meant it's doable
07:51 timotimo :)
07:52 brrt ok, one of the things i think should be automatable, is conversion of your routine function call to exprlist format
07:52 brrt letmegetanexampleofthat
07:53 timotimo extract only the branches and turn it into an exprlist like "copy-paste this part of the already existing machine code here, build this branch, more machine code copied from here to there, a label, ..."?
07:56 brrt https://gist.github.com/bdw/8ed7638d265ff77d716e
07:56 brrt this would be an example
07:57 brrt the args[] thingy can be converted to the arglist
07:57 brrt each item represents a carg
07:57 timotimo oh
07:57 timotimo you're talking about graph.c to output format
07:57 brrt hey, i didn't say it was easy
07:58 brrt :-P
07:58 timotimo no problem, that'll be doable
07:58 brrt anyway, i don't want to dump this into your lap. only pick it up if you want it
07:59 brrt more difficult stuff, you can just bail out on; they can be converted by hand if necessary
08:00 brrt but there are a lot of these, and they all follow the same pattern
08:01 timotimo mhm
08:02 brrt you don't have to worry about the actual operand values, because the tree builder takes care of that
08:03 brrt another thing is, if you have a register you're writing to, (say wval), you can neglect that, too
08:03 brrt because the tree builder is responsible for that, too
08:04 timotimo the destination register?
08:04 brrt yes
08:04 brrt neglect it
08:04 brrt throw it to the wind
08:04 timotimo as in, what is -1 in your "from.c" example
08:04 brrt :-)
08:04 brrt can be ignored
08:04 timotimo so i'll just convert the JIT_RV_* for the last argument of "call"
08:05 brrt yes, i think so
08:05 timotimo mhm, fair enough
08:05 brrt for the last argument of carg, i think you can get away with just using ptr or int for most cases
08:06 brrt doesn't make a difference for us
08:07 timotimo mhm
08:07 brrt the num thing does make a difference. but it' might be tricky to detect
08:07 brrt actually, it's not so difficult, reg_val_f => num, otherwise, perhaps just use int?
08:10 timotimo "just use int" %)
08:10 timotimo so, still like in your example, then?
08:11 timotimo "carg $foo num"
08:20 timotimo rakudo already noms 3 gigs of ram before it even reaches the beginning of op_to_func ... i'm searching for it via .*?
08:20 timotimo what the ...
08:20 timotimo anyway, i've got to be off for a bit
08:23 Ven joined #moarvm
08:33 brrt see you :-)
08:33 brrt i'd... ehm... heretically suggest using perl5. but that's your business, of course :-)
08:51 brrt aargh why didn't i just finish it yesterday
08:51 * brrt bbiab
09:23 zakharyas joined #moarvm
09:28 brrt joined #moarvm
10:24 Ven joined #moarvm
10:43 JimmyZ_ joined #moarvm
10:53 timotimo i can't even perl5
12:07 timotimo aaah very clevre
12:07 timotimo clever
12:07 timotimo make a "rule ws"
13:23 masak really `rule` and not `token`...?
13:23 jnthn masak: That's why it was "clever" :P
13:24 masak "clever (adj.) -- ... (9) not clever. ..."
13:24 masak :P
13:28 brrt joined #moarvm
13:30 arnsholt joined #moarvm
13:32 brrt \o
13:33 timotimo oO
13:34 jnthn /o
13:36 brrt :-)
13:40 FROGGS o|)      »-->      (·)
13:42 FROGGS o|)                (·)  __
13:42 FROGGS damn it
13:43 jnthn lol
14:10 masak it actually takes some skill to miss when there's just one dimension :P
14:45 danaj joined #moarvm
14:59 brrt hmm
15:07 jnthn hmm?
15:11 brrt i wsa overly optimistic yesterday evening :-(
15:12 brrt *was
15:15 Ven joined #moarvm
15:16 brrt the trick, i think, is to reduce the amount of possible label sets
15:18 brrt e.g. the combination of labels that are possible
15:18 brrt let me think about that a bit more
15:24 FROGGS joined #moarvm
15:30 njmurphy joined #moarvm
15:49 avuserow joined #moarvm
16:12 brrt joined #moarvm
17:31 nwc10 timotimo: not sure if you'd seen this: http://blogs.perl.org/users/flavio_s_glock/2015/07/a-perl5-to-java-compiler---first-benchmark.html
17:32 nwc10 currently his codegen beats Rakudo's (and MoarVM's ability to spesh it)
17:32 nwc10 I'd love someone more competant than me to work out how to beat his code.
17:37 lizmat joined #moarvm
17:41 timotimo it doesn't do big integer semantics
17:41 timotimo are you measuring against "my int $i" and such?
17:43 nwc10 at jnthn's suggestion yesterday I tried that too. He still wins.
18:04 jnthn How to get faster: lexical to local lowering, scope elimination, escape analysis (capable of understanding loops), scalar elimination, induction variable stuff to optimize away the bigint upgrade checks, and then good machine code generation.
18:05 timotimo right, i want the lexical to local lowering to work again
18:05 timotimo really, really want :)
18:05 timotimo but wanting something doesn't magically make you capable of bringing it about …
18:05 timotimo jnthn: do you have a hunch for where a decont may be generated that doesn't explicitly mention "decont"?
18:06 timotimo also, does the mast compiler that's inside moarvm ever add stuff like that?
18:06 jnthn It adds them in response to :decont annotations in the mapping stuff
18:06 timotimo mhm
18:07 timotimo that's for inbound parameters, yeah? not for outbound?
18:07 jnthn Right
18:07 timotimo hmm
18:08 jnthn The lexical to local lowering is competing with getting multi-dim stuff done, getting the new S17 additions in place, squishing concurrency bugs, and probably will have to compete with whatever GLR task stealing is needed of me.
18:08 timotimo mhm
18:17 * timotimo has dinner
18:32 lizmat joined #moarvm
18:49 brrt joined #moarvm
18:54 brrt ooh, that's fairly cool
18:55 timotimo hm?
18:57 dalek MoarVM: c9d526f | moritz++ | docs/ChangeLog:
18:57 dalek MoarVM: Fill in some ChangeLog for 205.07
18:57 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c9d526fd31
18:58 brrt the perl5-to-java compiler
18:59 brrt question is, of course, how well does it work
18:59 brrt i think it's a static compiler, from the looks of it?
19:00 timotimo yeah, if it's anything like the rest of perlito
19:00 timotimo it is still perlito, right?
19:00 brrt aye
19:01 brrt well, that's still really cool
19:03 brrt the thing that puzzles me personally is how he creates good code for a stack machine
19:03 brrt stack machines are weird
19:07 brrt hmm
19:09 brrt ok, observation: most tilish things can be evaluated postorder
19:09 brrt some things cannot (if statements)
19:09 brrt however... some if statements are really good statements for tiling
19:10 timotimo it could be it creates java code rather than java bytecode?
19:10 brrt e.g. (if (all (foo) (bar)) (quix) (quam)) <- clearly if foo is false we can skip ahead directly to quam
19:11 jnthn timotimo: I think it does, yes
19:13 brrt oh, yes, right :-)
19:14 zakharyas joined #moarvm
19:15 vendethiel joined #moarvm
19:20 brrt how does it deal with e.g. eval statements
19:20 brrt or does it just include the compiler for that purpose
19:21 brrt hmm
19:21 brrt actually, it's not that simple of course
19:22 jnthn One of the more annoying things about targetting Java instead of JVM bytecode is "no goto2 :)
19:22 timotimo mhhh
19:22 timotimo every basic block becomes a method
19:23 timotimo and your lexpad becomes an object
19:23 moritz rakudo with moarvm master has quite a few spectest failures, and t/spec/integration/advent2014-day05.t hangs
19:23 moritz not a good day to cut a release :(
19:23 timotimo it *could* be one of my recent merges made that happen
19:23 timotimo hm, no
19:24 timotimo i didn't really do much
19:24 brrt what's goto2?
19:25 jnthn goto, followed by a typo'd " :P
19:27 moritz huh, hangs on recommended moar version too
19:28 * moritz could have sworn he (mostly successfully) spectested today
19:28 moritz oh, my rakudo wasn't quite up to date
19:39 moritz but it really seems test changes that broke so many of them for me
19:43 timotimo test changes broke tests?
19:46 dalek MoarVM/even-moar-jit: 3f60420 | brrt++ | src/jit/x64.tiles:
19:46 dalek MoarVM/even-moar-jit: Add file describing intial grammar of tiler
19:46 dalek MoarVM/even-moar-jit:
19:46 dalek MoarVM/even-moar-jit: I have yet to figure out how to practically map it to machine
19:46 dalek MoarVM/even-moar-jit: code, but it's a start.
19:46 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/3f6042056f
19:53 brrt ok, hope that may break me out of my impasse :-)
19:53 brrt still many things i'm not sure of
19:53 brrt but i'll manage eventually
20:03 ggoebel joined #moarvm
20:57 TEttinger joined #moarvm
21:49 Peter_R joined #moarvm
23:33 jnthn joined #moarvm
23:33 [Coke] joined #moarvm
23:33 sergot joined #moarvm
23:33 moritz joined #moarvm

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