japhb Or is that: beer --> jnthn --> code 00:00
jnthn Probably sleep in not so long, but today I did things that mean I have a decent amount of Perl 6 time ahead of YAPC::EU, when there was a risk I'd have almost none. :) 00:01
japhb Very good news, that
jnthn Turning 3 longhaul flights into 1 usually is. :) 00:02
japhb Woah, yeah
jnthn As to the r-m benchmark regressions, are they all ones involving for loops? 00:04
japhb Loops in general, methinks
Time 2014.07 against nom/master, and you can see the regression in both nqp-m and r-m 00:05
(Note that I haven't tested -jvm or -parrot to see if these are at the VM-specific level or the VM-agnostic level) 00:07
jnthn OK 00:09
Will give it a look tomorrow, after some sleep :)
japhb Sure, sleep well 00:11
jnthn 'night o/ 00:13
diakopter o/
00:27 sergot joined 01:01 colomon joined 01:25 zakharyas joined 01:32 FROGGS_ joined 06:54 woolfy joined 07:24 woolfy left 07:49 itz joined 09:10 brrt joined
brrt \o 09:10
FROGGS_ o/ 09:12
nwc10 \o/ 09:14
jnthn: so beer is followed by very headache? 09:22
or just much lie-in?
brrt oh, much tail call optimization 09:35
09:47 colomon joined 09:59 woolfy joined, woolfy left 10:17 woolfy joined, woolfy left 10:21 lizmat joined
jnthn nwc10: Much lie-in, plus coffee, reading news, shopping... :) 11:21
FROGGS life is good :o) 11:22
jnthn According to the news, not for everyone... 11:23
FROGGS yeah, that's one reason I don't watch/read the news 11:27
jnthn: btw, I have a "fix" for that NFA bug 11:30
I just have to add a "+@substates;" after that line: github.com/perl6/nqp/blob/master/s...A.nqp#L330
jnthn Huh? 11:32
That's a no-op?
FROGGS I know :o)
but it keeps that variable in place I think
otherwise it ends up being a null object or so 11:33
jnthn If that makes a difference it's gotta be a bug of some kind...
FROGGS yeah, I just don't know how to debug that further
all I know is that it is not a speshbug
jnthn ah
That's a relief :)
FROGGS well, sort of :o) 11:34
jnthn Instruction deletion gone wild or something
Well, that means it could be in code-gen...
FROGGS hmmm, maybe I should --dump my program?
I mean, with and without my "fix" 11:35
jnthn Yes, that's worth a try
FROGGS k, will do that today
jnthn Though I did a fix for --dump recently, but it ended up in moar-jit... 11:36
FROGGS but right now I can continue hacking on v5, which is nice :o)
jnthn OK :)
FROGGS jnthn: well, I can cherry-pick it, no?
jnthn True :)
FROGGS++ for tracking this down
FROGGS not yet done :o)
11:56 woolfy1 joined, woolfy1 left 12:06 colomon joined 12:09 lizmat joined 12:10 woolfy joined, woolfy left 12:26 cognome joined
timotimo jnthn: i tried --dump very recently on moar-jit and it still error'd out due to SC lazyness stuff :( 13:08
jnthn huh...why does it even care about SCs... 13:11
jnthn is doing a JVM build of his qast_restructure stuff 13:12
timotimo let me try stuff out. 13:17
jnthn "Error while reading from file: java.nio.charset.MalformedInputException: Input length = 1" 13:18
wtf
timotimo we had that recently, didn't we? 13:19
jnthn Hm, I think somebody else may have reported it... 13:21
timotimo something about one of the files not being generated properly or something?
jnthn gen/jvm/CORE.setting looks a reasonable size at least
timotimo timo@schmand ~/p/nqp (master)> moar --dump NQPCORE.setting.moarvm 13:22
Unhandled exception: SC not yet resolved; lookup failed
jnthn oh... 13:24
Somehow some quotes are being turned to ANSI during generating gen/jvm/CORE.setting 13:25
timotimo the JVM trying to be helpful? 13:26
like MS word? %)
jnthn StandardWriteHandle seems to do setEncoding(tc, Charset.forName("UTF-8")); 13:29
bah, found it 13:40
Of course, what shoulda been a 2 line patch took a bunch more because Java. :/
vendethiel hehe, suffering for us so that *we* don't have to suffer writing java (to use the jvm) :p 13:53
14:18 jimmyz_ joined
jimmyz_ Stage parse : 31.236, before: ~33.3s, after qast_refactor. :) 14:20
jnthn Yeah, I saw a small speedup too. And a bit less memory use 14:21
jimmyz_ yeah 14:22
The last number I can remember was `Stage parse : ~46s(MoarVM)` 14:23
timotimo oh wow 14:24
that must have been very long ago ;)
oh, wait! :D
jnthn++
jimmyz_ yeah, long time ago :)
while parrot was ~600s 14:25
timotimo ouch!
14:34 avar joined 14:42 ggoebel1111112 joined 14:59 brrt joined 15:00 colomon joined 15:07 dalek joined
brrt \o 15:08
timotimo /o
brrt :-) 15:09
jnthn o/ brrt 15:11
brrt \o jnthn :-)
how was beer yesterday?
jnthn Delicious. The curry too. :) 15:12
brrt :-)
you seem to eat a lot of curry :-) 15:13
i think i can push run_handler into doing the right thing, but i kind of promise it'll be a hack 15:15
nwc10 m: say 5.7454e+01/5.7776e+01; say 5.7454e+01/6.597e+01
camelia rakudo-moar 356d57: OUTPUTĀ«0.994426751592357ā¤0.870911020160679ā¤Ā»
jnthn brrt: Can you outline your overall plan? 15:16
brrt: My thought on it was that a lngjmp back to the interpreter and rely on the enter JIT trampoline to do the right thing...
brrt i can after i get back 15:17
oh, that's possible too, but mine is a bit simpler :-)
basically, run_handler ends one way or the other with MVM_frame_unwind_to
the error is in the goto_offset thingy
which is taken from the bytecode handler, but which should be 0 for the jit handler 15:18
jnthn Yes; that needs to set a jit_entry_label I guess
brrt that's the last part yes
but as i said, it's a bit of a hack
:-)
brrt brb
jnthn k :) 15:19
nwc10 jnthn: optimised build passed. ASAN build now at the setting 15:20
timotimo nwc10: does --dump work for you?
like moar --dump foobar.moarvm?
nwc10 ==29762==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fda28f7b8d4 sp 0x7fffb95388c0 bp 0x7fffb9538bb0 T0) 15:21
that looks like "no"
timotimo oh, wow.
15:22 zakharyas joined 15:51 itz joined 17:06 cognome joined 19:16 brrt joined
dalek arVM/jit-handlers: a1f710d | (Bart Wiegmans)++ | src/core/exceptions. (2 files):
Support some kinds of handlers
 19:38
timotimo "some kind of" %) 19:41
dalek arVM/jit-handlers: d1fd1e5 | (Bart Wiegmans)++ | src/jit/ (5 files):
Generalise throwish control.

Sometimes, the throwish op may throw to the same frame the source. The simplest way of dealing with that by far is letting the interpreter start the JIT code in the right place. But in that case the invokish control guard will not do the right thing, so it has to be replaced by two different guards.		 19:54
brrt is tired today 19:55
now for the real test
does this work
it hath not broken yet 19:56
jnthn :) 19:58
brrt++ # progress
brrt it just worketh 19:59
wtf 20:00
jnthn ooh
brrt i'm not expecting that
jnthn Does this mean we can JIT frames with handlers now? :)
brrt ... yes
jnthn \o/
brrt and apparantly, that hasn't broken anywhere in {nqp, rakudo} testsuites
i'm still not sure if i believe it 20:01
FROGGS *g*
jnthn o.O 20:02
Wow.
jnthn hopes it's really for realz :)
dalek arVM/jit-handlers: 74be8e0 | (Bart Wiegmans)++ | src/jit/emit_ (3 files):
Increase stack space by 32 bytes

This gives us some scratch stack space wherein we can safely stuff temporary values even when we're using stack arguments for C calls.		 20:05
brrt too
29.5 s on stage parse :-D 20:07
btw, anybody any experience on doing a hard reset on a philips tv 20:08
oh, 28.399 s without jit
an old-style, cathode-ray-tube philips tv
i may have locked mine and without a remote, there's no way to unlock it 20:09
jnthn :(
FROGGS how do you lock a tv?
jnthn has no idea
brrt bad luck with button-pressing
jnthn barely watches TV :)
brrt but FROGGS, good question
brrt watches star trek quite a bit
FROGGS brrt: answers.yahoo.com/question/index?q...602AA80Wnu 20:10
(star trek)++
brrt :-) i've found that, but i don't have a remote
FROGGS uhh 20:11
how old school :P
brrt well, all i use it for is the wii, which is also the thing that plays the star trek :-)
FROGGS but you can't switch to AV? 20:13
brrt nope, because lock
FROGGS :/
brrt why does a tv have a lock? i don't know
i can't fathom it
FROGGS back in the days when SCART was popular the tv switched to AV when something star playing a video 20:14
brrt: you can try to pull the power cord for 15min
brrt hmm 20:16
i'll try that
nope still locked 20:17
(i've unplugged the power cord hours ago)
FROGGS ohh
:/
brrt uh oh, broken on windows 20:19
FROGGS hmmm, they also say that you can press the power button on the tv like five seconds, and then it will reboot O.o
but that sounds like it would work for newer devices 20:20
brrt false alarm 20:22
20:22 colomon joined
brrt wtf, windows-in-a-vm is /significantly/ faster than linux-native 20:25
i.e. 24.5s for stage parse
jnthn o.O
MSVC does make a better job of Moar than GCC, it seems.
FROGGS brrt: that also happens on my machine 20:26
brrt but, much false alarm it seems
FROGGS stage parse is faster on my Win7 VM, but compiling a lot of small files takes a lot longer
like when compiling MoarVM
jnthn brrt: False alarm on things working, or on Windows bustage? 20:27
brrt windows bustage
jnthn ah, good
brrt :-)
hmm, i can't directly compare building on windows vs building on linux, since on linux i use -j 4 and that... helps 20:28
but, this works for me, i'm going to merge iin with moar-jit 20:29
tomorrow i think i'll do the inline labels, which should be easy-ish in comparison 20:30
jnthn OK :) 20:31
brrt i should figure out where inline borders are actually used
i think in deopt - but we don't need it there - and in dynvars 20:32
dalek arVM/moar-jit: 2641788 | (Bart Wiegmans)++ | src/core/ (3 files):
Simplify die so it's more JIT-able
 20:34
MoarVM/moar-jit: 1159e41 | (Bart Wiegmans)++ | / (12 files):
MoarVM/moar-jit: WIP on Handler support.
20:35 dalek joined
jnthn I think dynvars are the key place 20:36
Ah, I think I figured out what's up with timotimo's lazy_static_lex_vivify branch 20:37
brrt do tell 20:38
timotimo ah, cool 20:39
jnthn It just went indexing into a table that you need to scan through to get a matchign index.
'cus not all lexicals have a static env entry
brrt i'm off for tonight :-) 20:41
jnthn 'night, brrt++... good luck with your TV!
brrt thanks :-) 'night jnthn++ 20:42
20:42 brrt left
jnthn Grrr....still doesn't work 20:42
(Different kind of breakage, though) 20:44
Well, now it builds and passes NQP tests... 21:16
Rakudo next.
timotimo huh. that seems like something i should have really noticed 21:22
jnthn State vars are a bit specail too 21:28
Anyway, got a working Rakudo that passes sanity test too 21:29
timotimo that's excellent! 21:34
jnthn Not much of a win just yet, though 21:37
21:45 woolfy joined
dalek arVM: 5494549 | jnthn++ | src/ (5 files):
Make static lexical deserialization lazier.

Only deserialize on first usage of a particular lexical now. Cache it so future lookups are fast. Much work in this patch by timotimo++.		 21:45
timotimo jnthn: sorry for causing you so much work for cleaning up after me :S 21:48
21:48 lizmat joined
timotimo especially since i don't really seem to be improving 21:48
jnthn timotimo: Well, it was probably still less work than me coming up with the patch from scratch. :) 22:06
timotimo maybe a bit less 22:07
:P
jnthn We still have lots of things in the way of really avoiding a lot of deserialization.
(At startup)
timotimo aye
jnthn Not least that we associated every code ref with a code object 22:08
Meaning we demand the code objects at startup. All of thme.
timotimo so we may not even need to have separate "loading" of stuff from the setting, just separate deserialization will help a great deal, eh?
jnthn Which in turn means we have to deserialize their Signature and Parameter objects.
Yeah, I think we can get a lot of the win out of deserialization.
timotimo gist.github.com/timo/ba36a47223115...tfile3-txt - that is this beauty, eh?
jnthn yes :) 22:09
As you might imagine, we save some QAST nodes, some MAST nodes, and so forth if we can avoid this.
timotimo we're not even re-using the registers! :)
jnthn Oh?
wtf
timotimo i thought it was due to having Stmt instead of Stmts where we emit this
but when i changed it i was unable to test if it changed, as moarvm blows up during --dump on my machines 22:10
22:18 woolfy joined
jnthn --dump should be fixed now between master and moar-jit, provided the static lexical environment not being lazily deserialized was the only issue 22:27
timotimo i'll check it out 22:28
This is MoarVM version 2014.07-331-g3c39bf8 -> Unhandled exception: SC not yet resolved; lookup failed 22:30
jnthn Did you do a master/moar-jit merge somewhere? 22:31
There's a patch on each side and I think it's only fixed between the two
timotimo i reset --hard to origin/moar-jit 22:35
and built without --enable-jit
jnthn yes, but then you don't have the commit I just did in master 22:37
22:37 woolfy left
jnthn Anyways, heading away for the evening. 'night 22:38
timotimo oh! 22:41
in *master*
okay, gnite!
i obviously misinterpreted "between" in that sentence
now it segfaults instead. let's see about that. 22:42
okay, fully_deserialized == 0 means we need to force deserialization to finish 22:51
ah, MVM_bytecode_finish_frame is what we want 22:54
22:59 avar joined
timotimo hum. MVM_frame_vivify_lexical only operates on a Frame, not a StaticFrame, iiuc 23:01
so iirc frame->static_info is what points to our StaticFrame
i think i'll want to just switch the lexical dumping over to just read directly from the static environment's flags 23:02
that way it could even point out if and what the lexical should be vivified to
oh, this frame_lexicals thing is something the dump code came up with 23:03
and bytecode_finish_frame is what is needed to fill in the lexical_names registry 23:06
okay. i'm not saying i understand fully what happens when exactly, but the code runs again :) 23:08
dalek arVM: bb61ea4 | (Timo Paulssen)++ | src/core/bytecodedump.c:
bytecode dumping has to finish frames before poking around in them
 23:09
timotimo "what happens when", as in which piece of the vivification dance happens when 23:12
and in what order those are valid etc
i was quite shocked when i just saw stage parse at 45 seconds, until i realized i had compiled moar with --optimize=0 23:13
i don't quite see where this code gets generated :\ 23:21
ah, nqp also emits this, so it must be either in moar or nqp, not necessarily in rakudo 23:22
nope. i can't quite find where this code is generated 23:38
well, chasing this "bad code gen" is probably not important; if i understand correctly, this piece will want to be replaced by something "lazy" anyway 23:47

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!