01:45 FROGGS_ joined 02:19 ventica2 joined 05:29 ventica2 joined 05:54 raiph joined 06:14 brrt joined
brrt \o 06:15
sergot hi o/ 06:16
brrt hi sergot :-) 06:23
raiph www.youtube.com/watch?v=DCdGlxBbKU4 # Disruptor, Hardcore Concurrency - Trisha Gee & Mike Barker 06:24
brrt how's things?
raiph hi guys
brrt i'll have you all know i don't have known bugs yet 06:33
sergot hi brrt: how is your gsoc project? :) 06:35
brrt much work yet 06:36
but, we can JIT compiles some regexes
which is awesome
sergot nice :) 06:37
brrt how's your progress doing? last i saw you were adding openssl suppot, which is very nice 06:53
sergot yeah, I write documentation now, tests and then I plan to end up with some cleaning 06:56
So, it's doing well, almost the end.
:)
brrt :-) 07:15
that's a bit further along than i am right now
sergot I have some optional goals I really want to achieve 07:18
07:21 Ven joined
brrt do tell :-) 07:23
sergot e.g. URI stuff, gzip support 07:38
or support for async IO
brrt new bail log: gist.github.com/bdw/5a1f7bbc8e3ec8588a11 07:39
hmm, async io seems like it'd be tricky
how do you handle chunked encoding?
sergot github.com/sergot/http-useragent/b...t.pm6#L110 07:40
dalek Heuristic branch merge: pushed 38 commits to MoarVM/moar-jit by bdw 07:41
nwc10 brrt: is your priority now getting it mergable, or are you still aiming to get more features added? 07:46
brrt both
:-)
nwc10 er, that's not strictly possible
you seem to have got it to the point where others can also contribute 07:47
brrt i want / need to do two things befoe i'm ready to sign it of as mergable
nwc10 and it's certainly better than 90% of the GSoC projects that I'm aware of
brrt thats' extops and throwish / handlers
yes, i'm glad others can actually contribute
nwc10 what subsection of code actually wins most from JIT currently - regular expressions? 07:48
brrt i have no idea really
i think regexes can benefit, even if only because they don't often do 'funky' stuff like throwning etc
timotimo++ implemented a whole bunch of relevant ops
basically a regex is vey often a very tight loop 07:49
nwc10 also, I suspect (not checked this) that they (mostly) compile to only a small set of ops
and they aren't making many method calls
brrt but jnthn++'s work on inlining does a lot of good too
nwc10 mostly string stuff and counting
brrt well, they make some method calls, and i'd like to see those gone
another thing that i reaaally want is to implement a refactor of the pessimized args handling 07:50
i.e. in a lot of cases we get sp_getarg_ stuff, and that runs well, but for a lot of frames that isn't possible yet (it seems)
or rather, it's very easy to make it impossible, and those frames aren't JITtable 07:51
while they might make very hot loops
a final cleanup thingy that i'd like to do is import minilua from luajit in the 3rd party sources, that's basically lua in a single c file, and is compatible with dynasm
nwc10 how many days do you have?
brrt a week until pencils down, two weeks until firm pencils down 07:52
nwc10 also, you can get it into a *mergable* state without merging
brrt that is true
i supose
nwc10 to my mind, that seems safer
get it mergeable
and then just have fun, but keep it mergable
and do the actual merge the day before firm pencils down 07:53
and then party :-)
brrt ok, good point :-)
nwc10 I think that way you still get all the stuff done you could do in the next 2 weeks
but in that order, you ensure that it is mergeable by the end
rather than doing just a bit too much, and missing that
also, merging is not the end 07:54
work on trunk is possible :-)
brrt that is true, as well 07:55
but in a way, i want the JIT to be maximally useful right from day one
nwc10 that's understandable 07:58
brrt :-o it seems that adding getdynlex created even more calls to die 08:04
jnthn morning o/ 08:19
FROGGS_ morning jnthn 08:20
nwc10 jnthn: you survived your curry? :-)
jnthn Yes :)
There's more of it left for today too :)
nwc10 brrt: ASAN builds JIT through to spectests. spectests are in a state of sin. No ASAN errors 08:23
08:40 brrt joined
timotimo brrt: without actually looking at a full jit log, i suspect most getlexdyn are followed by an error message in the case of the dynamic var missing 09:05
brrt yeah, i think that's likely
timotimo paramnamesused probably has a better chance of giving non-die ops :P 09:06
what are your next planned steps? work on handlers and exceptions next? 09:07
brrt that's a big one, yes 09:11
jnthn brrt: On extops... 09:12
brrt what about them
jnthn brrt: I realized we might make things much easier if we make it so we pass the extop a pointer to where it can find its args.
brrt: It will be trivial to do that from the interpreter
brrt aye 09:13
brrt concurs
jnthn brrt: From the JIT, all extops work in terms of just taking registers, so we can trivially allocate a bit of memory while JITting and just include the pointer. :)
As in, it's just a short array
brrt nods
jnthn We can always bail if the extop is more complex than that signature wise but...none are today afaik
brrt are any jumpy / invokish? 09:14
jnthn Yeah
But they're not hot path things, iirc
So we could for now flag them as "don't call from jit"
Well, invokish is OK I guess
One of them does some fooling around with the interp cur_op pointer
Anyway, I don't mind doing the extops refactor this evening 09:16
brrt ok, that'd be awesome
jnthn Which should hopefully make things easier :)
nwc10 jnthn: today is day job?
brrt in that case, i'll move towards throw / handlers
brrt thinks it should make it easier, yes 09:17
jnthn nwc10: yes
I even have to do...paperwork o.O :)
dalek arVM/moar-jit: f16435e | (Bart Wiegmans)++ | src/jit/ (5 files):
Add support for getdynlex
 09:21
arVM/moar-jit: 72f84e0 | (Bart Wiegmans)++ | 3rdparty/dynasm:
Update dynasm to include minilua source
arVM/moar-jit: 7c2d752 | (Bart Wiegmans)++ | / (2 files):
Use minilua for dynasm by default
brrt as in, paper work?
jnthn uh, yes :)
brrt: oh wow, did you just make the build way easier and not require a lua install? :) 09:22
timotimo brrt: does that include the bitops stuff so we have no external dependencies for building new emit code files? 09:24
brrt jnthn: yes, except that it doesn't /quite/ work for windows yet because of @exe@ bs 09:28
timotimo: yes
jnthn
.oO( execute-a-bull )
 09:29
nwc10 jvm spectests are slow
moar++ 09:30
jnthn Moar spectests have got quite a bit snappier over the last week or so too :) 09:31
nwc10 JVM jast stage is slow
numbers (this time) have disspeared deep into scrollback, but it seemed to be of the order of the parse time 09:32
jnthn Wow 09:34
brrt gets stage parse in 30s these days
jnthn brrt: Yes, me too :)
timotimo not jvm's stage parse, though :P
jnthn Whole setting build is under 45s for me these days
Which is still Too Damm High
timotimo that it is
nwc10 jnthn: agree, but I suspect in the short term it doesn't matter as much as general rumtime speedups. The build is fast enough compared with Perl 5 (or anything else) 09:36
jnthn nwc10: Aye, though some of the recent improvements were to the grammar engine, which means we speed up grammars 09:37
User ones too.
nwc10 sorry, should have said what I was thinking "but if they speed up general parsing"
or at least "also speed up user code"
jnthn Ah, I see 09:38
Speeding up compile time is also good for getting to runtime faster
And EVAL :P
dalek arVM/moar-jit: 551b18b | (Bart Wiegmans)++ | Configure.pl:
Make minilua compilation work on windows
timotimo developer turn-around time is also not bad 09:39
jnthn Well, yes. Making Rakudo more pleasant to develop is good.
timotimo moarvm development turn-around time is already excellent 09:40
we can skip right to the setting build if we change something we want to measure
brrt the reason this all had to work right now (instead of next week as i had planned) is that i think i've introduced a regression in win32 sp_findmeth 09:41
jnthn Ah, and you wanted the development environment to be more sane :) 09:42
brrt (i need five arguments for the findmeth_spesh routine, and win32 only supports 4)
in registers
aye
timotimo d'oh
brrt jnthn, any idea on how to make the /pdb:$@.pdb flag in Configure.pl 09:51
jnthn brrt: Last I looked...I didn't see an elegant way 09:52
Maybe we should just not care and hack it in somehow :)
brrt always a good idea
jnthn Oh...
since /pdb:$@.pdb will work anywhere... 09:53
brrt but i don't know how to detect win32-ish-ness in Configure.pl
jnthn ...could we not just add it to the link flags?
For when we're passing /debug?
brrt work anywhere?
jnthn As in, for the .exe too
brrt will gcc accept that?
oh, yeah
i see what you mean
jnthn No, I mean, it doesn't matter if it's in *every* link line we feed MSVC when debugging
Sure we'll get a moar.exe.pdb instead of a moar.pdb but that seems just fine :) 09:54
brrt so it can be inserted into ldflags, is what you mean
jnthn Right
brrt nods
jnthn build/setup.pm:320 is likely the place 09:55
brrt is trying it out as we speak 09:56
dalek arVM/moar-jit: 816a76b | (Bart Wiegmans)++ | build/setup.pm:
Add pdb flag to win32 link flags for debug
 10:00
jnthn \o/ 10:04
brrt afk for a bit 10:11
10:38 cognome joined
nwc10 brrt: ff90a050 "Add sp_findmeth which was big on bail logs" breaks the NQP build 11:12
Too many positional parameters passed; got 2 but expected 1 at gen/moar/stage1/NQPHLL.nqp:2072 (gen/moar/stage1/NQPHLL.moarvm::107) 11:13
etc
this suggests to me that some of the build excercises code paths that none of the regression tests touch
12:12 woolfy1 joined 12:13 FROGGS_ joined 12:15 brrt joined
brrt nwc10: you on windows? 12:30
jnthn Highly doubt it :)
nwc10 no, this was x86_64 Fedora
er, anyway, something in the deadrat familty 12:31
oh
CentOS release 6.4 (Final)
brrt i see that same problem
but only on windows
nwc10 so the compost heap
see, it's "my" machine.
brrt oh, now i see it on linux too 12:32
ok, i'll check it out
nwc10 anything I actually owned would be on something debian derived
probably real debian
12:33 oetiker joined
carlin 100% real debian, not cheap synthetic debian 12:34
12:34 jnap joined
brrt this is another one of the 'this only works if you compile it from fresh' things 12:46
nwc10 11:13 < nwc10> this suggests to me that some of the build excercises code paths that none of the regression tests touch
in this case "works" is fails? Because I was doing a full clean build
12:48 cognome joined
brrt no, i mean, this works if you disable JIT from the start, and which crashes if you /do/ disable JIT from the start 12:49
don't
ught
i.e. undebuggable 12:50
:-(
12:54 cognome joined
brrt all decidedly boring code, by the way 13:01
nwc10 OK, can you back out your change section by section (or go forward section by section) to narrow down the point at which it kills the NQP build? 13:02
jnthn Other tip: look for difference in file size of a working build and a non-working one; may be different. 13:03
Though may be bogus too
brrt yes, it's somewhere in the compilation of NQPHLL that goes wrong 13:04
jnthn That's the first file with a grammar in it, fwiw.
brrt yes, sp_findmeth is called really foten in there 13:05
foten = often 13:06
hmm, it's arround newtype() it seems 13:33
jnthn I'm quite sure new_type can't be jitted 13:34
Givne it's using nqp::newtype 13:35
Which I'm sure we don't JIT yet
But we might JIT the thing calling it of course
FROGGS Do we always have to call it "thing", Jim? 13:38
jnthn Well, there could be a better thingy for it... 13:47
brrt i really have no idea what causes this 13:49
grrr
13:50 raiph joined
brrt let's try and see what ASAN gives us 13:52
nothing! 13:53
yay
jnthn brrt: How did you do sp_findmeth in the end? 13:57
brrt basically, treat it as invokish
i.e., do the spesh-slot index in ASM, and if that fails call MVM_6model_find_method_spesh 13:58
jnthn ok 13:59
brrt hmm 14:00
i have /some/ good news, it seems
it doesn't seem to be a problem with the invokish check or even with the spesh variant 14:01
of find_method
brrt can't hope to find this bug in the current haystack of ops 14:28
new plan 14:32
implement a lot of new ops
wait until ASAN or SEGV gives away what the error is
dalek arVM/moar-jit: 352ce0c | (Bart Wiegmans)++ | src/jit/ (4 files):
Add support for isconcrete
 14:38
timotimo doesn't sound like a terrible idea 14:46
dalek arVM/moar-jit: f8bcded | (Bart Wiegmans)++ | src/jit/ (4 files):
Add support for indexat (is branching)
 14:53
brrt :-)
no luch so far, though
carlin
.oO( No lunch!? )
 14:55
darn human brain, only paying attention to the first and last letter of words 14:56
brrt hmm... a simple script hangs funnily even without JIT 15:13
or doesn
doesn't
jnthn: any idea why this doesn't work: gist.github.com/bdw/44faa4ab88bb14678d64 15:19
you'd think this ends with something running to 100, right? 15:20
not sensitive to JIT or spesh disabling, btw
timotimo how does it fail? 15:22
brrt ehm.. it hangs
or
it used to hang
but 15:23
i'm confused now
because it works
(now)
dalek arVM/moar-jit: 1b461c4 | (Bart Wiegmans)++ | / (5 files):
Add lt_n and gt_n
timotimo huh. 15:24
it ends prematurely on my nqp
brrt yeah, it also ends prematurely on my nqp, except not when i add JITting 15:25
haha confuse!
timotimo huh, yeah, it also ends prematurely with spesh turned off 15:27
this is most strange.
brrt MoarVM used confuse ray 15:30
it's super effective
brrt was hurt in the confusion!
timotimo do you also notice it seems to exit before it prints a newline?
could that just be because it didn't flush stdout?
brrt could be
i don't know
timotimo ah. 15:31
yeah
brrt what's it?
timotimo flush stdout manually and you'll get the correct output
it *does* run correctly.
brrt ... 15:32
timotimo something i find even more interesting is that even strace will end up with truncated output unless -o file.txt
and strace -e write -o log.txt nqp-m foobar.nqp makes foobar.nqp exit with a flushed stdout
good thing you decided to implement more ops before spending five hours chasing this odd behavior 15:33
we may want to force moarvm to flush all open file handles when exiting?
jnthn brrt: Value of $i is 103.982528359203 is last output I get 15:40
15:41 brrt joined
jnthn timotimo: I'm...surprised it's managing to lose output there... 15:41
brrt too 15:42
under JIT, it also runs to completion
timotimo i don't even know if i have a jitted nqp or not
timotimo AFK for a bit
brrt dinner & 15:43
15:43 brrt left 16:07 ventica joined 16:52 colomon joined 16:53 FROGGS[mobile] joined 18:09 brrt joined
brrt core.setting under asan is sloooow 18:20
FROGGS brrt: tell jnthn++, he can make it faster for ya' :o) 18:21
jnthn Hm, seems it's 6time :) 18:22
brrt well, ASAN has the nice property of swiftly telling me why something has crashed :-)
stop!
6time
267 s stage parse under asan
:-o
jnthn wat!
I thought ASAN didn't add so much... :)
brrt well,, sometimes it does
cannot invoke the null object :-o 18:27
we're getting closer it seems
18:30 harrow joined
brrt basically, stuff goes missing 18:30
jnthn That's often a marking fail 18:31
brrt hmm that.. is a bit unlikey i think
it's possible 18:32
but 'brrt did something subtly stupid somewhere' is also really likely 18:33
also, changing the nursery size should change the first appearance of our bug, and it doesn't
jnthn yeah, agree 18:34
(about the nursery size change :P)
dalek arVM/moar-jit: 40a2b51 | (Bart Wiegmans)++ | src/ (6 files):
Add findmeth and findmeth_s.

Program now blows up that much quicker. Which is good, because quicker blowups are much easier to fix.		 18:36
jnthn Aww crap 18:42
The annotations thing gets loads further with spesh disabled
brrt what thing? 18:43
FROGGS ewww
QAST annotations 18:44
github.com/perl6/nqp/blob/master/s...ode.nqp#L6
it let's you use QAST thingies as a hash 18:45
so every QAST::Node (or stuff that inherits from it like QAST::Op) has to keep that hash, even when is only rarely used
jnthn optimize_is_reprid is to blame for the latest spesh bug 18:53
Well, OK, disabling it hides it. 18:57
note note, commetning out these lines hides it: 18:58
result_facts->flags |= MVM_SPESH_FACT_KNOWN_VALUE;
result_facts->value.i64 = 0;
19:01 zakharyas joined
jnthn if (truthvalue != negated_op) { 19:02
hmm, wonder how reliable that is
I mean, there may be ways of representing true other than 1...
dalek arVM/moar-jit: 3257d23 | (Bart Wiegmans)++ | src/jit/ (4 files):
Implement isnull and isnonnull as primitives
 19:07
brrt still no further with bugs, by the way 19:08
19:13 colomon joined
timotimo brrt: if you want you can implement the reprid comparisons as primitive operations 19:14
(islist, isstr, ishash, isint, isnum i believe) 19:15
brrt oh, yes, you're quite right
those ought to be easy
nwc10 brrt: much boom, somewhat faster
gen/moar/stage1/NQPCORE.setting
Cannot invoke null object at gen/moar/stage1/nqpmo.nqp:1459 (gen/moar/stage1/nqpmo.moarvm:new:14)
brrt yeah, i'm trying to speed up that boom
FROGGS that's NQPAttribute.new 19:17
brrt it doesn't seem my implementation of isnonnull is quite working
nwc10 I know it's *not* what you are doing, but it is amusing me because I'm thinking of dave.org.uk/klortho/?n=11912 19:18
which, I thought we had in the perl 5 linux hints (or a commit message), related to the default optimiser settings for Intel's compiler
brrt in a way it is what i'm doing, isn't it? :-)
brrt bbiab
nwc10 yes.
you could just abort early and save a lot of bother :-) 19:19
anyway, ICC is not our favourite compiler: 19:23
perl5.git.perl.org/perl.git/blame/H...nux.sh#l87
a flag to make floating point be correct
another flag, "otherwise, icc pretends (poorly) to be gcc"
Klortho #11912 has been mentioned with reference to the first 19:24
synopsebot Link: rt.perl.org/rt3//Public/Bug/Displa...l?id=11912
jnthn oh, naughty... 19:30
nwc10 whom? me, bitching about their wrong defaults? or them? :-) 19:32
jnthn The optimizer, it turns out 19:33
It was doing a further pass of dead code elimination post-inlining
That may make sense at some point
nwc10 oh, "none of the above" 19:34
jnthn Unfortunately, at present it can lead to it deleting instructions that contain values needed after deopt
Which is a solved problem in general
But seems not in the inline case 19:35
In this case it was deleting the instruction that set the name of the annotation to look for
It'd specialized on the assumption we rarely find it
Uh, actually on the assumption there were no annotations 19:36
Then when there were it deopt'd and had lost the name of the annotation it was after.
Of course, while I'm talking about it as if it has a clue what our data structures mean, it of course doesn't; it's just collecting information about what usually happens and optimizing the case when it does happen :) 19:37
nwc10 bad code, no cookie
20:06 vendethiel joined
dalek arVM: 5d4882c | jnthn++ | src/spesh/optimize.c:
Normalize truth value.

We could come across a case where it will not be 1.		 20:18
arVM: e5370df | jnthn++ | src/spesh/optimize.c:
Don't redo dead instruction elim on inlinees.

For one, they've already had it done. For two, this doesn't quite respect deopt boundaries correctly.
arVM: c440b85 | jnthn++ | src/spesh/inline.c:
Make sure inlined args are always marked as used.
jnthn wonders if timotimo++ will be doing a p6weekly today :) 20:24
FROGGS jnthn: and I thought all your efforts is to impress the YAPC::EU attendees :o) 20:27
nwc10 jnthn: master/master/nom setting build fail 20:40
Stage parse : This type does not support associative operations
at src/Perl6/World.nqp:238 (blib/Perl6/World.moarvm:push_lexpad:44)
from src/Perl6/Grammar.nqp:936 (blib/Perl6/Grammar.moarvm:comp_unit:809)
jnthn nwc10: Yes, you need the Rakudo patch that chases the API change :)
Gee, you folks can test faster than I can push :P
nwc10 I re-checked 20:41
OK, *now* I have it
jnthn OK, that's last night's unfinished stuff done :) 20:46
20:59 ventica joined
nwc10 jnthn: 3 spectests currently fail, but did so 4 hours ago 21:00
timotimo japhb: oh! i was distracted by Crypt of the NecroDancer local co-op mode with a friend :) 21:01
jnthn Is encode.t one of them?
nwc10 IIRC yes
jnthn Seems I can reproduce it here...
nwc10 (now somwhere off in scrollback)
jnthn k 21:02
nwc10 t/spec/S32-io/IO-Socket-Async.rakudo.moar t/spec/S32-str/encode.rakudo.moar t/spec/integration/advent2010-day21.t
Stage mast : 15.608 21:04
that's a lower number than I remember
but my memory may be faulty
in that, "last week" I think it was 17.2 21:05
and parse was 48s, not 44s
but I'm not yet used to "this week"
21:07 brrt joined
lizmat rebuilding settings: real0m50.447s 21:10
user0m49.462s
sys0m0.887s
wow! 21:11
no time to get a cup of tea anymore!
brrt :-o 21:18
what will we do with our lives
apparantly even gt_n and lt_n blow up today :-(
timotimo :( 21:19
brrt something maaay be wrong with not_i 21:22
just a little bit 21:25
jnthn oh no, not not_i! 21:32
lizmat: Hey, my evil plan for increasing Rakudo dev productivity is working :D :P
lizmat yes, it is! 21:33
carlin being too fast to make a cup of tea probably decreases productivity :p
dalek arVM/moar-jit: 678f8c5 | (Bart Wiegmans)++ | src/jit/graph.c:
Temporarily comment all progress of today

We need a good basis to debug from		 21:34
arVM/moar-jit: c45061d | (Bart Wiegmans)++ | / (5 files):
Fix not_i
arVM/moar-jit: 50ca94b | (Bart Wiegmans)++ | src/jit/graph.c:
Indexat and is(non)null are OK
MoarVM: 2be1131 | jnthn++ | src/core/ (2 files):
MoarVM: Change ext op API to make JITting them easier.
MoarVM:
brrt problems with not_i are now past us
FROGGS brrt++
jnthn carlin: There's always spectest for tea ;)
timotimo nice.
jnthn brrt: gah, commit message got truncated but 2be1131 is for you. Rakudo patch tested and coming momentarily. 21:35
brrt i'll merge
jnthn Cool 21:36
dalek arVM/moar-jit: 5d4882c | jnthn++ | src/spesh/optimize.c:
Normalize truth value.

We could come across a case where it will not be 1.
arVM/moar-jit: e5370df | jnthn++ | src/spesh/optimize.c:
Don't redo dead instruction elim on inlinees.

For one, they've already had it done. For two, this doesn't quite respect deopt boundaries correctly.
arVM/moar-jit: c440b85 | jnthn++ | src/spesh/inline.c:
Make sure inlined args are always marked as used.
brrt is afk for tonight, i'll try to work on extops + findmeth bugs 21:40
21:40 brrt left, colomon joined 22:07 ventica joined
timotimo brrt, i'm afraid your // comments may make msvc unhappy 22:29
i think it only allows /* ... */

Powered by Cro and the Raku® Programming Language.

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

Thank you!