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:00
carlin yay, exciting times 00:08
01:22 FROGGS_ joined 05:28 lizmat joined 05:37 lizmat_ joined 08:24 FROGGS[mobile] joined 09:29 brrt joined
brrt \o 09:29
it's so much too hot here 09:30
taking the nursery size down to 4096 makes moar much slower :-) 09:34
FROGGS[mobile] hehe, of course :o) 09:50
brrt but, it doesn't crash 09:54
so that kind of goes against my 'it crashes because of GC issues' theory
FROGGS_ yeah, seems like not being gc related... 10:16
brrt that.. is kind of reason for unhappiness 10:32
FROGGS_ I mean, we are just guessing 10:33
brrt i know 10:34
:-)
11:49 cognominal joined
brrt afk 11:58
11:58 brrt left 12:20 cognominal joined 12:39 jnap joined 14:34 colomon joined
dalek arVM: 1f4ae9d | (Tobias Leich)++ | src/6model/reprs/NFA. (2 files):
add charrange handling to the NFA

This wont be used as long as nqp does not use $EDGE_CHARRANGE, so this patch on its own should not break anything.		 14:39
timotimo there is a project called "tomsfastmath" that apparently implements most of the stuff libtommath has with a mostly similar API 15:38
may be interesting to have a look at that at some point
FROGGS_ ohh true
timotimo i don't think we have big integer benchmarks yet? 15:39
FROGGS_ btw, I'd like to make a charrange benhmark
japhb__ timotimo: Interestingly, the rat_harmonic benchmark uses big integers ... inside the big rationals. 15:42
timotimo japhb__: moarvm has a trick where Int objects that fit into 16 bit will be calculated with regular 32bit integers 15:44
it'd be interesting to see if that gives a noticable corner in the performance graph
japhb__ timotimo: I think harmonic goes to big denominators so fast you wouldn't be able to see it. 15:47
timotimo ah, ok 15:48
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
japhb__ rat_mul_div_cancel keeps the denominator at n+1, so you might be able to see it there. 15:49
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 :)
at least in the benchmark run jnthn has here
i'm still astounded we're so much faster than perl5 at rationals (i guess Fat Rats?) 15:51
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:52
timotimo interesting 15:55
and that can't be optimized out?
japhb In perl5?
15:56 zakharyas joined
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
timotimo oh, that's interesting!
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.
timotimo it seems like it'll be a breeze overtaking perl5 in performance :P
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:00
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
we're pessimizing lots and lots of things still
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
japhb Yes, that one is killing us, methinks. 16:03
timotimo not only that
but it shows up in lots and lots of places
japhb nodnodndo 16:04
FROGGS_ I think it was the other way around... eagerness is often slow because of potential lazy lists
timotimo er
that's what i meant; i'm distracted :)
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"
FROGGS_ ahh, yeah
timotimo very little effort
FROGGS_ that might need pmichaud++'s input
japhb FROGGS_: I just added a `bench quickstart` for the truly lazy. :-) 16:06
FROGGS_ okay, will set it up and add charrange benchmarks
timotimo yes, i'm looking forward to when pm shows off his work :)
japhb It will go all the way from setup to comparing historical benchmarks for perl5, nqp-moar, and rakudo-moar.
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)
github.com/japhb/perl6-bench.git
FROGGS_ thanks
japhb no
problem
.oO( except my over-eager enter key )
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:09
FROGGS_ nice 16:10
timotimo i wonder at what point we should remove some of the microbenchmarks at the very top? 16:11
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
timotimo: You mean the non-scaling ones?
FROGGS_ k
16:12 lizmat joined
timotimo non-scaling? you mean the ones that just run more iterations? 16:12
japhb timotimo: No, the ones like 'empty', 'zero', and 'hello' that mostly just look for overhead. 16:13
timotimo oh, hm
japhb (and don't iterate at all)
I'm just trying to understand what you meant by "microbenchmarks at the very top" 16:14
timotimo ah
i just meant from the "bunch at the top"
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
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:16
timotimo that sounds good 16:17
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. :-)
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
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
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"
Oh, I should give you a commit bit too. Are you FROGGS on github as well? 16:22
FROGGS_ yes 16:23
japhb You're added. :-) 16:24
FROGGS_ thanks :o) 16:25
16:26 lizmat joined
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
16:27 woolfy joined
FROGGS_ japhb: I have 16:28
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
japhb (I was surprised that the perl5 windows builds weren't really easy, since perl5 was ported to windows a LONG time ago.) 16:36
FROGGS_ yes, using strawberry or activeperl 16:48
17:00 carlin joined
itz I'm having problems matching working versions of moar-jit, nqp and rakudo 17:11
can anyone do a "perl6-m -v"?
FROGGS_ :/
I'm not using moar-jit right now
itz ok no worries
timotimo itz: are you able to merge moar-jit into master without conflicts? 17:12
itz I haven't tried that .. but will
japhb timotimo: Wouldn't he wan't the opposite? 17:14
timotimo it doesn't really matter :)
at least not for this case
japhb nodnod
itz I got no conflicts
timotimo great! should work in that case
don't forget to --enable-jit in moar's configure
itz I've made that mistake already :) 17:15
timotimo :) 17:16
itz I still get the same error as before "Stage start : 0.000 17:20
Stage parse : This type does not support associative operations at src/Perl6/Grammar.nqp:2384 (blib/Perl6/Grammar.moarvm::0)
timotimo huh o_O
17:27 lizmat joined, woolfy joined
FROGGS_ well, that might be the problem brrt is trying to hunt down 17:27
i'm not sure how it shows up 17:28
itz nqp passes tests .. its the rakudo build stage
17:51 woolfy joined 18:16 woosley joined 18:23 woolfy left 18:33 carlin joined 19:08 woolfy joined, woolfy left, brrt joined
brrt \p 19:10
\o
FROGGS_ o/ 19:12
brrt itz: it's indeed that bug i'm trying to hunt 19:14
as in
have been staring at for two days, with hardly an idea of the cause
it would help if i knew how that code worked 19:15
19:18 woolfy1 joined 19:20 woolfy joined 19:21 lizmat joined 19:25 woolfy left
itz the answer will probably come unexpected in the shower Monday morning when you have stopped thinking about it! 19:31
brrt that is too late for me :-) 19:37
i want to know it /now/
:-)
FROGGS_ can you bisect the problem somehoe? 19:38
how*
by disabling certain jitted things or so?
brrt well, the thing is, disabling some JITted things disables many others at the same time 19:42
i haven't a specific test for it
i.e.if i disable atkey_o, atpos_o, then this particular frame isn't run
but that maybe just masks the problem 19:43
(likely, in fact)
FROGGS_ hmmm :/ 19:44
brrt exactly
19:49 carlin left
masak that's why I prefer to stop thinking about things, and just take showers all the time. 20:04
oh, oops, stale backlog :)
FROGGS_ *g*
masak it was to itz' comment above.
brrt :-D 20:07
vendethiel shower-driver development ? 20:30
FROGGS_ I'd like to see an SDD course given by masak :o) 20:31
brrt ahah 20:32
ok, so the object we're comparing with is null, clearly
(i think i was this far yesterday) 20:33
:-( 20:34
FROGGS_ brrt: is it the same bug as this? gist.github.com/FROGGS/be23c4bcdca...b-bash-L38 20:43
20:43 lizmat joined
brrt i have no idea 20:44
it looks sameish
actually, no
it looks alike
FROGGS_ brrt: would it hurt to merge moar master into your branch? 20:46
I'd like to see your bug when my current spectests have finished 20:47
brrt i thought i had, i'll push 20:53
dalek Heuristic branch merge: pushed 19 commits to MoarVM/moar-jit by bdw 20:54
brrt basically, i'm out of ideas 20:55
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
(it appears to me it could be a problem with the way i invoke wval)
but that seems.. unlikely 21:05
i'm off for tonight
21:05 brrt left
FROGGS_ is it possible that a decont is missing? 21:05
ohh, gnight then :o)
21:13 FROGGS joined 21:30 btyler joined 22:51 btyler joined 23:57 vendethiel joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!