00:02 lue joined 01:24 FROGGS_ joined 07:32 brrt joined 07:40 itz_ joined
dalek arVM: 91e6ce5 | (Bart Wiegmans)++ | src/jit/ (2 files):
JIT scwbenable / scwbdisable
 07:50
FROGGS ohh, that seems rather important to have :o) 07:52
brrt there were quite a few bails of these 07:53
and they're primitives properly 07:54
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 :-)
FROGGS *g* 08:00
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)
brrt wonders how old jnthn really is 08:07
never to old to learn anything
how young do you think i am?
tadzik young enough :) 08:08
brrt hmm 08:13
i guess that's all relative enough :-)
masak what does that even mean 08:16
nwc10 good $is_it_nearly_bedtime_yet, #moarvm
moritz "that's all relative" is an absolute statement, though :-) 08:17
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 :-)
meeting&
masak amazingly, I'm not confused yet.
moritz: is it *is* a relative statement.
s/is it/so it/ 08:19
brrt wow, semantic 08:24
dalek arVM: ab7b487 | (Bart Wiegmans)++ | src/jit/ (2 files):
JIT assignunchecked and assign
 08:32
brrt i think it was jnthn's idea to use dynasm? 08:41
it was an awesome idea
very much approve
dalek arVM: ac5904d | (Bart Wiegmans)++ | src/jit/ (2 files):
JIT getlexstatic_o and getlexperinvtype_o
 08:45
jnthn \o/ 08:53
nwc10 t/spec/S32-list/uniq.t only runs 22 tests in the spectst, at least sometimes 08:54
but always 35 when standalone (it seems)
anyway, it was the only failure apart from the original 2 sinners
prior to that commit 10 minutes ago 08:55
retesting
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
jnthn will try and nail init.t tonight or tomorrow
09:31 itz joined 10:07 ggoebel1111115 joined 10:30 ggoebel1111115 joined 10:58 FROGGS[mobile] joined
masak .oO( just put a nail init ) 11:05
jnthn
.oO( if you liked it shoulda put a nail init )
 11:06
masak .oO( all the single nailies ) 11:07
11:26 brrt joined
brrt lol 11:28
lizmat perhaps we need a "nail($code,$RTnumber)" that would automatically send a note to the RT queue when failed :-) 11:30
or at least reports this at the end of the test: RT tickets failed: ... 11:31
brrt i should embarassingly add that i don't know how the test anything protocol actually works 11:39
FROGGS lizmat: this must have been there at some point... 11:59
lizmat: because there are replies that say that the issue is solved by an automatic check... 12:00
12:42 jnap joined
[Coke] waits for the "why didn't you just use lua instead of implementing a new VM, if you're using luajit stuff?" question. 12:54
brrt who should ask that question? 13:06
we're using lua for generating the assembler part of the JIT 13:07
and ehm, not even that directly
as in, nobody here's writing any lua soon :-)
nwc10 IIRC there is an answer for this
[Coke] brrt: I expect to hear that question from the haters.
brrt who hates us?
brrt can't imagine 13:08
nwc10 jnthn: what thing does Perl 6 need that Lua doesn't have, hence luajit doesn't provide?
IIRC luajit isn't even good enough for Lua 5.2
that's a bit cheeky for me to say
brrt luajit supports 5.1 so far, iirc 13:09
but luajit is in fact rather specifically optimized for lua
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)
IIRC there's something significant missing. Not "not optimised for us"
brrt what about multi's?
nwc10 it might well have been continuations. But I really can't remember 13:11
brrt hmm, i don't know that either
but i can imagine there being many things
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
terse, accurate, hard-for-the-clueless-to-naysay
brrt hmm
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
brrt well, many such reasons are subjective 13:14
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
masak Perl 6 has sixmodel, which is the thing that ultimately provides us with the best optimization hints in MoarVM.
nwc10 I wonder how pyston is coming along
(IIRC that's stab-the-second at a Python JIT on LLVM)
2.7 again.
Guido's employer (again) 13:16
brrt the earlier was unladen swallow
basically, people tend to believe that llvm is this magic codegen blackbox that you throw a tree in and fast code rolls out
that is not how this works
(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
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:18
for example, if i recall correctly, the webkit javascriptcore guys did just that 13:19
and one of the compromises that they had to make - again, iirc - is conservative garbage collection
which means, no generational collection and no compacting
swap llvm with v8 or luajit, and you encounter much the same (but different) problems 13:20
nwc10 brrt: if you're up for it, this stuff would make an interesting short blog post 13:21
brrt but a subjective one :-)
but yeah, i agree, it's one of the things i want to talk about a bit :-)
nwc10 sure, that's not a problem. You aren't saying "impossible" here. 13:22
you're saying "these are the downsides"
brrt true :-) 13:23
brrt is running errands, bbiab 13:24
13:24 brrt left
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
but I thought there was something structurally troublesome with mapping some part of Perl 6 semantics to what Luajit provides 13:29
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?
I'm not meaning to be a troll or a time sinkhole here. 13:31
and please tell me to be quiet if I am coming across as one
13:31 FROGGS_ joined
masak has MoarVM overtraken JVM in some benchmarks at this point? 13:36
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:45
[Coke] That said, I still want jvm for deployment inroads. 13:46
it'll get perl6 in places we can't get with p5. 13:47
jnthn Oh, it's strategic to be on the JVM, absolutely. 13:50
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 13:57 JimmyZ joined
JimmyZ Good evening, #moarvm 13:58
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
A lot of what LuaJIT does to be fast relies on knowing a lot about how Lua works.
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
lambda-the-ultimate.org/node/3851#comment-57805
Which is probably the best answer to anybody who asks "Why not just use LuaJIT" :) 14:08
dalek arVM: 8b1c1a0 | jimmy++ | 3rdparty/linenoise:
Bump linenoise to latest version.
 14:14
JimmyZ loves language-specific VM 14:16
14:20 Guest1337 joined
Guest1337 Hi, just to barge in on VM discussion, what about CLR? Niecza is going stale, methinks 14:25
JimmyZ CLR doesn't have 6model 14:27
jnthn Nor did the JVM :P
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.
And the CLR doesn't have *that*.
There's no big reason you couldn't get a Rakudo CLR to work. 14:29
I mean, no big technical reason.
Guest1337 not strategic enough?
JimmyZ yeah
jnthn But I certainly don't have time for yet another backend.
JimmyZ agrees 14:30
jnthn If somebody showed up and wanted to work on it, well, +1 14:31
JimmyZ MoarVM -- The world's most advanced Open Source Virtul Machine ( A tiltle like www.postgresql.org ) :P 14:33
*title
jnthn I...think we'll stick with the current one :P
JimmyZ :) 14:35
14:37 brrt joined 14:42 ggoebel1111116 joined
jnthn decommute & 14:45
15:21 klaas-janstol joined 15:26 jnap joined
[Coke] looks like moar barfed today during the spectests, but moar-jit did not. 15:33
tadzik that settles it, commence merging 15:34
TimToady um, okay...done :) 15:35
16:26 brrt joined
brrt [Coke]: master failed? after which commit? 17:55
you should know that development on the JIT continues on master now :-) 18:04
[Coke] brrt: yes. 18:06
I'm testing moar & moar-jit daily now, from master. 18:07
according to github.com/coke/perl6-roast-data/b..._rates.csv rakudo.jit is fine, but rakudo.moar is broken on 4328c75; last worked on 0c42c11
brrt ah, i see
hmmm
then all is well 18:08
[Coke] .. except that moar is dying, yes :) 18:09
brrt hmm
i have no idea why that should be so
[Coke] so, one of these commits: 4e28c75 969e6c2 b87d6a5 18:12
I miss the build bots that would do every revision of parrot, but start with the most recent version and backfill. 18:15
... though having spec be different makes that harder. I wonder if we should have a spec revision. 18:16
brrt spectest takes quite a while doesn't it 18:17
FROGGS_ o/
[Coke] I was just able to do a moar-jit spectest in 156 wallclock secs 18:18
... but that's on my new worktop, not the roast box.
brrt hmm 18:19
i'm not expecting this to be fast, as i said, ASAN :-)
18:42 synopsebot joined 19:03 brrt left 19:42 Ven joined 20:05 klaas-janstol joined
dalek arVM: 06851b2 | (Timo Paulssen)++ | src/jit/graph.c:
nfarunproto and nfafromstatelist for the jit.
 20:15
20:18 brrt joined
brrt \o 20:18
timotimo hey brrt 20:21
brrt hey timo
timotimo about 70 instances of run and nfa_run now get jitted 20:23
(throughout rakduo's compilation process)
brrt \o/
that makes a bit of difference 20:24
diakopter brrt: did you get the jumplist op
brrt ehm, jumplist was done
diakopter cool
brrt yes, or are you refering to bugs?
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
20:25 donaldh joined
timotimo brrt: how hard is paramsnamesused actually? 20:25
brrt paramsnamesused is not hard
in fact, it's easy 20:26
timotimo prepared a before_paramnamesused.txt :)
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)
timotimo ah. of course
it'd be kind of helpful to have the spesh log automatically "linked to" from the jit log 20:28
so you could see what opcodes are up next
but i suppose i can just grep the spesh log for "paramnamesused"
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
jnthn diakopter: (jumplist) likely in the .dasc
timotimo oh, actually
brrt: paramnamesused *follows* param_* ops 20:30
brrt o really?
timotimo yeah
so it *would* be worth it to implement that :) 20:31
brrt github.com/MoarVM/MoarVM/blob/mast...dasc#L1496
diakopter ^
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
very well, i'll implement paramnamesused :-) 20:34
timotimo \o/ 20:35
brrt and gf are busy learning cyrillic alphabet 20:45
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
no not yet
we can't really represent conditionals on graph level
jnthn timotimo: Or just move the check out of the interp and into the thing the interp calls
Since the interp is probably the only caller anyway.
timotimo oh, hmm.
let me check that 20:49
brrt yeah, i was going to say, that depends on who else calls it :-)
dalek arVM: a555298 | (Bart Wiegmans)++ | src/jit/ (2 files):
Add paramnamesused to JIT

By popular demand.		 20:50
timotimo src/io/syncstream.c uses it, too
but that's the only place 20:51
the rest calls the _nocheck variant
but that nocheck probably refers to a bounds check rather than a "is the string null" check
20:51 klaas-janstol joined
jnthn Aye 20:51
An extra null check won't be costly compared to IO :)
timotimo null check + "is the number of graphemes 0?"
i'll get a diff for the bails first 20:52
brrt btw, we're inching ever closer to runtime parity with and without jit 20:53
(on my machine, that is)
(for core setting compilation, that is)
jnthn Ooh
JIT moar things and maybe we come out ahead ;) 20:54
timotimo that would be fantastic
okay, for nqp the result looks like this: 20:55
unless_s0 got 50 more bails aand went up to 107
gt_s got 42 more bails 20:56
getobjsc got 25 more bails
create appeared at 2 bails
freshcoderef went from 4 to 17, which is +13
savecapture appeared at 23
m: say 903 - 23 - 13 - 2 - 25 - 42 - 50 20:57
camelia rakudo-moar daf80f: OUTPUTĀ«748ā¤Ā»
timotimo so we now compile ~750 frames more during the nqp compilation
now for rakudo: 20:59
unless_s0 got 70 more bails
getobjsc got 35 more bails
mod_n appeared at 66 bails 21:00
getlexouter got a single bail more 21:01
gt_s moved from 18 to 38, which is +20
savecapture appeared at 27
hintfor got +3 and is at 23 now
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
i've changed the jit log opening to "a" and ran a complete nqp and rakudo compilation each 21:03
jnthn Oh
timotimo and then vimdiff'd the numbers
jnthn OK, was gonna say, hintfor should appear like once per process :P
brrt seriously mod_n?
jnthn Or something approximating that
brrt mod f-ing n?
timotimo m: say 836 - 70 - 35 - 66 - 1 - 20 - 27 - 3 - 1 - 4 - 1 - 4 - 3 - 4
camelia rakudo-moar daf80f: OUTPUTĀ«597ā¤Ā»
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
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
a spesh bug
it should not be there
timotimo more or less
jnthn Ummm....deopt?
timotimo we didn't do the "put argument names into the callsite" change completely yet
brrt no, what i mean is, it appears without a prepargs to prefix it 21:06
jnthn Oh.
timotimo ... oh?
jnthn Yeah, OK.
brrt yes
jnthn That can be fixed, then.
brrt probably from inlining :-) 21:07
jnthn Right
brrt afk
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 arVM: 60ffbb2 | (Bart Wiegmans)++ | src/jit/ (2 files):
JIT unless_s0 and if_s0
timotimo let me have a look
jnthn timotimo: 'cus all the % usages I spot in NQP happen with a native int variable and an int literal
21:09 brrt left
timotimo ah 21:09
we forgot to add it to the hash that't do it
i'll run that through some tests 21:10
that almost exactly halves the number of mod_n bails 21:12
21:13 flussence joined, FROGGS joined
timotimo 0 bails in the rakudo compilation process after optimizing mod_n into mod_i 21:15
and i suppose i can also add abs_n for good measure? 21:16
jnthn yes :)
timotimo does the opt know how to handle one-param ops?
jnthn I dunno...you wrote the opt! :P
timotimo it does not
should i add that? :)
jnthn If you wish; neg_n can also be handled then
timotimo good. 21:17
fortunately we don't have -1 as neg_n(1) in the code any more :)
jnthn hah
:)
bbi10 21:18
timotimo oh, huh? 21:32
still 84 mod_n in nqp? 21:33
jnthn Well, stage0... 21:42
timotimo oh
that's a good point
i hadn't thought of that
has been a really long time since we updated the stage0
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
but more of the improvements were in rakudo anyway, i believe
(cheaper as in: cloning an nqp already takes much more time than it should) 21:45
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
abs_n and neg_n still have a few occurences in rakudos build, but very few 21:48
1 + 8
jnthn 9 21:49
timotimo 1 abs_n + 8 neg_n
dalek arVM: 32f0b6d | (Timo Paulssen)++ | src/ (3 files):
get_grapheme_at is now more jit friendly, and ordat is implemented.
 22:07
timotimo it seems like my existskey implementation stadey on my laptop 22:08
i must have looked wrong. 22:15
dalek arVM: f5f8d14 | jnthn++ | src/ (3 files):
Refactor some bigint ops for simple JITting.
 23:02
arVM: cc8e3f8 | jnthn++ | src/jit/graph.c:
JIT a few bigint ops.
arVM: 22c22e2 | jnthn++ | src/jit/graph.c:
JIT coerce_Is and base_I.
 23:16
23:53 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!