01:38 vendethiel joined 02:51 vendethiel joined 03:00 JimmyZ_ joined 04:15 vendethiel joined 05:30 vendethiel joined 07:02 zakharyas joined 07:20 Ven joined 08:21 brrt joined
brrt \o 08:21
hmm
anyone know how to initialize an array of variable-sized int arrays 08:22
hmm, you can't 08:23
ok, that's clear enough
why can't i have nice things 08:34
because C 08:38
masak I think you need to take a step back and ask why it is you want that data structure. 08:40
and then do what is possible in C. 08:41
anyway, in True Perl 6 the answer is something like `my @array[20; *];`
08:48 Ven joined
brrt i can answer that :-) 08:49
in fact, that was supposed to be the topic of a blog post ;-)
basically, my goal is to convert a spesh-graph basic block to a low-level expression tree (a machine-level IR), on which i can then run a pattern-matching code generation 08:51
jnthn moarning o/
brrt moarning
now, the spesh graph is properly considered an SSA-annoteted form of three-address-code 08:52
maybe sometimes more than three addresses, sometimes less, but that is beside the point
so my first order of business would seem to be conversion of the spesh format to an expression tree (or actually expression set, but again, beside the point) 08:53
agreed?
jnthn brrt: Sounds like what the pattern matching approach needs, yes. 08:54
jnthn notes that usage counts could help a huge amount
brrt hmm
jnthn In that, if something has a single use, it is a candidate for moving into the tree under its user. 08:55
brrt agreed; however, my tree-building algorithm is more aggressive than that
as in, it always moves it under the tree, it's just kept available until overwritten 08:56
so in a sense, that generates a DAG
because multiple parents can 'acquire' a child
now, how to do this without it taking up the full 8 or so weeks i have left? :-) 08:57
well, for that, i want to use expression templates 08:58
much like dynasm, in fact
these templates would be formed by a piece of IR tree and a set of fill-in instructions 09:01
the fill-in instructions can conveniently be a string, because the set of opertions is quite small 09:02
nwc10 I admit that I've not studied luaJIT closely, but I've read a couple of the explanations of what it does for certain things
am I right in thinking that it doesn't take any advantage of runtime type information?
ie it is a "Just In Time" compilation of the static Lua code. 09:03
brrt ah, i can answer that, i think
nwc10 no guard clauses or similar "oh bother" bailout
brrt as far as i know, lua doesn't really support user-defined types
09:04 Ven joined
brrt it supports user-defined classes and objects, but those are just extensions to the universal 'table' structure 09:04
and, luajit is a trace compiler
what that means is that for luajit to specialize on type, it just constant-folds the hash-table lookup it would otherwise do 09:05
specialisation on method calls is 'for free' given the tracing, but that does mean you need to do trace guards 09:06
i.e. if you leave the trace, you'll need to deopt
this is all only possible because lua is a *much* simpler language than perl6 09:08
jnthn Yeah, LuaJIT is pretty specialized to Lua, which is why saying "just lift X idea from Lua to MoarVM" always frustrates me - because it's never gonna be "just". 09:10
brrt anyway, it looks like i'll need / want a preprocessor convert the expression-ir-templates to something that can be used at runtime, to fill those templates 09:11
nwc10 ah OK. thanks. So, my naive assumption is wrong - there are guards. 09:12
brrt alternatively, i could handcode it all, but that's timeconsuming and error-prone
yes :-)
oh, there's another fun thing about lua; lua only has floats 09:13
heh. luajit in fact uses it's high-level IR directly for compilation, doesn't convert to a low-level IR set 09:14
in effect, luajit uses peephole-optimized code generation 09:15
jnthn nwc10: Trace JIT is all about guards, pretty much...
nwc10: You eliminate all control flow for guards.
To a first approximation :)
brrt nods 09:16
nwc10 OK, the bit my befuddled brain missed was that there was never mention of deoptimisation in any of the exmaples of stuff (or guards)
brrt and adds that loops or equally-taken-branches will likely end up in a trace
nwc10 and also, that there seemed to be no concept of an intermediate state of specialised bytecode. Or logging of control flow 09:17
obviously logging has to happen, to make tracing work.
jnthn nwc10: It's a language thing; they don't call it "deopt", more like "trace exits"
brrt re: logging, i think it's embedded in the interpreter?
jnthn Yeah, though I suspect our logging is going to change with time
I'd like it to be more PIC-like
And cheaper 09:18
nwc10 PIC (in this context)?
jnthn re-read the PIC paper on the train on Sat
brrt my same question
jnthn nwc10: Polymorphic Inline Cache
brrt aha
nwc10 aha. them
brrt i read the pypy guys had a new trick on their sleeve, dispatch chains
but i'm not totally sure what that's about
nwc10 I'm a bit disappointed that there hasn't been a new entry on blog.pyston.org/ since Feb 24 09:19
and even lists.pyston.org/pipermail/pyston-dev/ hasn't had a message (archived) since March 2015
it's clear that they're busy doing stuff, given github.com/dropbox/pyston 09:20
but I'd love something that summarises their progress. Because I'm curious.
brrt ehm, what's new about pyston?
jnthn brrt: I glanced over that paper recently.
brrt yes, my reading was also limited to a glance :-)
nwc10 particularly given that they thought that starting a new JIT was more likely to be a win for them than using/contributing to pypy
jnthn brrt: But it was on a day when my allergy stuff was horrid, so it was all a bit of a blur... 09:21
nwc10 brrt: in terms of technology - I have no idea, and I suspect "nothing" (and that might be a design choice - just do existing things well)
I was far more curious about the "do another JIT" choice
jnthn will re-read the paper at some point
brrt we're doing another JIT, just inside the old one :-P
hmm... 09:24
one of the greater disadvantages of pypy, imho, is that they've distanced themselves quite far from the mainstream, technically and intellectually
nobody else is talking about a meta-tracing compiler
ah, on llvm 09:25
hmm... well, that can work.
nwc10 brrt: I wasn't aware of that. I was aware that I can't build the thing on my laptop, as I only have 4Gb 09:26
and even on a desktop with >6Gb RAM it takes forever to build (ie about 40 minutes) 09:27
which makes their development feedback cycle dog slow.
which will hinder them massively
and prevent them from getting many new contributors
brrt well, it's just my opinion, for one thing :-) 09:28
but yes 09:29
pypy takes literally forever to build
forever to download (on a slow line)
figuratively forever, perhaps
and... what they write about it is barely comprehensible to an outsider (me) 09:30
09:42 JimmyZ_ joined
brrt bbiab 09:53
10:31 brrt joined
brrt back 10:32
11:20 vendethiel joined 11:23 hoelzro_trying_w joined 11:24 hoelzro joined 11:47 vendethiel joined
brrt does MSVC support int array[runtime_variable] yet? 12:30
jnthn I don't *think* so... 12:31
brrt :-( 12:33
dalek arVM/even-moar-jit: 9885d9e | brrt++ | src/jit/expr.c:
First draft of expression tree building algorithm

This is not yet a useful implementation since it lacks any templates to fill, a template filling algorithm, definitions of the structures involved, and I'm fairly sure it doesn't compile. But its useful to have it out in the open anyway.
brrt well, no matter
it supports alloca, doesn't it?
this wasn't meant to compile anyway 12:35
jnthn _alloca is in the MSDN: msdn.microsoft.com/cs-cz/library/wb1s57t5.aspx 12:36
uhh...
msdn.microsoft.com/en-us/library/wb1s57t5.aspx
brrt why the underscore 12:38
does microsoft not like us
ok, now for the next bits 12:39
filling templates
my hypothesis is that for constructing templates, i can just look at the asm code we meticulously wrote for dynasm can be a guide 12:40
12:40 vendethiel joined
brrt hmmm 12:50
i'd better get the whole spesh ins for acquiring the template
13:04 Ven joined 13:09 vendethiel joined 13:17 zakharyas joined
dalek Heuristic branch merge: pushed 30 commits to MoarVM/even-moar-jit by bdw 13:22
timotimo is the "turn jitting to C invocations" thing going to be a priority soon? 13:24
brrt ehm, sorry, i don't get the context yet :-) 13:25
timotimo er 13:26
yeah, it's missing half the text in the quotes
"turn jitting to C invocations into a table lookup"
brrt ehm, yes
timotimo or maybe "build a jit interpreter" :P
brrt well
let me explain my plan for now 13:27
basically, as i said this morning, the first thing i have to do is lower the spesh graph ir to a low-level IR
timotimo mhm 13:28
brrt i want to use templates to do that
timotimo mhm
brrt as in, something, have a template for the tree, and fill it in
timotimo you mean "match something"?
brrt no, matching is much later
timotimo what's the something for, then? :) 13:29
brrt for each MVM instruction, find a template for the low-level IR, and fill it in with IR nodes generated for the instruction operands
timotimo ah, hm
brrt e.g. translate an immediate operand into an immediate node and fill this in
in other words 13:30
timotimo ah, so even for operations that have a constant argument in the MVM bytecode, we'll emit something akin to a "load constant" operation?
brrt inc_i would becomde { mem-ref register (i}, immediate (1), add relative(0), relative(1) }
yes 13:31
actually
that will exist in the IR
not in the written bytecode
the 3rd element (index 2) willl then be the root of the template
hmm 13:32
i didn't do that in my mockup implementation yet
anyway, to make a long story short
timotimo i don't know what "root of the template" is necessary for
brrt basically, this creates a tree (in s-expr notation) (add (reg-val 1) (imm 1)); the add node is the root 13:33
timotimo oh, ok
brrt i need the root, because the root now stands for the value of that computation
timotimo and the "relative" is relative to the { } 13:34
brrt precisely
anyway, that'd be the same thing as would be written for the c calls
the c calls would have two nodes, the call pointer and the argument list, ensuring that (in recursive evaluation) the arguments are stored in the right place 13:36
timotimo "mem-ref register", "immediate 1" and friends are equivalent to the things we already put into the structs for generating c calls 13:37
right
brrt yes, but generalised, because they'll need a size
i.e. they should generalise to getting stuff from like, euh 13:38
timotimo mhm
brrt getting the category mask from the MVMException ;-) 13:39
timotimo that's the first time we've needed sized reads :3
and we've reverted that again
brrt well, we need it for a lot of things, its just that most of those have been implemented by hand, in asm, in emit_x64 13:40
timotimo OK
so emit_x64 is going to shrink a bit, too?
brrt that is the goal, yes
timotimo well, i mean, a lot of the hand-coded things so far
we'll have the things that turn our IR into assembly, that'll be in a .dasc file, too 13:41
brrt yes, that's the final codegenerator 13:42
timotimo will it be a separate .dasc file?
brrt and a lot of what's in emit_x64.dasc will ocntinue to exist
timotimo mhm
brrt i am planning to split them, yes, and use dynasm-level .include to include them
timotimo sounds good
seems like you can stop explaining and continue working ;)
brrt :-) 13:43
jnthn brrt++ # plan sounds good, having just caught up reading :)
brrt :-) thanks
that's a relief, really
timotimo should i try building a code analysis thing that can turn the current jit/graph.c into a table? :P 13:44
brrt you... could do that, yes, i've thought about it
timotimo sounds a bit painful
but maybe fun
and since it's a one-off, it'd be acceptable to make it do 90% of the work and do the rest by hand 13:45
brrt the thing is, i haven't settled on the format of the table just yet
timotimo mhm
brrt :-P
timotimo in that case, the generator can be changed
or we generate a more detailed table that can be turned into the final table
brrt yes, that's true
timotimo i heard xslt can be used to transform <table>s 13:46
brrt anyway, if you wanted to try and analyze the graph.c thingy, that'd help, definitely
timotimo having had something like that could have been a good thing earlier to figure out things like "passed n arguments, but claimed the argument list was m elements big"
brrt nods 13:47
anyway, the process is automatable as far as i care. so we should automate it :-)
but i'll be back in a few hours
i have a study colloquium to attend :-)
see you!
timotimo K cya :)
13:50 JimmyZ_ joined 13:51 JimmyZ_ joined 14:26 Ven joined 15:20 vendethiel joined 15:21 JimmyZ__ joined
timotimo we b0rked --asan 15:29
probing whether your compiler thinks that it is gcc ==6073==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
15:48 JimmyZ_ joined 15:54 Ven joined 16:35 vendethiel joined 16:53 JimmyZ__ joined 16:57 FROGGS joined
FROGGS FYI: moarvm 2015.06-2 MIGRATED to testing 16:57
The status of the moarvm source package
in Debian's testing distribution has changed.
Previous version: (not in testing) 16:58
Current version: 2015.06-2
jnthn \o/
FROGGS much happy 17:00
nebuchadnezzar: how does moarvm get into stable/main or what it is called? 17:01
17:02 vendethiel joined
japhb FROGGS: ISTR the path was something like: Unstable --> Testing: O(weeks) with no new bugs relative to existing Testing release; Testing --> Stable: Whenever a new major release happens. 17:05
FROGGS japhb: the Unstable --> Testing happens after five days 17:06
japhb FROGGS: But it's been a while since I was following Debian day-to-day; I've drifted a couple forks away. (I used to ride Debian Testing as a matter of course, but I got frustrated when the odd failure happened and I couldn't use my computer.)
FROGGS: Methinks that's shortened over time. I would swear it used to be 2 weeks, but maybe that's just a broken memory.
FROGGS and since moarvm is now in testing, I guess we should focus on nqp and then rakudo? 17:07
and all of them will go into stable at some point
japhb Last time I switched distros at home, I went to Mint 17:08
FROGGS somehow
japhb Yeah, nqp seems next up. Might be worth doing nqp-m and nqp-j.
JimmyZ__ is using deepin linux..
FROGGS probably, yes
FROGGS uses ubuntu 17:09
bbl &
japhb Mint has the interesting structure that you can have either an Ubuntu-based one, or a Debian-based one. # "Would you like your Debian at one level of indirection, or two?" 17:11
JimmyZ: What made you choose that one?
17:12 Ven joined
JimmyZ__ japhb: based on ubuntu, but much better ui , easier use. 17:18
and winxp/win7/osx similar theme switch 17:19
japhb Yeah, part of my reason for using Mint was the desktop replacement, my laptop not being a 7" tablet. 17:24
JimmyZ__ I have tried mint , but I think its ui is not better than deepin 😊 17:27
japhb JimmyZ__: I use the non-default desktop (the one that looks kinda like GNOME 2) 17:28
JimmyZ__ japhb: deepin.org/?language=en 17:30
japhb: deepin.org/system.html for quick view. 😊 17:33
japhb chuckles at "Fashion mode" 17:34
That felt an awful lot like "For those who love Linux but envy Apple products" 17:35
JimmyZ__ there are another two modes 17:37
japhb Fair enough. :-) 17:38
17:40 Ven joined
JimmyZ__ For those who love linux but envy Windows xp/7 , haha 17:40
17:58 brrt joined
brrt \o 18:01
japhb o/
timotimo i've spent most of my evening getting rid of a headache ... though not thoroughly successfully :( 18:02
brrt hmm.. unfortunately there is no cure-all for headaches 18:05
18:05 vendethiel joined
brrt just, wow (at the deepin thingy) 18:06
to pursue perfectness and finely craft it 18:08
timotimo yeah, headaches can be any of a million types 18:11
i've tried taking a painkiller, but it didn't help much
and of course i drank lots of water
brrt sleep is also important :-) 18:15
timotimo i laid down for about an hour 18:19
didn't feel any better after that :( 18:20
and now i still have to shop some groceries
but dinner hasn't been decided yet
18:21 lucasb joined
lucasb Hi there. iiuc, moarvm is tracking libuv at 1.0.0. any reasons for not updating to the latest 1.6.1? 18:23
brrt last time we upgraded it caused some fallout, iirc 18:25
but it wouldn't harm too much just to check if we can upgrade 18:26
lucasb brrt: ok, thanks 18:27
brrt oh, there's another matter, libuv has had it's repo moved 18:28
lucasb yep, from joyent to libuv
timotimo huh, they are already at 1.6? 18:32
lucasb github says 1.6.1 is 25 days ago 18:33
brrt building and testing as we speak 18:34
although i should've run a spectest before going all-in
will TimToady be at YAPC::EU perchance? 18:37
nwc10 brrt: he's not yet marked as confirmed: act.yapc.eu/ye2015/search?country=us 18:42
brrt would be nice though
hmm. S17-lowlevel/lock.rakudo.moar still flaps 18:43
TimToady yes, Glo and I will be there 18:48
brrt \o/ 18:50
i hope to finally meet you there 18:51
18:51 vendethiel joined
dalek arVM/libuv-1.6.1-update: a5f39dd | brrt++ | / (2 files):
Update libuv to 1.6.1.

As far as I know, not associated with new spectest failures.		 18:54
timotimo is there a little summary of what we get by going from 1.0 to 1.6? 19:37
FROGGS brrt: Creating library moar.dll.lib and object moar.dll.exp 19:42
uv.lib(util.obj) : error LNK2001: unresolved external symbol __imp_GetUserProfileDirectoryW
19:56 brrt joined, zakharyas joined
brrt hmmmm 19:56
weird 19:57
which windows are you on?
i'll start a vm
FROGGS mine :P
no problem, I've got a fix I think
dalek arVM/libuv-1.6.1-update: eedb1fb | FROGGS++ | build/setup.pm:
link to userenv.dll on windows for latest libuv
 19:59
FROGGS brrt: ^^
brrt aha
quick find
FROGGS now I continue testing
brrt thanks 20:00
lizmat: i'm especially also interested in os x, winkwinknudgenudge ;-)
lucasb timotimo: for the changes from 1.0 to 1.6, maybe it is mostly bug fixes. (sorry for the delay, I was away) 20:16
github.com/libuv/libuv/blob/v1.x/ChangeLog 20:17
FROGGS brrt: that's the fallow: gist.github.com/FROGGS/49e998a91482821ec1bb 20:21
brrt: I know it is usually not clean on windows, so I'll rerun with libuv 1.
brrt wow, that's actually pretty bad
FROGGS 1.0*
brrt please do 20:22
timotimo cool, thanks lucasb 20:23
nwc10 jnthn: paste.scsys.co.uk/491510 is what ASAN makes of MVM_SPESH_NODELAY=1 and t/moar/01-continuations.t 20:24
timotimo i've seen this sort of error where it kinda looks like we're returning into an already-freed spesh bytecode segment or something 20:25
it completely stumped me :\
20:30 japhb joined
brrt FROGGS: i even see normal tests fail :-( 20:38
FROGGS brrt: I updated the gist 20:48
and it seems that windows is just unhappy in general 20:49
m: say <0x01/0x03> / (0x01/0x03) == 1 20:50
camelia rakudo-moar 7c35c5: OUTPUT«True␤»
brrt what's the diff?
FROGGS C:\rakudo>perl6-m -e "say <0x01/0x03> / (0x01/0x03)" 20:51
Attempt to divide by zero using div
brrt: the diff is that the sleep test worked on 1.6.1 20:52
brrt can be an accident, the sleep test working
FROGGS C:\rakudo>perl6-m -e "say <0x01/0x03>"
Attempt to divide by zero using div
true
m: say <0x01/0x03>
camelia rakudo-moar 7c35c5: OUTPUT«0.333333␤»
brrt hmm, frustrating 20:53
FROGGS C:\rakudo>perl6-m -e "say <0x01/3>"
0
that's weird 20:54
brrt rather
i'm off for tonight
FROGGS gnight
japhb m: say +'0x01/0x03' 21:05
camelia rakudo-moar 7c35c5: OUTPUT«0.333333␤»
japhb Because Str.Numeric. Boo-yah. 21:06
FROGGS but how can that be different on windows?
japhb FROGGS: <0x01/0x03> and +'0x01/0x03' are different parsers. Though why it would be different on Windows, I have no idea. Unless perhaps some obtuse compiler-sensitive bug in the grammar engine. 21:10
*are parsed by different parsers
21:17 colomon joined 21:18 TEttinger joined 21:39 colomon joined 22:29 colomon joined 23:58 TimToady 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!