Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-19

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

All times shown according to UTC.

Time Nick Message
00:00 timotimo well, the moarvm.org roadmap says that 2014.08 will see jit compilation as well as further async IO work and turning exception handlers into simple gotos during inlining
00:08 carlin yay, exciting times
01:22 FROGGS_ joined #moarvm
05:28 lizmat joined #moarvm
05:37 lizmat_ joined #moarvm
08:24 FROGGS[mobile] joined #moarvm
09:29 brrt joined #moarvm
09:29 brrt \o
09:30 brrt it's so much too hot here
09:34 brrt taking the nursery size down to 4096 makes moar much slower :-)
09:50 FROGGS[mobile] hehe, of course :o)
09:54 brrt but, it doesn't crash
09:54 brrt so that kind of goes against my 'it crashes because of GC issues' theory
10:16 FROGGS_ yeah, seems like not being gc related...
10:32 brrt that.. is kind of reason for unhappiness
10:33 FROGGS_ I mean, we are just guessing
10:34 brrt i know
10:34 brrt :-)
11:49 cognominal joined #moarvm
11:58 * brrt afk
11:58 brrt left #moarvm
12:20 cognominal joined #moarvm
12:39 jnap joined #moarvm
14:34 colomon joined #moarvm
14:39 dalek MoarVM: 1f4ae9d | (Tobias Leich)++ | src/6model/reprs/NFA. (2 files):
14:39 dalek MoarVM: add charrange handling to the NFA
14:39 dalek MoarVM:
14:39 dalek MoarVM: This wont be used as long as nqp does not use $EDGE_CHARRANGE, so
14:39 dalek MoarVM: this patch on its own should not break anything.
14:39 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1f4ae9ddf7
15:38 timotimo there is a project called "tomsfastmath" that apparently implements most of the stuff libtommath has with a mostly similar API
15:38 timotimo may be interesting to have a look at that at some point
15:38 FROGGS_ ohh true
15:39 timotimo i don't think we have big integer benchmarks yet?
15:39 FROGGS_ btw, I'd like to make a charrange benhmark
15:42 japhb__ timotimo: Interestingly, the rat_harmonic benchmark uses big integers ... inside the big rationals.
15:44 timotimo japhb__: moarvm has a trick where Int objects that fit into 16 bit will be calculated with regular 32bit integers
15:44 timotimo it'd be interesting to see if that gives a noticable corner in the performance graph
15:47 japhb__ timotimo: I think harmonic goes to big denominators so fast you wouldn't be able to see it.
15:48 timotimo ah, ok
15:48 timotimo in that case it might be interesting to have a benchmark that will stay in the 16 bit numbers range for a bit and when you up the scale enough enters the really big integer range
15:49 japhb__ rat_mul_div_cancel keeps the denominator at n+1, so you might be able to see it there.
15:50 japhb__ Problem is, I don't force FatRat (because it can fit in a standard 64-bit-denom Rat, and that's a design feature of Perl 6, so I allow it)
15:50 timotimo it doesn't go high enough before the time runs out :)
15:50 timotimo at least in the benchmark run jnthn has here
15:51 timotimo i'm still astounded we're so much faster than perl5 at rationals (i guess Fat Rats?)
15:52 japhb__ I think this is one of the advantages of big ints and overloaded ops being core to the language, and optimized for.  In perl5, BigInt is an object with overloading, and that invokes a lot of slow paths.
15:55 timotimo interesting
15:55 timotimo and that can't be optimized out?
15:55 japhb In perl5?
15:56 zakharyas joined #moarvm
15:58 timotimo yeah
15:58 japhb If that's what you meant, then I should say that perl5 has a *really* simple optimizer compared to the ones already in the rakudo-moar stack.  It has a peephole optimizer for turning multiple ops that perform a single function into a single op that performs that function with less overhead, and I think there are a few more minor things.  But there's certainly no spesh, no proofs, no escape analysis
15:58 timotimo oh, that's interesting!
15:59 timotimo i thought perl5 had some pretty awesome performance
15:59 japhb nwc10++ can of course correct me if my info is out of date -- I haven't paid much attention to the perl5 core since 5.10 or so.
15:59 timotimo it seems like it'll be a breeze overtaking perl5 in performance :P
16:00 japhb timotimo: Well ... perl5's ops have been optimized over decades, so even though it never left the peephole-optimized optree interpreter paradigm, it's damn good at that.
16:01 japhb And its type system is way more narrow, so it gets some speed from being able to assume a lot about the input types ... actually, to be more accurate, it doesn't need to pessimize as much.
16:01 timotimo ah, ok
16:01 timotimo we're pessimizing lots and lots of things still
16:02 japhb There was a story that was old a decade ago that many people had tried to further optimize Ilya's highly-tuned regex engine, and to a person they had all failed.  I wonder if anyone ever bested him ....
16:02 timotimo jnthn has rightfully complained of the missing communication channels to make lazyness less bad
16:03 japhb Yes, that one is killing us, methinks.
16:03 timotimo not only that
16:03 timotimo but it shows up in lots and lots of places
16:04 japhb nodnodndo
16:04 FROGGS_ I think it was the other way around... eagerness is often slow because of potential lazy lists
16:04 timotimo er
16:04 timotimo that's what i meant; i'm distracted :)
16:05 FROGGS_ timotimo: does it take much effort to setup p6bench?
16:05 japhb FROGGS_: I interpreted timotimo's comment as "make [supporting] lazyness less bad"
16:05 FROGGS_ ahh, yeah
16:05 timotimo very little effort
16:05 FROGGS_ that might need pmichaud++'s input
16:06 japhb FROGGS_: I just added a `bench quickstart` for the truly lazy.  :-)
16:06 FROGGS_ okay, will set it up and add charrange benchmarks
16:06 timotimo yes, i'm looking forward to when pm shows off his work :)
16:06 japhb It will go all the way from setup to comparing historical benchmarks for perl5, nqp-moar, and rakudo-moar.
16:07 FROGGS_ japhb: what is the repo url ooc?
16:07 japhb (Though it's not fully tested, because I didn't have the tuits earlier this week)
16:07 japhb https://github.com/japhb/perl6-bench.git
16:07 FROGGS_ thanks
16:07 japhb no
16:07 japhb problem
16:07 japhb .oO( except my over-eager enter key )
16:09 japhb FROGGS_: As a side note, `bench quickstart` is mostly implemented as calling the other MAIN variants, so the code reads a lot like "the commands people would normally run manually, just wrapped up into one for convenience"
16:10 FROGGS_ nice
16:11 timotimo i wonder at what point we should remove some of the microbenchmarks at the very top?
16:12 japhb FROGGS_: You'll want to add one-liner benchmarks to microbenchmarks.pl and file-sized benchmarks to minibenchmarks.pl with files in perl5/, nqp/, and perl6/.  The .pl files are written in perl5 code, as they are loaded by timeall, which is written in perl5.
16:12 japhb timotimo: You mean the non-scaling ones?
16:12 FROGGS_ k
16:12 lizmat joined #moarvm
16:12 timotimo non-scaling? you mean the ones that just run more iterations?
16:13 japhb timotimo: No, the ones like 'empty', 'zero', and 'hello' that mostly just look for overhead.
16:13 timotimo oh, hm
16:13 japhb (and don't iterate at all)
16:14 japhb I'm just trying to understand what you meant by "microbenchmarks at the very top"
16:14 timotimo ah
16:14 timotimo i just meant from the "bunch at the top"
16:15 japhb 'zero' and 'hello' are variants to check for specific startup issues that we used to have, while 'empty' is actually required for the proper functioning of timeall (it is used as the "absolute base startup time" reference)
16:15 timotimo mhm
16:16 japhb My feeling is that over time we will come up with a set of benchmarks that we consider to be our standard set, we tag them as such, and then just use those for our main benchmarking runs (and I'll canonize that tag in quickstart as well)
16:17 timotimo that sounds good
16:18 FROGGS_ japhb: so bench quickstart will not build parrot stuff?
16:18 japhb FROGGS_: Nah, because when I wrote it I was focused on 2014-era changes.  But it's new code, it's not like we can't change that choice.  :-)
16:19 FROGGS_ japhb: no I mean that's fine :o)
16:19 japhb I didn't want to include jvm by default, for example, because the slow benchmarking runs would drive people to distraction
16:20 japhb And I left parrot out because ... meh.
16:20 FROGGS_ my changes affect perl6-p and perl6-j also, but I expect that they behave equalish
16:21 FROGGS_ for example I wanna see how big a char range must be so that the enumcharlist is slower than charrange
16:21 japhb Well, once you know the commands to use, you can extract, build, and time (there you go, I just gave you the answer ;-) whichever compilers you like.  The quickstart is just to get someone interesting data "out of the box"
16:22 japhb Oh, I should give you a commit bit too.  Are you FROGGS on github as well?
16:23 FROGGS_ yes
16:24 japhb You're added.  :-)
16:25 FROGGS_ thanks :o)
16:26 lizmat joined #moarvm
16:27 japhb FROGGS_: Am I correct in remembering that you have have a Windows dev box available?  (I know that's jnthn's primary platform.)
16:27 woolfy joined #moarvm
16:28 FROGGS_ japhb: I have
16:34 japhb FROGGS_: In that case, patches for "Just Works" Windows compatibility particularly appreciated.  jnthn reported he had to do a couple minor things to the tools I wrote, plus had a bit of trouble with the perl5 builds, but he hasn't pushed any patches yet (presumably because he hadn't yet made them work automatically on both posix-like and windows-like platforms yet)
16:34 FROGGS_ hmmm
16:36 japhb (I was surprised that the perl5 windows builds weren't really easy, since perl5 was ported to windows a LONG time ago.)
16:48 FROGGS_ yes, using strawberry or activeperl
17:00 carlin joined #moarvm
17:11 itz I'm having problems matching working versions of moar-jit, nqp and rakudo
17:11 itz can anyone do a "perl6-m -v"?
17:11 FROGGS_ :/
17:11 FROGGS_ I'm not using moar-jit right now
17:11 itz ok no worries
17:12 timotimo itz: are you able to merge moar-jit into master without conflicts?
17:12 itz I haven't tried that .. but will
17:14 japhb timotimo: Wouldn't he wan't the opposite?
17:14 timotimo it doesn't really matter :)
17:14 timotimo at least not for this case
17:14 japhb nodnod
17:14 itz I got no conflicts
17:14 timotimo great! should work in that case
17:14 timotimo don't forget to --enable-jit in moar's configure
17:15 itz I've made that mistake already :)
17:16 timotimo :)
17:20 itz I still get the same error as before "Stage start      :   0.000
17:20 itz Stage parse      : This type does not support associative operations at src/Perl6/Grammar.nqp:2384  (blib/Perl6/Grammar.moarvm::0)
17:20 timotimo huh o_O
17:27 lizmat joined #moarvm
17:27 woolfy joined #moarvm
17:27 FROGGS_ well, that might be the problem brrt is trying to hunt down
17:28 FROGGS_ i'm not sure how it shows up
17:28 itz nqp passes tests .. its the rakudo build stage
17:51 woolfy joined #moarvm
18:16 woosley joined #moarvm
18:23 woolfy left #moarvm
18:33 carlin joined #moarvm
19:08 woolfy joined #moarvm
19:08 woolfy left #moarvm
19:08 brrt joined #moarvm
19:10 brrt \p
19:10 brrt \o
19:12 FROGGS_ o/
19:14 brrt itz: it's indeed that bug i'm trying to hunt
19:14 brrt as in
19:14 brrt have been staring at for two days, with hardly an idea of the cause
19:15 brrt it would help if i knew how that code worked
19:18 woolfy1 joined #moarvm
19:20 woolfy joined #moarvm
19:21 lizmat joined #moarvm
19:25 woolfy left #moarvm
19:31 itz the answer will probably come unexpected in the shower Monday morning when you have stopped thinking about it!
19:37 brrt that is too late for me :-)
19:37 brrt i want to know it /now/
19:37 brrt :-)
19:38 FROGGS_ can you bisect the problem somehoe?
19:38 FROGGS_ how*
19:38 FROGGS_ by disabling certain jitted things or so?
19:42 brrt well, the thing is, disabling some JITted things disables many others at the same time
19:42 brrt i haven't a specific test for it
19:42 brrt i.e.if i disable atkey_o, atpos_o, then this particular frame isn't run
19:43 brrt but that maybe just masks the problem
19:43 brrt (likely, in fact)
19:44 FROGGS_ hmmm :/
19:44 brrt exactly
19:49 carlin left #moarvm
20:04 masak that's why I prefer to stop thinking about things, and just take showers all the time.
20:04 masak oh, oops, stale backlog :)
20:04 FROGGS_ *g*
20:04 masak it was to itz' comment above.
20:07 brrt :-D
20:30 vendethiel shower-driver development ?
20:31 FROGGS_ I'd like to see an SDD course given by masak :o)
20:32 brrt ahah
20:32 brrt ok, so the object we're comparing with is null, clearly
20:33 brrt (i think i was this far yesterday)
20:34 brrt :-(
20:43 FROGGS_ brrt: is it the same bug as this? https://gist.github.com/FROGGS/be23c4bcdca366a0ddab#file-gdb-bash-L38
20:43 lizmat joined #moarvm
20:44 brrt i have no idea
20:44 brrt it looks sameish
20:44 brrt actually, no
20:44 brrt it looks alike
20:46 FROGGS_ brrt: would it hurt to merge moar master into your branch?
20:47 FROGGS_ I'd like to see your bug when my current spectests have finished
20:53 brrt i thought i had, i'll push
20:54 dalek Heuristic branch merge: pushed 19 commits to MoarVM/moar-jit by bdw
20:55 brrt basically, i'm out of ideas
21:04 brrt what happens in this case is that some value is loaded from wval, which apparantly doesn't support key or positional operations (it really doesn't) and... well, the thing just crashes
21:04 brrt (it appears to me it could be a problem with the way i invoke wval)
21:05 brrt but that seems.. unlikely
21:05 brrt i'm off for tonight
21:05 brrt left #moarvm
21:05 FROGGS_ is it possible that a decont is missing?
21:05 FROGGS_ ohh, gnight then :o)
21:13 FROGGS joined #moarvm
21:30 btyler joined #moarvm
22:51 btyler joined #moarvm
23:57 vendethiel joined #moarvm

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