Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-08-10

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

All times shown according to UTC.

Time Nick Message
00:46 zakharyas joined #moarvm
01:01 timotimo hm. adding the filename to spesh/dump.c output makes it more helpful, but it also leads to very long lines
01:04 timotimo now what would be really nice is to find a filename + line number annotation in the original and dump that
01:08 zakharyas joined #moarvm
01:09 colomon joined #moarvm
01:16 timotimo i'm not quite sure how to turn a hllboxtype or bootintarray operation into a set-like instruction ... set is only for moving data between registers, sp_get_o is for getting an object that's pointed at from a different object ...
01:17 timotimo i know i should be able to just set KNOWN_VALUE and value.o, but that could easily explode
01:22 timotimo theoretically i could just const_i64 it ... except on 32bit systems ... this is A Bad Idea™
01:30 FROGGS_ joined #moarvm
01:47 ilbot3 joined #moarvm
01:47 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
01:47 dalek MoarVM/spesh_hll_and_boot_types: 07b4b07 | (Timo Paulssen)++ | src/spesh/optimize.c:
01:47 dalek MoarVM/spesh_hll_and_boot_types: sketch out spesh for boot* and hll* operations
01:47 dalek MoarVM/spesh_hll_and_boot_types: review: https://github.com/MoarVM/MoarVM/commit/07b4b077f3
03:06 timotimo well, as expected just setting the known type + value and removing the instruction fails hard
03:13 timotimo oh my, why the F am i still up so early in the morning?
07:30 woolfy joined #moarvm
07:31 woolfy left #moarvm
08:24 lizmat_ joined #moarvm
08:37 brrt joined #moarvm
08:51 brrt \o
08:51 jnthn timotimo: Um, but facts.c already sets known type for all those.
08:52 jnthn timotimo: And if the instruction really isn't needed then dead instruction elimination will already get it
08:52 jnthn timotimo: And the JIT will typically turn the things into constants...
08:53 jnthn o/ brrt
08:53 jnthn timotimo: So there's not much more to do for them.
08:53 brrt constants? i didn't hear no nothing about constants?
08:53 brrt or are we talking about wvals
08:53 jnthn Any object literal that's in gen2
08:54 brrt oh yes
08:54 jnthn Yes, same thing as for wvals
08:54 brrt that may have not been totally implemented yet
08:54 jnthn Ah, ok
08:54 brrt for strings it has
08:57 brrt i had an idea that i'd like to implement
08:58 brrt basically, we can add in the oplist file some information that gives us the name of the symbol as well as the parameters that should be passed
09:00 brrt i.e. i could append something like &MVM_exception_die(iTr1a0), where everything between & and ( is the symbol name, and the string describes the parameters
09:00 brrt hmm
09:00 brrt oh, and after that comes the return value in some sense
09:01 FROGGS[mobile] joined #moarvm
09:17 jnthn ah, to generate a bunch of graph.c instead?
09:18 jnthn (Instead of hand-maintain it, that is...)
09:18 * brrt nods
09:18 brrt or well, even to do it dynamically
09:26 jnthn Comes after getting moar-jit merged, I'd say :)
09:26 jnthn But yeah, could be a nice idea.
09:28 dalek MoarVM/moar-jit: e95a0b8 | (Bart Wiegmans)++ | src/jit/graph.c:
09:28 dalek MoarVM/moar-jit: Split pre- and post- processing of instructions in jit graph
09:28 dalek MoarVM/moar-jit:
09:28 dalek MoarVM/moar-jit: This will ensure that even as some instructions consume multiple
09:28 dalek MoarVM/moar-jit: ops, annotations will still be applied correctly.
09:28 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/e95a0b8900
10:06 brrt i'm a bit puzzled as to how MVM_frame_find_contextual_by_name really works with regards to inlines
10:06 jnthn With difficulty...
10:06 brrt i.e. it seems that it only works for invoking frames because it requires return_address
10:07 brrt but it is initialized with the leaf frame
10:07 * brrt can see that at least :-)
10:08 jnthn Yes. And we disallow inlining of getlexdyn
10:08 jnthn So the other case needn't be handled.
10:08 jnthn Plus getlexdyn doesn't consider the currently executing frame, iirc.
10:09 jnthn Since we know what lexicals are in the curernt frame, so my $*FOO; ... $*FOO := 42; in the same frame just compiles into normal lexical access.
10:09 brrt hmm
10:09 brrt ok
10:09 brrt so this is a bug that's not a bug because it's guarded by two other constructs
10:09 brrt :-)
10:09 jnthn So yeah, we kinda get away with that case. You're understanding it right, though. :)
10:09 brrt nice
10:10 brrt ok, i'm going to re-enable getdynlex and see if it blows up
10:10 brrt fingers crossed
10:11 dalek MoarVM/moar-jit: dc2fca5 | (Bart Wiegmans)++ | src/ (2 files):
10:11 dalek MoarVM/moar-jit: Support dynvar caching again
10:11 dalek MoarVM/moar-jit:
10:11 dalek MoarVM/moar-jit: This was disabled because the JIT obfuscates where we are
10:11 dalek MoarVM/moar-jit: in the process, and thus we couldn't find exactly in which
10:11 dalek MoarVM/moar-jit: inlined frame we are. The JIT now keeps track of inline borders
10:11 dalek MoarVM/moar-jit: and so it is possible to enable this again.
10:11 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/dc2fca51d6
10:15 * brrt is amazed at how this keeps working
10:19 brrt https://gist.github.com/bdw/79da1fdbf5ec7f17b593 new bail log with getdynlex support
10:20 dalek MoarVM/moar-jit: 3c923a6 | (Bart Wiegmans)++ | src/ (2 files):
10:20 dalek MoarVM/moar-jit: Re-enable getdynlex
10:20 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/3c923a6dd9
10:20 jnthn lexoticresult tends to come quite late on and so would win us a bunch of frames
10:21 jnthn paramnamesused tends to come early on so likely hides other things :)
10:24 brrt yeah, i know what's needed for paramnamesused, and i'm still in the pondering phase of that
10:24 brrt :-)
10:25 brrt also, lexoticresult can / should be implented as a primitive i think
10:27 brrt hmm
10:27 brrt it need not be
10:27 brrt but it's just as well
10:33 brrt MVM_exception_throw_adhoc never returns, does it?
10:33 jnthn Hm, looks like lazily deserializing method caches - even without the work to less eagerly deserialize/set code objects - saves another 8MB or so off the base memory for Rakudo.
10:33 jnthn brrt: Correct; it lngjmp's back to the interp
10:34 brrt good
10:34 brrt :-)
10:38 brrt ah... newlexotic is wrong
10:38 brrt subtly so
10:44 * brrt brb
11:23 brrt joined #moarvm
11:36 timotimo ah, i knew i already saw code to handle boot* and hll*type >_<
11:36 timotimo that's why you don't code at 3 in the morning
11:39 * brrt back
11:43 timotimo o/
11:45 timotimo jnthn: i only got the idea to put these into optimize.c because i saw lots of those in a spesh log
11:45 timotimo so the dead code elimination doesn't kill them yet
11:45 timotimo may want to decrease the usages of the type for some ops in optimize.c
11:47 jnthn timotimo: Yes, in the past we were more hesitant about ->usages-- because deopt boundaries weren't handled properly. They should be now.
11:47 timotimo ok
11:48 timotimo also: holy crap, there are *many* useless set ops in some pieces of code
11:50 jnthn That's 'cus we turn various things into set :)
11:53 brrt uhm, maybe 24717904 is a bit large for an offset
11:53 jnthn much offset
11:54 brrt very so
11:54 dalek MoarVM: 4492a63 | jnthn++ | src/ (6 files):
11:54 dalek MoarVM: Lazily deserialize method caches.
11:54 dalek MoarVM:
11:54 dalek MoarVM: Saves another ~8MB off base memory for Rakudo.
11:54 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4492a6344b
11:56 timotimo i may need to help friends move a bunch of boxes before tackling the usages-- thing
11:58 brrt will the boxing be in time?
11:58 timotimo :)
12:05 colomon joined #moarvm
12:06 brrt wow, offsets are really large
12:09 brrt oh, i see why
12:09 brrt they're transformed into bb pointers
12:09 brrt that's
12:09 brrt inconvenient
12:10 brrt i'll be needing the instruction in some cases and the basic block in others
12:10 jnthn Why do you need those, ooc?
12:11 jnthn Those offsets would correspond to the unoptimized bytecode...sometimes.
12:11 jnthn (As in, not if the subgraph is inlined)
12:11 brrt the newlexotic op takes the hard coded bytecode offset
12:11 jnthn Oh...
12:12 brrt watchpoints are useful by the way :-o
12:12 jnthn And then uses it to resolve a handler, iirc?
12:12 brrt es
12:12 brrt yes
12:12 * jnthn wonders if we can't pre-resolve that when JITting...
12:13 jnthn ...or at least use a label address
12:13 jnthn Since we have handler labels too
12:14 brrt hmmm
12:14 brrt yes
12:14 brrt that's possible too
12:14 jnthn That feels less fragile
12:15 brrt but i'll have to modify the newlexotic function a bit
12:15 brrt i can even use the label number, how about that
12:15 timotimo it seems like i was just tripped up by the before/after refering to the logging instruction insertion, not the spesh process itself
12:16 timotimo it seems like boot* and hll*type are kicked out properly already
12:17 jnthn ah, cool :)
12:18 jnthn brrt: Yeah, or just a newlexotic_jit function :)
12:18 brrt oh, yeah, that's possible too
12:18 timotimo MVMArray only speshes create, i think it'll be easy to spesh things like elems as well
12:19 jnthn yeah, elems should be easy
12:19 jnthn Other things less so
12:19 timotimo aye.
12:20 brrt yay, copy paste coding :-)
12:24 brrt jnthn: it occurs to me that after codegen, we might also restore the ins_offset to its then-current value
12:24 brrt or wait
12:24 brrt not
12:24 jnthn After code-gen we often throw the graph away... :)
12:25 brrt yeah, but not before the JIT has access to it
12:25 brrt but i don't like that hack
12:26 jnthn no, that'd be horrible
12:27 timotimo huh.
12:28 timotimo for sp_get_i i should supply something like offsetof( MVMArray, body.elems ), right?
12:31 timotimo because that's what i'm doing right now and it faceplants pretty loudly
12:33 jnthn Something like that, yes
12:33 * timotimo huhs
12:33 jnthn How does it fail?
12:34 timotimo Cannot call method 'MATCH' on a null object
12:34 timotimo at gen\moar\stage2\QRegex.nqp:552  (src/vm/moar/stage0/QRegex.moarvm:CAPHASH:4294967295)
12:34 jnthn Odd
12:35 timotimo maybe i'm trying to get the elems count from an array that's actually VMNull?
12:35 timotimo but wouldn't the non-spesh'd code have blown up in that case, too?
12:35 timotimo except if it would have caught the resulting exception
12:36 timotimo but no, we're relying on known_type, which would force the register to have non-null contents, right?
12:36 jnthn Should do, yes
12:36 jnthn I guess that the opt does come in with truthiness checks too
12:37 jnthn So it's possible there's an elems check
12:37 jnthn And that control access to something else
12:38 timotimo there is only a single sp_get_i in the resulting spesh log, which is inside !cursor_capture
12:39 timotimo the offset is 24, which should be the exact length of an object's header
12:39 timotimo we guardconc directly before that get_i
12:39 timotimo and afterwards we seem to push_i the result from elems somewhere
12:41 timotimo aye
12:41 timotimo cursor_capture does push_i($!bstack, nqp::elems($!cstack))
12:41 brrt hmmm
12:42 timotimo (and just to be sure i verified that it succeeds if i don't spesh it)
12:42 timotimo (don't spesh it == MVM_SPESH_DISABLE)
12:43 timotimo and without the elems optimization it succeeds, too
12:51 jnthn You are checking its known concrete as well as known type, I guess?
12:51 jnthn I guess that goes for all repr things...
12:52 timotimo oh!
12:52 timotimo the repr guard only checks for known type actually
12:52 timotimo that could be a problem
12:53 timotimo another thing we should fix soon is that the optimize_repr_op does "use_facts" for us on the type fact, but the spesh slot of the repr doesn't signal whether or not it actually did anything
12:53 timotimo so the use_facts ought to move into repr's spesh methods
12:53 timotimo i can do that, too
12:53 jnthn True
12:54 timotimo checking that FACT_CONCRETE is set doesn't fix the problem, unfortunately
12:55 brrt and.. i know why it fails, too
12:55 brrt (this is something else entirely)
12:55 timotimo that's still good for you :)
12:55 timotimo we can just leave out the spesh for MVMArray's spesh, but we can't really leave out a big chunk of the jit like handler support ;)
12:56 timotimo AFK for a bit
12:58 brrt :-)
12:59 brrt completely offtopic: my qualified biologists opinion on anti-aging and calico in particular is that it is the dumbest thing ever
13:00 brrt all organisms age, because all organisms must tradeoff between reproduction, growth, and maintenance
13:02 brrt that doesn't change when you throw google-type money against the problem
13:05 jnthn Trying to "deal with death" is a human obsession since forever, I guess; it's just that now we're seeing folks try to throw science at it instead of religion. :)
13:07 brrt i suppose that's true
13:07 brrt but it's also incredibly naive about how organisms and especially large vertebrates actually work
13:08 brrt and that's annoying
13:08 xiaomiao brrt: and if you reduce the "death" mechanism you amplify the "cancer" mechanism, most of the time
13:09 xiaomiao I'm not sure that's a good idea :)
13:09 brrt yeah, that is very true
13:09 brrt very very true
13:09 brrt it's a problem
13:09 brrt :-)
13:10 brrt despite that, progress on cancer has been pretty good the last few years, so i may be totally wrong
13:11 xiaomiao yes. I'm sometimes surprised by the progress in medicine
13:11 dalek MoarVM/moar-jit: 57b8266 | (Bart Wiegmans)++ | src/ (6 files):
13:11 dalek MoarVM/moar-jit: Fix newlexotic
13:11 dalek MoarVM/moar-jit:
13:11 dalek MoarVM/moar-jit: Newlexotic normally takes the bytecode offset of the frame
13:11 dalek MoarVM/moar-jit: handler goto label, but this is transformed into a pointer to
13:11 dalek MoarVM/moar-jit: the basic block during spesh graph creation. Instead of looking
13:11 dalek MoarVM/moar-jit: up the correct value using some hack, pass the label instead.
13:11 dalek MoarVM/moar-jit:
13:11 dalek MoarVM/moar-jit: Because the goto annotation is attached to an instruction and
13:11 dalek MoarVM/moar-jit: the instruction points to a block, the labels of these would diverge
13:11 dalek MoarVM/moar-jit: if the annotated instruction was not the first of the basic block,
13:11 xiaomiao appendix removal with microsurgery and such tricks
13:11 dalek MoarVM/moar-jit: as would happen if there where PHI nodes before. So I've changed the
13:11 dalek MoarVM/moar-jit: labeling code to disregard PHI nodes when labeling an instruction.
13:11 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/57b82663f9
13:13 * brrt bbiab
13:14 * jnthn will give latest moar-jit a spin after the current block/code object work he's doing :)
13:15 brrt please do
13:15 brrt i've tested it of course, but more is better wrt to testers :-)
13:15 brrt left #moarvm
14:17 brrt joined #moarvm
14:18 brrt \o
14:18 timotimo ¯o¯
14:18 brrt :-)
14:34 brrt much nqp / rakudo code churn
14:35 timotimo really quite looking forward to the next commit jnthn is likely going to push
14:36 brrt does the 'Cannot look up attributes on a type object' bug say anything to any of you?
14:36 timotimo oh?
14:36 timotimo haven't seen that come up in builds often
14:37 brrt ugh
14:37 brrt my code is broken again :-(
14:38 jnthn timotimo: Turns out that it's not an immediate big win.
14:38 timotimo oh
14:38 timotimo OK
14:38 jnthn Which probably means we've another source of object "leaks"
14:39 timotimo sure; sadly we don't have a good tool to find those
14:39 timotimo but i'm still looking forward :P
14:39 jnthn Only me.
14:39 timotimo hah
14:39 jnthn .oO( crap, did I just call myself a tool... )
14:40 * brrt heard it
14:40 jnthn One good bit of news though; it does knock a little more off setting compilation
14:40 brrt hmm
14:40 timotimo oh? how does it do that? %)
14:40 brrt my settings compilation has risen to 62s by now
14:40 brrt and
14:40 avar joined #moarvm
14:40 avar joined #moarvm
14:40 brrt breaks
14:40 jnthn Well, just because it's cheaper to stick a pair of IDs on a MAST::Frame that generate a bunch of QAST, and then MAST, that does a wval lookup and so forth.
14:41 timotimo ah, yeah
14:41 timotimo that does make sense :)
14:42 ggoebel1111113 joined #moarvm
14:44 dalek MoarVM: 34a1a35 | jnthn++ | / (9 files):
14:44 dalek MoarVM: Enable code objects to be lazily deserialized.
14:44 dalek MoarVM:
14:44 dalek MoarVM: We now can attach the indexes to a MAST::Frame, and keep them around
14:44 dalek MoarVM: until such a time as we need the code object. The goal is that, in
14:44 dalek MoarVM: conjunction with some other improvements, we might be able to avoid
14:44 dalek MoarVM: deserializing many code objects in Perl 6, along with signatures,
14:44 dalek MoarVM: parameters, etc.
14:44 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/34a1a351e8
14:44 nwc10 brrt: yes, I get "Cannot look up attributes in a type object" too.
14:45 brrt wait what
14:45 nwc10 setting build, Stage optimize, nom HEAD
14:45 brrt with jit?
14:45 brrt or without?
14:45 * brrt also gets that bug
14:45 nwc10 with
14:45 brrt oh bloody hell
14:46 nwc10 ASAN doesn't spot anything bad
14:46 brrt ugh :-(
14:49 timotimo nqp builds in just 30 short seconds
14:49 timotimo that's pretty good
14:49 jnthn Way better than taking 30 long seconds.
14:50 timotimo yep
14:52 jnthn Urgh. If I build CORE.setting with a tiny nursery I get SEGV
14:52 timotimo interestingly, -march=native doesn't change build times
14:52 jnthn ah...
14:52 jnthn void MVM_reentrantmutex_lock(MVMThreadContext *tc, MVMReentrantMutex *rm) { if (MVM_load(&rm->body.holder_id) == tc->thread_id) {
14:52 jnthn SEGVs there
14:52 jnthn timotimo: Didn't you add a reentrant mutex recently?
14:52 timotimo oh, did the mutex for the compunit not get initialized early enough?
14:53 timotimo i did, yes
14:53 jnthn Did you GC mark it?
14:53 timotimo i think so. gimme a sec.
14:53 jnthn Or write-barrier assigning it?
14:53 timotimo i gc-mark it
14:53 timotimo and i assign_ref it
14:53 timotimo might be wrong
14:53 timotimo it's in MVMCompunit.c
14:53 brrt :-(
14:54 jnthn oh...
14:54 jnthn MVM_ASSIGN_REF(tc, &(root->header), body->update_mutex, REPR(mutextype)->allocate(tc, STABLE(mutextype)));
14:54 jnthn That isn't too wise
14:54 timotimo dang. i don't grok the assign_ref macro at all >_<
14:54 jnthn Well, it's that body can get invalidates by the allocation
14:57 jnthn Ended up looking at this 'cus i got a not-very-reproducable explosion while building CORE.setting during an earlier change
14:57 timotimo i'll ask for double-checks whenever i use the assign ref macro in the future
14:57 * jnthn runs it again to see if we look better this time
15:00 brrt things where going too good today :-(
15:00 timotimo for "say 1" i'm down to 105 mb maxrss
15:01 jnthn Is rss the one including mmap'd stuff?
15:01 timotimo that's a good question
15:01 timotimo but it used to be 135mb
15:02 jnthn Well, on Windows I get around 89mb, is all
15:02 timotimo mhm
15:03 timotimo could well be that it counts that on linux but not on windows
15:06 * brrt hopes something is wrong with newlexotic
15:06 dalek MoarVM: 43991af | jnthn++ | src/6model/reprs/MVMCompUnit.c:
15:06 dalek MoarVM: Correct comp unit mutex setup.
15:06 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/43991af665
15:07 timotimo mhm mhm
16:20 brrt joined #moarvm
16:21 brrt left #moarvm
16:21 brrt joined #moarvm
16:25 flussence joined #moarvm
16:30 brrt uhm, it's kind of difficult to repeat this bug of ours
16:31 timotimo that sounds good. we don't want to repeat bugs, right? :P
16:34 brrt hmmm
16:34 brrt yes and no
16:35 brrt we want any bugs that do exist to be repeatable
16:35 timotimo reproducible is the word we're looking for, eh?
16:36 brrt yes
16:36 brrt :-)
16:40 dalek MoarVM/moar-jit: 91b60e5 | (Bart Wiegmans)++ | src/jit/graph.c:
16:40 dalek MoarVM/moar-jit: Add binddynlex support.
16:40 dalek MoarVM/moar-jit:
16:40 dalek MoarVM/moar-jit: Note that this seems to work, but I've seen spurious,
16:40 dalek MoarVM/moar-jit: difficult-to-repeat crashes in stage optimize, and nwc10++ has seen them
16:40 dalek MoarVM/moar-jit: as well.
16:40 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/91b60e5c90
16:42 brrt any help in reproducing the bugs would be greatly appreciated
16:43 FROGGS ohh, two witnesses O.o
16:44 brrt can you repeat it?
16:44 FROGGS not tried yet... that would happen in rakudo's stage optimize?
16:45 timotimo there seems to be a merge conflict when pulling master into moar-jit
16:45 timotimo but we probably should get that segfault fix jnthn made above (for the compunit mutex initialisation)
16:45 brrt yes
16:45 brrt i'll merge master
16:46 timotimo oh
16:46 timotimo that's not really a conflict
16:46 timotimo that's two things being added at the same place
16:46 brrt :-)
16:46 brrt easy enough to resolve i think
16:47 brrt hmm
16:47 brrt or not
16:47 timotimo it's just that a } got disappeared from the "conflict"
16:47 brrt oh i see
16:48 dalek MoarVM/moar-jit: 5494549 | jnthn++ | src/ (5 files):
16:48 dalek MoarVM/moar-jit: Make static lexical deserialization lazier.
16:48 dalek MoarVM/moar-jit:
16:48 dalek MoarVM/moar-jit: Only deserialize on first usage of a particular lexical now. Cache it
16:48 dalek MoarVM/moar-jit: so future lookups are fast. Much work in this patch by timotimo++.
16:48 brrt merged :-)
16:48 timotimo good :)
16:49 * FROGGS builds
16:49 dalek joined #moarvm
16:49 * brrt builds too
16:51 timotimo hmm, jit makes the nqp build take a bit longer
16:51 brrt yes, that's what i find as well
16:52 brrt bloody!
16:52 brrt anyway, the crash report is clear enough
16:52 brrt i'll look at it after dinner
16:52 * brrt dinner &
16:53 brrt left #moarvm
16:53 timotimo i can get it to be a tiny bit less slow by using -j2
16:54 timotimo i get that same error brrt got
16:56 timotimo with spesh disabled, it works again
16:57 jnthn If you disable spesh, it won't JIT... :)
16:58 timotimo it breaks when having inline disabled
17:01 FROGGS /home/froggs/dev/MoarVM/3rdparty/dynasm/minilua.c:3496: undefined reference to `floor'
17:01 FROGGS /home/froggs/dev/MoarVM/3rdparty/dynasm/minilua.c:3497: undefined reference to `pow'
17:01 FROGGS /tmp/ccuGAzX8.o: In function `luaV_execute':
17:01 FROGGS :o(
17:03 FROGGS that's the cmd btw: gcc -O1 -DNDEBUG -g3  -D_REENTRANT -D_FILE_OFFSET_BITS=64 -fPIC -DMVM_TRACING=0 -DMVM_CGOTO=1 -lm -lpthread -lrt -ldl 3rdparty/dynasm/minilua.c -o 3rdparty/dynasm/minilua
17:03 FROGGS /tmp/ccuGAzX8.o: In function `constfolding':
17:20 timotimo i thought -lm had that?
17:29 nwc10 m: say  5.6892e+01/5.7454e+01; say 5.6892e+01/6.597e+01
17:29 camelia rakudo-moar 5d5ec1: OUTPUT«0.990218261565774␤0.862391996361983␤»
17:40 nwc10 Stage optimize   : Cannot look up attributes in a type object at src/Perl6/Optimizer.nqp:606  (blib/Perl6/Optimizer.moarvm:lexical_vars_to_locals:4294967295)
17:40 nwc10 that's an interesting line number
17:41 nwc10 moar-jit HEAD, master, nom
17:41 nwc10 moar's master is fine
17:42 dalek MoarVM/moar-jit: ef9e381 | (Tobias Leich)++ | build/Makefile.in:
17:42 dalek MoarVM/moar-jit: fix build of minilua by moving LDLIBS to the end
17:42 dalek MoarVM/moar-jit:
17:42 dalek MoarVM/moar-jit: See http://stackoverflow.com/questions/9253200
17:42 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/ef9e3816be
17:42 timotimo *sigh*
17:42 FROGGS I am a JIT hacker \o/
17:42 timotimo yeah, linking order
17:52 FROGGS Stage optimize   : Cannot look up attributes in a type object
17:52 FROGGS at src/Perl6/Optimizer.nqp:606  (blib/Perl6/Optimizer.moarvm:lexical_vars_to_locals:4294967295)
17:52 FROGGS from src/Perl6/Optimizer.nqp:867  (blib/Perl6/Optimizer.moarvm:visit_block:0)
17:53 nwc10 same as mine. With the same interesting line number
17:53 timotimo how come we generate so many gotos directly before the label they point to?
17:53 FROGGS O.o
17:54 FROGGS that does not make much sense
17:54 timotimo i mean
17:54 timotimo only one goto each
17:54 timotimo but we do that often
17:55 FROGGS 606 is the line after the comment:
17:55 FROGGS # Also ensure not dynamic.
17:55 FROGGS my $dynamic := try nqp::getattr($qast.value, nqp::p6var($qast.value).WHAT, '$!descriptor').dynamic;
17:56 FROGGS so $qast.value is probably NQPMu
17:56 timotimo https://gist.github.com/timo/b2420e6f5db8d5791266
17:56 timotimo just from looking at optimizer.nqp.moarvm a bit
18:00 FROGGS ohh dear
18:00 FROGGS it is a Heisenbug like the NFA thing...
18:01 timotimo noooo :<
18:01 FROGGS when I do the following before line 606 it succeeds:
18:01 FROGGS nqp::say($qast.value.HOW.name($qast.value));
18:03 jnthn If it looks like a try not working, or working flakily, given handlers were recently enabled in the JIT, that could be a hint...
18:06 FROGGS now I get:
18:06 FROGGS Stage optimize   : Spesh: failed to fix up handlers (-1, 672, 672)
18:06 FROGGS at <unknown>:1  (blib/Perl6/Optimizer.moarvm:lexical_vars_to_locals:4294967295)
18:06 FROGGS (I added this before line 606: unless nqp::istype($qast.value, NQPMu) { )
18:06 FROGGS might be easier to debug, I dunno
18:09 timotimo jnthn: superfluous gotos are not terribly expensive, aye? they don't cost much to interpret and having more BB's in spesh won't be the end of the world either, right?
18:09 timotimo how costly is it to const_s the very same string into registers multiple times over?
18:10 jnthn That's cheap, and probably JITs really cheap
18:11 timotimo the most costly part is probably causing speshing and jitting to do more work unnecessarily
18:11 jnthn The surplus gotos aren't a huge deal, but would be nice to dispose of
18:13 dalek MoarVM: ec09497 | jnthn++ | src/core/ (5 files):
18:13 dalek MoarVM: Fix --dump when there are state variables.
18:13 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ec094974ef
18:33 brrt joined #moarvm
18:34 FROGGS damn, my pseudofix for the NFA bug does not work anymore :o(
18:39 * brrt rather hopes this is a bug in handlers
18:48 woolfy joined #moarvm
18:56 jnthn Today's fun story: earlier on this evening I left a spectest run to happen while I went to cook dinner. Upon returning to my computer after dinner, it was utterly hosed: loudly swapping, and unresponsive to pretty much anything.
18:56 brrt hmm, disabling inlines or disabling OSR doesn't change it
18:56 brrt ok, /me wonders how this will end
18:57 jnthn A restart later, I watched it spectest. And found I'd broken slurp.t in such a way that one test looped and allocated at a rate of about 500MB/s :)
18:57 jnthn In other words, 30s to fill all available RAM :)
18:58 brrt uhm... 30s * 500MB/s is .... 15GB ?
18:58 brrt not bad
18:58 jnthn Yeah, I got 16GB of RAM in here
18:58 jnthn I don't know how far it made it into the swap :)
18:59 jnthn Anyway, turns out it was the same bug that had broken encode.t the other day :)
18:59 FROGGS jnthn: you are working on string ops optimization?
18:59 jnthn No!
19:00 jnthn Was improving code-gen believe it or not :)
19:00 FROGGS ahh :o)
19:00 jnthn I got rid of a ton of useless wval and getlex operations we were code-gening in the mainline.
19:00 brrt gcc without optimize is truly ridiculously fast
19:01 brrt (i.e. fast in generating code, not so much in generating fast code)
19:01 nwc10 does the code gen still make defensive assumptions necessary for parrot?
19:01 FROGGS nice, my NFA pseudofix works again, let's get another --dump out of it...
19:01 nwc10 IIRC refetching lexicals repeatedly
19:01 jnthn Which is great except they were providing enough ordering to the deserialize to hide a nasty bug
19:03 FROGGS jnthn: the --dump of my program (grammar match) is identical when working correct and when not...
19:03 jnthn o.O
19:04 FROGGS except for cuids and stuff like that:
19:04 FROGGS -00009   const_s      loc_2_str, '2014.07-145-g5d5ec1e'
19:04 FROGGS +00009   const_s      loc_2_str, '2014.07-141-gb86a152'
19:05 FROGGS jnthn: shall I dump the QRegex.moarvm?
19:06 jnthn FROGGS: Can try that, yes
19:06 FROGGS k
19:07 FROGGS FROGGS: these revisions work for v5: 2014.07-141-gb86a152 / 2014.07-60-g2b21569 / 2014.07-112-gec09497
19:11 brrt apparantly, MVM_exception_throw_adhoc is called quite often
19:11 dalek MoarVM: d0c50da | jnthn++ | src/6model/serialization. (2 files):
19:11 dalek MoarVM: Provide a way to force-deserialize an STable.
19:11 dalek MoarVM:
19:11 dalek MoarVM: Sometimes, we get ordering dependencies with deserializing REPR data.
19:11 dalek MoarVM: Now that we deserialize lazily, this can get us into trouble. Enable
19:11 dalek MoarVM: fixing this by providing a mechanism for enforcing the dependency.
19:11 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d0c50dafa2
19:11 dalek MoarVM: 693a628 | jnthn++ | src/6model/reprs/MVMArray.c:
19:11 dalek MoarVM: VMArray types depend on their element type.
19:11 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/693a62837b
19:11 dalek MoarVM: 514c504 | jnthn++ | src/core/frame.c:
19:11 dalek MoarVM: Allow takeclosure to not force the code object.
19:11 timotimo nice :)
19:11 FROGGS indeed :o)
19:12 jnthn Walk, but then I really need to protect SCs with a lock now we do lazy deserialization.
19:12 jnthn As the lazier we get, the hoseder our threading tests get...
19:12 FROGGS Protect all our SCs! /o/
19:12 timotimo %)
19:13 jnthn Anyway, I also discovered something that shoots a hole in all the lazy
19:13 FROGGS ó.ò
19:13 jnthn Which is that the first thing tht happens after CORE.setting has finished loading is we go and iterate over every leixcal in it.
19:14 jnthn In order to know what's in the outermost context.
19:14 timotimo hah
19:14 jnthn So even now I've fixed all the other bits, we've still that one.
19:15 jnthn Anyway, bbiab &
19:24 timotimo that's an interesting occupation
19:24 timotimo iterating over all the lexicals
19:44 nwc10 brrt: sadly valgrind gives no clues as to what's up with the JIT failing to build the setting
19:44 brrt i had expected it not to :-)
19:51 nwc10 jnthn: much spectest failure for: This is MoarVM version 2014.07-115-g514c504
19:51 nwc10 2 I have sampled are both:
19:51 nwc10 ===SORRY!===
19:51 nwc10 Cannot call method 'dispatcher' on a null object
19:51 nwc10 no ASAN barfage
19:53 nwc10 OK, different one:
19:53 nwc10 $ ./perl6-m t/spec/integration/advent2010-day14.t
19:53 nwc10 1..5
19:53 nwc10 Cannot call method 'name' on a null object in any vivify_for at src/gen/m-Metamodel.nqp:2998
20:07 jnthn nwc10: Yes, I've a patch for that one locally
20:07 nwc10 OK, good to know
20:07 jnthn (Didn't push a MOAR_REVISION bump that makes anybody following the supported path see this)
20:08 nwc10 yes, I am rather getting what I am asking for
20:36 lizmat joined #moarvm
20:36 FROGGS jnthn: I think I know something about the NFA bug
20:37 * jnthn imagines FROGGS++ knows all too much about it by now :)
20:37 FROGGS jnthn: you remember that I added a +@substates, which "fixes" it?
20:37 * jnthn does some spectesting in home of various pushes and version bumps...
20:37 jnthn FROGGS: yes
20:38 FROGGS jnthn: so in order to have nice comparable dumps of qregex I added a +%seen
20:38 FROGGS so I have the same number of lines and locals and so on
20:38 FROGGS now, +%seen does not fix the issue
20:38 FROGGS and now look at this:
20:38 FROGGS 00059   decont       loc_8_obj, loc_8_obj
20:38 FROGGS 00060   smrt_numify  loc_20_num, loc_8_obj
20:38 FROGGS 00062   isfalse      loc_15_int, loc_8_obj
20:39 FROGGS this is +@substates and the condition afterwards
20:39 FROGGS we are decont-ing in place
20:39 FROGGS that's why it has an effect
20:39 jnthn hmmmm
20:39 FROGGS right?
20:39 jnthn Well
20:39 jnthn It's OK for it to immediately re-use it *if* loc_8_obj were a temporary
20:41 jnthn Bad code generator.
20:41 jnthn push_op($il, 'decont', $reg, $reg);
20:43 FROGGS and this also means that we sneak in an extra container for my example code
20:43 FROGGS (in perl6-m only)
20:44 FROGGS m: grammar G { token TOP { <a> }; proto token a {*}; token a:sym<foo> { <b> }; token a:sym<indirect> { \w+ }; proto token b {*}; token b:sym<foo> { <sym> } }; say(G.parse("foo"))
20:44 camelia rakudo-moar 5d5ec1: OUTPUT«「foo」␤ a => 「foo」␤␤»
20:44 FROGGS this
20:45 dalek MoarVM: 9a4fda8 | jnthn++ | src/6model/ (3 files):
20:45 dalek MoarVM: Fix data races in lazy deserialization.
20:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9a4fda83f6
20:45 FROGGS that also means that fixing the side effects of that decont might break something
20:45 jnthn Well, the side-effect is clearly wrong
20:45 jnthn I've a patch fixing it building now
20:47 FROGGS nice :o)
20:47 jnthn Now I've got about 4 things that should be committed independently to pick out of QAST -> MAST... :)
20:48 jnthn eek
20:48 jnthn Fixing that gets me
20:48 jnthn ===SORRY!===
20:48 jnthn No such private method '!canon-cat' for invocant of type 'IO::Spec::Win32'
20:48 FROGGS eww
20:48 FROGGS btw, have you also fixed add_bindattr_op and add_getattr_op?
20:49 FROGGS they do: push_op(@ins, 'decont', $type_mast.result_reg, $type_mast.result_reg);
20:49 colomon joined #moarvm
21:01 jnthn FROGGS: oh, now I look at the patch again, I did a silly typo
21:02 jnthn yeah, it was that, I think
21:02 FROGGS ohh, nice
21:02 jnthn Also, I don't know if this is partly my forced reboot, but..
21:02 jnthn command took 0:1:0.11 (60.11s total)
21:03 jnthn First time building Rakudo has been basically a minute
21:03 FROGGS I had a stage parse of 36s a few hours ago, which is quite impressive
21:03 jnthn hm, now we've got this patch do I should spectest again :)
21:03 timotimo neato
21:03 jnthn Mine is 26.727 by now
21:04 FROGGS well, spectests do not take that long, so... :o)
21:04 FROGGS wow
21:04 jnthn It was pushing towards 39s at the point of the last month's release.
21:04 FROGGS I have said that "we" reach 20s this year
21:04 timotimo that feels like it is in reach now
21:04 FROGGS when you had 39s I had about 46s+
21:04 timotimo i'm quite curious what makes the jit-enabled moarvm that much slower
21:05 timotimo we do run the jitted code, because we can make things crash by having it generate bad/bogus code
21:05 timotimo but ... it's not much faster? generating the jitted code doesn't seem to show up in profiling, does it?
21:06 jnthn I got curious about this and spent a bit of time looking for a construct the JIT makes slower.
21:06 jnthn And failed. Anything involving some loops and repeated operations I tried happening in around half the time with the JIT
21:07 FROGGS we'll have the first JIT that makes your program slower :P
21:07 jnthn Well, depends on your program, it seems
21:08 jnthn But yeah, CORE.setting seems unhelped so far.
21:08 FROGGS sure
21:08 FROGGS was just a joke anyway
21:11 brrt joined #moarvm
21:16 FROGGS jnthn: as expected my little grammar fails to match correctly
21:17 timotimo jnthn: do we still have to build the millions and gazillions of local variables to do the getcode/takeclosure dance?
21:17 timotimo or could we just be re-using a couple?
21:21 jnthn It does that because in much code we need them
21:21 timotimo oh, ok
21:22 timotimo so, what kind of things are we doing in that first frame anyway? setting up closures and executing init-time things?
21:22 brrt come on... why won't gdb just break where i need it
21:28 FROGGS <optimized out>
21:28 jnthn timotimo: Basically that, yes
21:34 brrt how many ways really exist to dump a backtrace?
21:34 timotimo most of them do
21:36 brrt configure --optimize=0 fixes that
21:37 brrt but, it also makes moar twice as slow
21:44 jnthn Enough for today...
21:45 jnthn brrt: Will have a bunch of Perl 6 time tomorrow, so will build the latest JIT then and see if I can spot what's happening...
21:45 jnthn 'night, #moarvm
21:48 FROGGS gnight

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