Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-08-13

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

All times shown according to UTC.

Time Nick Message
00:02 lue joined #moarvm
01:24 FROGGS_ joined #moarvm
07:32 brrt joined #moarvm
07:40 itz_ joined #moarvm
07:50 dalek MoarVM: 91e6ce5 | (Bart Wiegmans)++ | src/jit/ (2 files):
07:50 dalek MoarVM: JIT scwbenable / scwbdisable
07:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/91e6ce59a9
07:52 FROGGS ohh, that seems rather important to have :o)
07:53 brrt there were quite a few bails of these
07:54 brrt and they're primitives properly
07:54 brrt so since - afaik - very few people have expressed an interest in x64 assembly, and since i don't mind, i think i'll implement as many as i can :-)
08:00 FROGGS *g*
08:00 FROGGS I guess I am too old to learn that... hey I mean I am older than jnthn O.o (which is not very hard, but still)
08:07 * brrt wonders how old jnthn really is
08:07 brrt never to old to learn anything
08:07 brrt how young do you think i am?
08:08 tadzik young enough :)
08:13 brrt hmm
08:13 brrt i guess that's all relative enough :-)
08:16 masak what does that even mean
08:16 nwc10 good $is_it_nearly_bedtime_yet, #moarvm
08:17 moritz "that's all relative" is an absolute statement, though :-)
08:18 masak moritz: but how about "that's all relative enough"?
08:18 moritz masak: that's relative to your definition of "enough" in that context :-)
08:18 moritz meeting&
08:18 masak amazingly, I'm not confused yet.
08:18 masak moritz: is it *is* a relative statement.
08:19 masak s/is it/so it/
08:24 brrt wow, semantic
08:32 dalek MoarVM: ab7b487 | (Bart Wiegmans)++ | src/jit/ (2 files):
08:32 dalek MoarVM: JIT assignunchecked and assign
08:32 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ab7b4872e5
08:41 brrt i think it was jnthn's idea to use dynasm?
08:41 brrt it was an awesome idea
08:41 brrt very much approve
08:45 dalek MoarVM: ac5904d | (Bart Wiegmans)++ | src/jit/ (2 files):
08:45 dalek MoarVM: JIT getlexstatic_o and getlexperinvtype_o
08:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ac5904d370
08:53 jnthn \o/
08:54 nwc10 t/spec/S32-list/uniq.t only runs 22 tests in the spectst, at least sometimes
08:54 nwc10 but always 35 when standalone (it seems)
08:54 nwc10 anyway, it was the only failure apart from the original 2 sinners
08:55 nwc10 prior to that commit 10 minutes ago
08:55 nwc10 retesting
08:55 nwc10 we seem to be in a good place, where most of the architecture is done, and it's now a case of incrementally filling in the gaps
08:55 * jnthn will try and nail init.t tonight or tomorrow
09:31 itz joined #moarvm
10:07 ggoebel1111115 joined #moarvm
10:30 ggoebel1111115 joined #moarvm
10:58 FROGGS[mobile] joined #moarvm
11:05 * masak .oO( just put a nail init )
11:06 jnthn .oO( if you liked it shoulda put a nail init )
11:07 * masak .oO( all the single nailies )
11:26 brrt joined #moarvm
11:28 brrt lol
11:30 lizmat perhaps we need a "nail($code,$RTnumber)" that would automatically send a note to the RT queue when failed  :-)
11:31 lizmat or at least reports this at the end of the test: RT tickets failed: ...
11:39 brrt i should embarassingly add that i don't know how the test anything protocol actually works
11:59 FROGGS lizmat: this must have been there at some point...
12:00 FROGGS lizmat: because there are replies that say that the issue is solved by an automatic check...
12:42 jnap joined #moarvm
12:54 * [Coke] waits for the "why didn't you just use lua instead of implementing a new VM, if you're using luajit stuff?" question.
13:06 brrt who should ask that question?
13:07 brrt we're using lua for generating the assembler part of the JIT
13:07 brrt and ehm, not even that directly
13:07 brrt as in, nobody here's writing any lua soon :-)
13:07 nwc10 IIRC there is an answer for this
13:07 [Coke] brrt: I expect to hear that question from the haters.
13:07 brrt who hates us?
13:08 * brrt can't imagine
13:08 nwc10 jnthn: what thing does Perl 6 need that Lua doesn't have, hence luajit doesn't provide?
13:08 nwc10 IIRC luajit isn't even good enough for Lua 5.2
13:08 nwc10 that's a bit cheeky for me to say
13:09 brrt luajit supports 5.1 so far, iirc
13:09 brrt but luajit is in fact rather specifically optimized for lua
13:10 brrt much as v8 is for javascript
13:10 nwc10 Good. I got the version numbers correct. I meant to wilfully misrepresent the fact that Lua has advanced a minor version number, but Luajit hasn't (yet)
13:10 nwc10 IIRC there's something significant missing. Not "not optimised for us"
13:10 brrt what about multi's?
13:11 nwc10 it might well have been continuations. But I really can't remember
13:11 brrt hmm, i don't know that either
13:11 brrt but i can imagine there being many things
13:12 brrt and in fact it's not at all that easy to say 'just use $backend for your language'
13:12 nwc10 anyway, accurate answer would be useful for the proto-FAQ
13:12 nwc10 terse, accurate, hard-for-the-clueless-to-naysay
13:12 brrt hmm
13:13 brrt what about 'luajit-2.0 source code is rather dense and we'd like to keep sane'
13:13 nwc10 no, that's not a good reason. that's subjective
13:14 brrt well, many such reasons are subjective
13:15 brrt you could argue 'why not use llvm as a backend' and once again, sanity is the reason
13:15 nwc10 the one I believe I was told was not subjective
13:15 masak Perl 6 has sixmodel, which is the thing that ultimately provides us with the best optimization hints in MoarVM.
13:15 nwc10 I wonder how pyston is coming along
13:15 nwc10 (IIRC that's stab-the-second at a Python JIT on LLVM)
13:15 nwc10 2.7 again.
13:16 nwc10 Guido's employer (again)
13:16 brrt the earlier was unladen swallow
13:16 brrt basically, people tend to believe that llvm is this magic codegen blackbox that you throw a tree in and fast code rolls out
13:16 brrt that is not how this works
13:17 brrt (speaking from 3 months of experience :-))
13:17 nwc10 there's been a lot of talk on perlmonks that I've seen, to that effect
13:18 brrt if you were to do that, you'd basically have to start from scratch, say, from day one, we're going to JIT all code through llvm, and design your 'vm' arround LLVM limitations
13:19 brrt for example, if i recall correctly, the webkit javascriptcore guys did just that
13:19 brrt and one of the compromises that they had to make - again, iirc - is conservative garbage collection
13:19 brrt which means, no generational collection and no compacting
13:20 brrt swap llvm with v8 or luajit, and you encounter much the same (but different) problems
13:21 nwc10 brrt: if you're up for it, this stuff would make an interesting short blog post
13:21 brrt but a subjective one :-)
13:21 brrt but yeah, i agree, it's one of the things i want to talk about a bit :-)
13:22 nwc10 sure, that's not a problem. You aren't saying "impossible" here.
13:22 nwc10 you're saying "these are the downsides"
13:23 brrt true :-)
13:24 * brrt is running errands, bbiab
13:24 brrt left #moarvm
13:28 jnthn nwc10: It's really rather handy to have a VM that knows 6model, serialization stuff, threads, async stuff, etc. Not to mention all the optimization opportunities we get by designing things for Perl 6.
13:28 nwc10 jnthn: oh, I totally agree with that
13:29 nwc10 but I thought there was something structurally troublesome with mapping some part of Perl 6 semantics to what Luajit provides
13:30 jnthn Well, I'd say the MOP and natives issue is pretty structural.
13:30 nwc10 but JVM doesn't have a MOP, so surely it has the same pain?
13:31 nwc10 I'm not meaning to be a troll or a time sinkhole here.
13:31 nwc10 and please tell me to be quiet if I am coming across as one
13:31 FROGGS_ joined #moarvm
13:36 masak has MoarVM overtraken JVM in some benchmarks at this point?
13:45 jnthn nwc10: Yes, but the JVM is also a multi-language host with a userbase using multiple languages on it. And for however good the JVM is, it's never going to be able to be as focused on Perl 6's needs as something trying to be good just at those.
13:46 [Coke] That said, I still want jvm for deployment inroads.
13:47 [Coke] it'll get perl6 in places we can't get with p5.
13:50 jnthn Oh, it's strategic to be on the JVM, absolutely.
13:51 jnthn But that doesn't mean it's going to be an ideal backend for everyone who wants to ues Perl 6.
13:51 * [Coke] is reminded to try to actually make that work!
13:53 Guest1337 joined #moarvm
13:57 JimmyZ joined #moarvm
13:58 JimmyZ Good evening, #moarvm
14:01 jnthn Also note that a lot of the things spesh does, and thus the JIT relies on, boil down to knowing about how Perl 6 types, containers, boolification, representations, etc. work.
14:01 jnthn A lot of what LuaJIT does to be fast relies on knowing a lot about how Lua works.
14:07 jnthn Oh, and then there's the quote from Mike Pall, LuaJIT's creator: "Since I don't believe in multi-language VMs, LuaJIT is pretty Lua-specific on all levels."
14:07 jnthn http://lambda-the-ultimate.org/node/3851#comment-57805
14:08 jnthn Which is probably the best answer to anybody who asks "Why not just use LuaJIT" :)
14:14 dalek MoarVM: 8b1c1a0 | jimmy++ | 3rdparty/linenoise:
14:14 dalek MoarVM: Bump linenoise to latest version.
14:14 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8b1c1a0fbf
14:16 * JimmyZ loves language-specific VM
14:20 Guest1337 joined #moarvm
14:25 Guest1337 Hi, just to barge in on VM discussion, what about CLR? Niecza is going stale, methinks
14:27 JimmyZ CLR doesn't have 6model
14:27 jnthn Nor did the JVM :P
14:28 JimmyZ no spesh too
14:28 jnthn Very true. At least indy makes an effort at letting you teach the JVM how your language works, though.
14:28 jnthn And the CLR doesn't have *that*.
14:29 jnthn There's no big reason you couldn't get a Rakudo CLR to work.
14:29 jnthn I mean, no big technical reason.
14:29 Guest1337 not strategic enough?
14:29 JimmyZ yeah
14:29 jnthn But I certainly don't have time for yet another backend.
14:30 * JimmyZ agrees
14:31 jnthn If somebody showed up and wanted to work on it, well, +1
14:33 JimmyZ MoarVM -- The world's most advanced Open Source Virtul Machine ( A tiltle like www.postgresql.org ) :P
14:33 JimmyZ *title
14:33 jnthn I...think we'll stick with the current one :P
14:35 JimmyZ :)
14:37 brrt joined #moarvm
14:42 ggoebel1111116 joined #moarvm
14:45 jnthn decommute &
15:21 klaas-janstol joined #moarvm
15:26 jnap joined #moarvm
15:33 [Coke] looks like moar barfed today during the spectests, but moar-jit did not.
15:34 tadzik that settles it, commence merging
15:35 TimToady um, okay...done :)
16:26 brrt joined #moarvm
17:55 brrt [Coke]: master failed? after which commit?
18:04 brrt you should know that development on the JIT continues on master now :-)
18:06 [Coke] brrt: yes.
18:07 [Coke] I'm testing moar & moar-jit daily now, from master.
18:07 [Coke] according to https://github.com/coke/perl6-roast-data/blob/master/perl6_pass_rates.csv rakudo.jit is fine, but rakudo.moar is broken on 4328c75; last worked on 0c42c11
18:07 brrt ah, i see
18:07 brrt hmmm
18:08 brrt then all is well
18:09 [Coke] .. except that moar is dying, yes :)
18:09 brrt hmm
18:09 brrt i have no idea why that should be so
18:12 [Coke] so, one of these commits: 4e28c75 969e6c2 b87d6a5
18:15 [Coke] I miss the build bots that would do every revision of parrot, but start with the most recent version and backfill.
18:16 [Coke] ... though having spec be different makes that harder. I wonder if we should have a spec revision.
18:17 brrt spectest takes quite a while doesn't it
18:17 FROGGS_ o/
18:18 [Coke] I was just able to do a moar-jit spectest in 156 wallclock secs
18:18 [Coke] ... but that's on my new worktop, not the roast box.
18:19 brrt hmm
18:19 brrt i'm not expecting this to be fast, as i said, ASAN :-)
18:42 synopsebot joined #moarvm
19:03 brrt left #moarvm
19:42 Ven joined #moarvm
20:05 klaas-janstol joined #moarvm
20:15 dalek MoarVM: 06851b2 | (Timo Paulssen)++ | src/jit/graph.c:
20:15 dalek MoarVM: nfarunproto and nfafromstatelist for the jit.
20:15 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/06851b23b5
20:18 brrt joined #moarvm
20:18 brrt \o
20:21 timotimo hey brrt
20:21 brrt hey timo
20:23 timotimo about 70 instances of run and nfa_run now get jitted
20:23 timotimo (throughout rakduo's compilation process)
20:23 brrt \o/
20:24 brrt that makes a bit of difference
20:24 diakopter brrt: did you get the jumplist op
20:24 brrt ehm, jumplist was done
20:24 diakopter cool
20:24 brrt yes, or are you refering to bugs?
20:25 diakopter no, it's just I invented the op while making the regex compiler, and was curious how its JITting ended up looking
20:25 donaldh joined #moarvm
20:25 timotimo brrt: how hard is paramsnamesused actually?
20:25 brrt paramsnamesused is not hard
20:26 brrt in fact, it's easy
20:26 * timotimo prepared a before_paramnamesused.txt :)
20:27 diakopter brrt: where would I find the jit impl of jumplist? :)
20:27 brrt the thing is, it doesn't solve anything yet, because after that, there will be a whole slew of param_(r|o)(p|n)_(i|n|s|o)
20:27 timotimo ah. of course
20:28 timotimo it'd be kind of helpful to have the spesh log automatically "linked to" from the jit log
20:28 timotimo so you could see what opcodes are up next
20:28 timotimo but i suppose i can just grep the spesh log for "paramnamesused"
20:29 jnthn timotimo: Last time I looked at the logs, the nfa ops often got inlined into other things, so the 70 are probably the things that inlined it :)
20:29 brrt diakopter: let me find that for you
20:29 jnthn diakopter: (jumplist) likely in the .dasc
20:29 timotimo oh, actually
20:30 timotimo brrt: paramnamesused *follows* param_* ops
20:30 brrt o really?
20:30 timotimo yeah
20:31 timotimo so it *would* be worth it to implement that :)
20:31 brrt https://github.com/MoarVM/MoarVM/blob/master/src/jit/emit_x64.dasc#L1496
20:31 brrt diakopter ^
20:32 diakopter thanks
20:32 brrt basically, align a bunch of labels by 8 bytes, and compute the offset to jump to by first getting the relative address of the first label
20:34 brrt very well, i'll implement paramnamesused :-)
20:35 timotimo \o/
20:45 * brrt and gf are busy learning cyrillic alphabet
20:48 timotimo brrt: ordat and ordfirst have a "die if the string is null" part to them; if they didn't i'd've implemented them long ago ... is there maybe a super simple way to emit that check without writing any assembly?
20:48 brrt ehm
20:48 brrt no not yet
20:48 brrt we can't really represent conditionals on graph level
20:48 jnthn timotimo: Or just move the check out of the interp and into the thing the interp calls
20:48 jnthn Since the interp is probably the only caller anyway.
20:48 timotimo oh, hmm.
20:49 timotimo let me check that
20:49 brrt yeah, i was going to say, that depends on who else calls it :-)
20:50 dalek MoarVM: a555298 | (Bart Wiegmans)++ | src/jit/ (2 files):
20:50 dalek MoarVM: Add paramnamesused to JIT
20:50 dalek MoarVM:
20:50 dalek MoarVM: By popular demand.
20:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a555298c96
20:50 timotimo src/io/syncstream.c uses it, too
20:51 timotimo but that's the only place
20:51 timotimo the rest calls the _nocheck variant
20:51 timotimo but that nocheck probably refers to a bounds check rather than a "is the string null" check
20:51 klaas-janstol joined #moarvm
20:51 jnthn Aye
20:51 jnthn An extra null check won't be costly compared to IO :)
20:51 timotimo null check + "is the number of graphemes 0?"
20:52 timotimo i'll get a diff for the bails first
20:53 brrt btw, we're inching ever closer to runtime parity with and without jit
20:53 brrt (on my machine, that is)
20:53 brrt (for core setting compilation, that is)
20:53 jnthn Ooh
20:54 jnthn JIT moar things and maybe we come out ahead ;)
20:54 timotimo that would be fantastic
20:55 timotimo okay, for nqp the result looks like this:
20:55 timotimo unless_s0 got 50 more bails aand went up to 107
20:56 timotimo gt_s got 42 more bails
20:56 timotimo getobjsc got 25 more bails
20:56 timotimo create appeared at 2 bails
20:56 timotimo freshcoderef went from 4 to 17, which is +13
20:56 timotimo savecapture appeared at 23
20:57 timotimo m: say 903 - 23 - 13 - 2 - 25 - 42 - 50
20:57 camelia rakudo-moar daf80f: OUTPUT«748␤»
20:57 timotimo so we now compile ~750 frames more during the nqp compilation
20:59 timotimo now for rakudo:
20:59 timotimo unless_s0 got 70 more bails
20:59 timotimo getobjsc got 35 more bails
21:00 timotimo mod_n appeared at 66 bails
21:01 timotimo getlexouter got a single bail more
21:01 timotimo gt_s moved from 18 to 38, which is +20
21:01 timotimo savecapture appeared at 27
21:01 timotimo hintfor got +3 and is at 23 now
21:02 jnthn timotimo: um, where are these numbers from?
21:02 timotimo guardcontconc +1, guardconttype +4, mul_I +1, create +4, newtype + 3 and hllizefor appears at 4
21:03 timotimo i've changed the jit log opening to "a" and ran a complete nqp and rakudo compilation each
21:03 jnthn Oh
21:03 timotimo and then vimdiff'd the numbers
21:03 jnthn OK, was gonna say, hintfor should appear like once per process :P
21:03 brrt seriously mod_n?
21:03 jnthn Or something approximating that
21:03 brrt mod f-ing n?
21:03 timotimo m: say 836 - 70 - 35 - 66 - 1 - 20 - 27 - 3 - 1 - 4 - 1 - 4 - 3 - 4
21:03 camelia rakudo-moar daf80f: OUTPUT«597␤»
21:04 brrt the thing isn't even all that well defineed
21:04 timotimo so we still got a win of almost 600 frames from that
21:05 timotimo well, you can ignore mod_n for now; param_rp_o at 402, param_sn at 240, param_sp at 221 and argconst_s at 175 are more pressing, and even then, unless_s0 is 157 and getobjsc is at 80 :)
21:05 brrt argconst_s is a mistake
21:05 brrt a spesh bug
21:05 brrt it should not be there
21:05 timotimo more or less
21:05 jnthn Ummm....deopt?
21:05 timotimo we didn't do the "put argument names into the callsite" change completely yet
21:06 brrt no, what i mean is, it appears without a prepargs to prefix it
21:06 jnthn Oh.
21:06 timotimo ... oh?
21:06 jnthn Yeah, OK.
21:06 brrt yes
21:06 jnthn That can be fixed, then.
21:07 brrt probably from inlining :-)
21:07 jnthn Right
21:07 * brrt afk
21:08 jnthn timotimo: Does the nqp optimizer deal with nqp::mod_n => nqp::mod_i on integer args, like it does with add/sub/mul?
21:08 dalek MoarVM: 60ffbb2 | (Bart Wiegmans)++ | src/jit/ (2 files):
21:08 dalek MoarVM: JIT unless_s0 and if_s0
21:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/60ffbb295c
21:08 timotimo let me have a look
21:08 jnthn timotimo: 'cus all the % usages I spot in NQP happen with a native int variable and an int literal
21:09 brrt left #moarvm
21:09 timotimo ah
21:09 timotimo we forgot to add it to the hash that't do it
21:10 timotimo i'll run that through some tests
21:12 timotimo that almost exactly halves the number of mod_n bails
21:13 flussence joined #moarvm
21:13 FROGGS joined #moarvm
21:15 timotimo 0 bails in the rakudo compilation process after optimizing mod_n into mod_i
21:16 timotimo and i suppose i can also add abs_n for good measure?
21:16 jnthn yes :)
21:16 timotimo does the opt know how to handle one-param ops?
21:16 jnthn I dunno...you wrote the opt! :P
21:16 timotimo it does not
21:16 timotimo should i add that? :)
21:16 jnthn If you wish; neg_n can also be handled then
21:17 timotimo good.
21:17 timotimo fortunately we don't have -1 as neg_n(1) in the code any more :)
21:17 jnthn hah
21:17 jnthn :)
21:18 jnthn bbi10
21:32 timotimo oh, huh?
21:33 timotimo still 84 mod_n in nqp?
21:42 jnthn Well, stage0...
21:42 timotimo oh
21:42 timotimo that's a good point
21:42 timotimo i hadn't thought of that
21:42 timotimo has been a really long time since we updated the stage0
21:43 jnthn aye
21:43 timotimo if it were cheaper, i'd suggest just doing it for the hell of it, as the code gen has improved a bunch since the last time
21:43 timotimo but more of the improvements were in rakudo anyway, i believe
21:45 timotimo (cheaper as in: cloning an nqp already takes much more time than it should)
21:46 jnthn True, though we build more often than we clone :)
21:46 timotimo just wait for the influx of newbies that want to contribute once we ... dunno what exactly :P
21:48 timotimo abs_n and neg_n still have a few occurences in rakudos build, but very few
21:48 timotimo 1 + 8
21:49 jnthn 9
21:49 timotimo 1 abs_n + 8 neg_n
22:07 dalek MoarVM: 32f0b6d | (Timo Paulssen)++ | src/ (3 files):
22:07 dalek MoarVM: get_grapheme_at is now more jit friendly, and ordat is implemented.
22:07 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/32f0b6dad1
22:08 timotimo it seems like my existskey implementation stadey on my laptop
22:15 timotimo i must have looked wrong.
23:02 dalek MoarVM: f5f8d14 | jnthn++ | src/ (3 files):
23:02 dalek MoarVM: Refactor some bigint ops for simple JITting.
23:02 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f5f8d14ebf
23:02 dalek MoarVM: cc8e3f8 | jnthn++ | src/jit/graph.c:
23:02 dalek MoarVM: JIT a few bigint ops.
23:02 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cc8e3f8cc1
23:16 dalek MoarVM: 22c22e2 | jnthn++ | src/jit/graph.c:
23:16 dalek MoarVM: JIT coerce_Is and base_I.
23:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/22c22e246a
23:53 colomon joined #moarvm

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