00:27 btyler joined 00:53 timotimo joined, tokuhirom joined 01:00 FROGGS joined 01:03 FROGGS_ joined 01:47 ilbot3 joined 02:18 [Coke] joined 06:00 lizmat joined, woolfy joined 07:41 brrt joined
brrt good moarning 07:41
.tell masak that moarvm actually does this, it's sp_6oget_ and sp_6obind_, and i've implemented the non-vivifying ones in JIT this week :-) 07:50
(wrt to the 'hidden class' paper)
or... isn't that what it's about? 07:51
08:41 woolfy joined, lizmat joined 08:51 lizmat_ joined 09:00 vendethiel joined
jnthn Hm, where on earth is dalek... 11:45
tadzik stuck on the stairs? Or how did that joke go 11:46
jnthn :P
brrt \o jnthn 11:48
jnthn o/ brrt 11:49
brrt how are things
have you had to travel to norway yet?
jnthn Didn't shake off the cold yet
No, I won't have to. 11:50
So I'll be about plenty next week.
brrt :-) well, get well soon
jnthn Will probably take a couple of days of it to do Perl 6 things, in fact. :)
brrt very nice :-)
jnthn Got some meetings on Wednesday; otherwise, I'll be about here quite a lot.
brrt renembers that he should blog, but has been to busy to do so in the last week or so
that is good (for me :-))
hey, ehm, now that i've 'passed' my midterm evaluation, have you any advice for me on how to do better? 11:51
there must be something i can improve :-)
jnthn Well, I wouldn't mind more atomic or descriptive commits... 11:53
97ff5e0d9e for example says it's about getlex, but also happens to add gethow/getwhat/null 11:54
brrt oh, ehm, yes, that is correct :-)
quite frankly, i thought i had commited these before that
i will take care of it :-)
jnthn Well, if you realize soon enough afterwards, rebase -i... :) 11:55
These days, my workflow leading up to a commit often ends up with a git add -p or a git commit -p, giving me a chance to review what I'm comitting and exclude any debugging bits. 11:56
Not saying such a workflow works for everyone, but I've found it fairly helpful.
As another example, I'd probably have done the refactor step in a12a3753f9e as a separate commit to the JIT additions. 11:58
While I'm in review mode: 11:59
github.com/MoarVM/MoarVM/commit/a1...ce5213R191
+ // NB: the next line is only legal because spesh stuff + // is zeroed before it is acquired
Unfortunately, I suspect it's less than legal on big endian...
brrt hmmm 12:00
jnthn Well, or maybe.
I dunno.
brrt i dunno either
:-)
i should check that out
jnthn But the comment is taking up more chars than the conditional that would make the code robust.
Which kinda says it all. :)
brrt yes, that is true
:-)
shame on my evil little endian hackery ways 12:01
jnthn Generally, it's better to write the code a bit more robust in the first place, because debugging such things later is always a real drag. 12:02
brrt true
jnthn grmbl 12:03
.\nqp-m.bat --target=mbc --output=NQPP5QRegex.moarvm gen\moar\stage2\NQPP5QRegex.nqp
Iteration past end of iterator
jnthn wonders how OSR gets this wrong...
FROGGS_ o/ 12:04
brrt \o FROGSS 12:05
in response to your question yesterday night, X bugs make me restart my laptop; also battery-conciousness 12:06
jnthn Ah...d'oh. It moves the deopt annotation onto a PHI... 12:19
And thus re-runs a shift instruction
brrt is working on a blog post explaining the plans of next week 12:27
see you in a bit
FROGGS_ X bugs... gladly don't have them since years now 12:30
timotimo for some reason i don't understand (or maybe for no reason at all) my google-chrome tends to get rendering bugs after some time of use and it doesn't seem like restarting it fixes that 13:40
jnthn Bad news: it appears I forgot to eat lunch. 14:01
Good news: osr now builds NQP and passes tests, also builds Rakudo and passes sanity tests. 14:02
timotimo oh wow! 14:12
14:25 woolfy joined, lizmat joined
jnthn Seems to be doing about the right thing. 14:26
timotimo does it kick in often? :)
jnthn Not that often 14:27
But in benchmarks with outer loops, yes, it seems to
lemme try some rough timings
perl6-m --optimize=3 -e "my $i = 0; while (++$i <= 5000000) { }" 14:28
No spesh at all: 6.37s
Spesh with OSR disabled: 6.07s
Spesh with OSR: 4.55s
timotimo oh, not bad! 14:29
in nqp-land, that loop should also be jitted, eh? 14:30
jnthn I'd guess so
14:30 woolfy joined
jnthn Note that inline isn't yet up to nailing the ++ and <= there 14:30
timotimo in perl6 land, inline nails almost nothing :) 14:31
14:32 vendethiel joined
jnthn Right. 14:33
That's one of the next things on my todo list :)
Anyway, spectest runnign while I go shopping 14:37
vendethiel
.oO( that shop must really be nearby )
 14:39
timotimo :D 14:40
i remmeber the times when that wasn't the case 14:41
vendethiel doesn't, and is happy to have started looking into perl 6 just now, cause he can (and does) play with tons of stuff already 14:50
timotimo hah 14:51
i'm also glad i've joined the community right as very exciting things started happening
vendethiel sorryfor not suffering along with you guys :P. I get to only eat the cake, not bake it
timotimo :) 14:53
vendethiel
.oO( well, I'll get back to writing the recipe now )
 14:54
timotimo the recipe as in "how it was baked" or the recipe as in "how to bake the next one"? :)
vendethiel the best one : how to eat it :D. 14:55
Well, the most important one I'd say :).
timotimo aye, that's a good one :)
i've been meaning to write a turtle graphics style module and build a tutorial for p6 on top of it 14:56
now that we have a gtk3 binding, that isn't going to be terrifyingly hard any more
15:29 JimmyZ joined
jnthn le spectests look good, and we're miles from a release, so I'm going for the merge 15:30
JimmyZ jnthn++ :)
jnthn Done Moar and NQP merges :) 15:33
dalek, dalek, where art thou...
JimmyZ she is tired :P 15:35
timotimo sweet! 15:52
16:04 zakharyas joined 16:52 carlin_ joined
jnthn timotimo: Remember the busted isconcrete optimization we disabled? Turns out it had a really silly bug :) 16:59
I'm spectesting with it fixed and turned on now.
But Spesh + OSR + that working (which in turn kills off the whole bindassert thing, thus why it's a win) gets us down to 4.11s. 17:00
timotimo oh wow 17:01
that's a nice win!
benchmarks are going to look much better now :3
jnthn Well, the bindassert thing not being optimized away is a inline killer.
timotimo i don't even recall what bindassert does :)
jnthn It's the thing that causes us to re-run binding with the slow-path binder to generate a good error message in the case we fail to bind the lowered signature. 17:02
timotimo ah 17:06
17:29 carlin joined
japhb jnthn: The way that src/io/syncsocket.c does socket_connect, will a connect failure result in a leak sometimes, because on the local error path socket, connect, and dest are all freed, but in the on_connect error path, only req (== connect, I think) is freed? Or am I misunderstanding the control flow? 17:58
jnthn japhb: Yeah, and I'm not convinced that throw inside of on_connect is the robustest thing either... 18:08
japhb Given that the status seems to be passed back anyway, should on_connect even *have* an error path? 18:09
jnthn japhb: Well, it's the uv_run(tc->loop, UV_RUN_DEFAULT); that leads to the code path that eventually calls on_connect 18:10
japhb Oh, hmmm. 18:11
jnthn japhb: libuv wants the socket world to be async, Rakudo needs us to provide sync sockets as well, so we basically re-create sync sockets atop of async ones 18:12
Though, hardware does I/O async anyway, so all sync IO is some kind of illusion I guess. :)
japhb Nodnod 18:13
TimToady I had a lot of flakiness getting the Event entry on RC not to segfault, just trying to use DateTime instead of now 18:20
and it's otherwise a real simple entry
jnthn timotimo: link? 18:23
oops
TimToady: link?
TimToady rosettacode.org/wiki/Events#Perl_6 18:24
especially adding another log line after the Channel.new (that also uses DateTime instead of now) 18:25
it seemed somewhat race-conditiony, insofar that it varied in how it dumped, but it usually failed for me 18:26
I think I was using DateTime.now, iirc 18:27
but maybe DateTime.Str
er, .now.Str
or some such
TimToady is guessing refering to something not threadsafe both inside and outside the start 18:28
*ferring
hmm, that doesn't look right either :)
jnthn OK, thanks. Planning to use Monday to look over a bunch of the async/threading robustness things. 18:33
TimToady I'll put up a gist that crashes here 18:35
gist.github.com/anonymous/8f407afdb8cccc1ed09c 18:36
putting an extra log line after the Channel.new makes it work again here 18:37
'course it could be something completely un-event-ful
or something only fails on Linux... 18:38
18:53 carlin joined
timotimo o/ 19:04
jnthn back 19:16
TimToady: Thanks for the gist.
19:33 LLamaRider joined
timotimo i miss dalek 19:59
jnthn Same
jnthn doesn't know where dalek runs or who has admin...maybe ask on #perl6... 20:00
timotimo i'll be interested in seeing how the jit benefits from OSR soon 20:11
jnthn Meanwhile, I got extop inline stuff working enough to try that benchmark from earlier out. 20:42
After the various scalar optimizations from earlier, it stood at around 3.77s. With inlining it's down to 3.02s. 20:44
20:58 LLamaRider joined
jnthn bah, with the extops inline improvements it manages to regress precisely one spectest...by SEGVing it. 21:00
Ah, was a more general issue, uncovered by OSR, but actually dating back to frame handling changes done during inlining. 21:32
TimToady well that's alright then; I prefer it when things are generally bad... 21:37
jnthn Seems it's generally gooder now. :) 21:38
jnthn fires off spectest again.
timotimo i got distracted, but the benchmark results are in, just have to render the .html now 21:51
jnthn Yeah 21:52
Turns out that my machine was loaded down when I posted previous post-inline time 21:53
Now consistently getting it at like 2.7s or so
timotimo actually, i should run the 2014.06 things again 21:54
because otherwise the newer benchmarks would be missin
jnthn I just pushed inlining of extops. 21:56
timotimo oh, m
did you bump the versions?
jnthn Not yet.
timotimo can you tell how often we bail out due to extops when we're doing perl6 code rather than nqp?
i think perl6 code ends up having lots and lots of extops, as all rakudo ops are implemented as extops, eh? 21:57
or was this just about having different sets of extops on both sides of the inlining barrier?
jnthn No, it bailed as soon as it saw an extop
And they're, like, all over
Even infix:<+> used one
Well, uses...
timotimo ah, wow. 21:59
in that case, it should make almost no difference between 2014.06 and OSR-before-extop-inlining, but a bigger one between the latter and the most current one 22:00
i suppose i'll just ignore the timings i made earlier
would be glad if you could push a version bump in the next ~half hour 22:01
hm, but i can --gen-moar=master --gen-nqp=master in rakudo's configure.pl, can't i? 22:02
jnthn timotimo: pushed the version bumps 22:06
timotimo thank you :) 22:07
jnthn We're gradually closing the native gap, but there's work to go yet 22:14
my int $i = 0; while (($i = $i + 1) <= 100000000) {}
2.64s 22:15
my $i = 0; while (++$i <= 100000000) { }
27.82s
wait
47.82s
m: say 47.82 / 2.64 22:16
camelia rakudo-moar 8de0fd: OUTPUT«18.113636␤»
jnthn Quite a factor still.
As a yardstick, in Perl 5
my $i = 0; while (++$i <= 100000000) { }
Takes 3.82s
Or 3.73 with use integer
timotimo wait, that's not nqp 22:17
jnthn m: say 3.73 / 2.64
camelia rakudo-moar 8de0fd: OUTPUT«1.412879␤»
jnthn This is all Rakudo
timotimo neato!
jnthn So, we've 1.4 times faster than Perl 5 on my box if you use native types typere.
*there
m: say 47.82 / 3.82
camelia rakudo-moar 8de0fd: OUTPUT«12.518325␤»
jnthn But the code you'll naively right is 12.5 times faster in Perl 5 still. 22:18
uh, write
TimToady so now it's just a smop to beat p5 :)
jnthn Well, it's interesting to ponder the path to get there.
In part, I there are code-gen improvements to be had. 22:19
*there are
There's JIT to take out the interp overhead.
timotimo huh. rc-self-describing-numbers seems to hang?
i don't think perl6-bench has anything for infinilooping benchmarks
oh, i was wrong 22:20
it did finish
jnthn But none of these deal with the more fundemental issue that ++$i in Perl 5 doesn't have to allocate
TimToady presumably we have enough type info to determine that integers below maxint don't *really* need to call .succ
jnthn While in Perl 6 it's allocating an Int each time.
TimToady: It doesn't actually call .succ at all
TimToady *whew* 22:21
jnthn TimToady: The bounds check is also a drop in the ocean at this point.
TimToady we oughta be able to figure out that it can use the same Int
timotimo so the allocation of the Int is harder; can we sp_fastcreate it at least?
TimToady: sounds like something escape analysis could enable
TimToady er, int container anyway
jnthn TimToady: Yes, that's escape analysis. It's quite hard. 22:22
But yes, that and the JITter are our sources of big improvements on this from here.
TimToady is very happy to see the progress we've *cough* you've been making 22:23
language designers who wave their hands and say "with a good enough optimizer" are either geniuses or idiots, depending on who is helping them :) 22:24
TimToady feels like a genius today :) 22:25
22:25 colomon_ joined
timotimo %) 22:29
jnthn timotimo: How long until pretty graphs? ;) 22:33
timotimo 15 minutes perhaps?
building the very newest nqp and rakudo right now
perl5, rakudo/nqp and 2014.06 are build
and timed, of course 22:34
jnthn cool 22:35
jnthn is running "my $i = 0; while (++$i <= 100000000) { }" on R* (Rakudo Parrot) from 2014.03, which was conveniently available in an MSI 22:36
Just to get a feel for the progress
timotimo i'd like to know, too :)
jnthn It's taking a while... 22:39
timotimo oh, yikes
but while loops themselves weren't optimized recently, were they?
jnthn Rakudo's optimizer learned to take a lot of the cruft out of the basic ops
timotimo OK 22:40
jnthn Loop code-gen did improve for Moar in the last few months too
timotimo fair enough
jnthn But some of the opts were Rakduo optimizer level and influence all backends.
timotimo i like those :) 22:41
did you notice something being off with stage parse? 22:44
it seems to be taking quite a lot longer than i'm used to 22:45
jnthn It's looked fairly normal to me
timotimo well, the ssh connection aint dead
jnthn checks his most recent build 22:46
Yeah...
It's seen it lower, but I think more stuffs ended up in the setting.
timotimo well, this has been going for more than a minute now 22:47
it's apparently also not consuming any cpu time ... ?!
jnthn o.O
22:47 tgt joined
timotimo is retrying 22:48
jnthn I just wonder...
oh you're kidding
jnthn--
I think it'll have deadlocked on itself.
timotimo oops :(
jnthn Yeah, braindead copy pasto on my part. Sorry. 22:49
timotimo oke :)
jnthn oh, the Parrot run finished
1246.44s
timotimo here we lock, afterwards we lock. should work, right?
jnthn On windows, mutexes are reenterant natively so I didn't notice the issue. pthreads ones ain't.
timotimo ouch :)
yes
FFTF
jnthn Pushed fix 22:50
will bump
timotimo thanks
jnthn otherwise everybody has a borked HEAD
thanks for reporting
timotimo YW of course :) 22:51
jnthn Pushed version bumps to NQP and Rakudo now. 22:52
timotimo: BTW, there are two new envvars you may like to know about
timotimo i saw them :)
jnthn OK, cool
timotimo cool indeed
f1fd505 ← a cute commit short-id 22:53
jnthn SOS indeed :P
m: say 1246.44 / 47.82 22:56
camelia rakudo-moar 8de0fd: OUTPUT«26.065245␤»
22:56 LLamaRider joined
timotimo i'm in the benchmarks section now 22:59
oh, wow.
23:00 raiph joined
[Coke] src/core/interp.c:4187:17: warning: implicit declaration of function 'MVM_io_eventloop_cancel_work' is invalid in C99 23:18
timotimo huh. 23:19
jnthn hmm
[Coke]: ah, I see the prob... 23:20
[Coke]: Patched, thanks. 23:21
[Coke] jnthn: I will continue to post random moarvm build warnings as they happen to scroll by in future builds, then. :) 23:26
jnthn [Coke]: Well, they may not all be that easy. But that one was. :) 23:30

Powered by Cro and the Raku® Programming Language.

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

Thank you!