Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-01-21

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

All times shown according to UTC.

Time Nick Message
00:17 FROGGS r: say "\c[ARABIC LIGATURE TEH WITH MEEM WITH JEEM INITIAL FORM]".ord.fmt("%#x")
00:17 camelia rakudo-moar 1c37f3: OUTPUT«0xfd5f␤»
00:17 camelia ..rakudo-parrot 1c37f3, rakudo-jvm 1c37f3: OUTPUT«0xfd55␤»
00:18 benabik r: say "\c[ARABIC LIGATURE TEH WITH MEEM WITH JEEM INITIAL FORM]"
00:18 camelia rakudo-parrot 1c37f3, rakudo-jvm 1c37f3: OUTPUT«ﵕ␤»
00:18 camelia ..rakudo-moar 1c37f3: OUTPUT«ﵟ␤»
00:19 FROGGS r: say "\c[ARABIC LIGATURE YEH WITH JEEM INITIAL FORM]".ord.fmt("%#x")
00:19 camelia rakudo-parrot 1c37f3, rakudo-jvm 1c37f3: OUTPUT«0xfcda␤»
00:19 camelia ..rakudo-moar 1c37f3: OUTPUT«0xfce4␤»
00:20 jnthn ARABIC LIGATURE TEH WRONG ON MOAR
00:21 FROGGS the comment in the file is correct though: /*29537*/"ARABIC LIGATURE YEH WITH HAH INITIAL FORM"/* FCDB */,
00:25 benabik Well, the code isn't paying attention to teh comments.
00:25 FROGGS I know
00:25 FROGGS but it makes it a little easier to bisect
00:26 diakopter I was trying to track that down yesterday
00:26 diakopter didn't get very far
00:26 FROGGS yeah
00:27 FROGGS I tried to hunt down a problem with the bitfield and gave up
00:27 FROGGS I thought this might be easier
00:27 diakopter might be nice to enable some kind of super-verbose mode with the .c emission
00:27 diakopter for that bitfield
00:27 FROGGS yeah
00:37 jnthn Hmmm
00:41 jnthn Well, this didn't...quite...go to plan.
00:41 jnthn So we had an algorithmic issue in the GC.
00:41 diakopter oh?
00:42 jnthn Where anything that referenced a frame would end up on the gen2 roots.
00:42 diakopter ok.. :)
00:42 jnthn I've just tried teaching frames to know about generations.
00:43 diakopter I sense an awesome punch line
00:43 jnthn It seems it does actually flatten the growth in time if you lower the full collection rate.
00:43 jnthn But it actually increases the overall runtime
00:44 jnthn It does successfully decrease the amount of time spent processing the gen2 roots list.
00:44 jnthn And chewing through the gen2 frames doesn't seem very costly either
00:44 jnthn Yet somehow we work out slower overall. o.O
00:45 jnthn Could be lexical store barriers...
00:45 jnthn There is one awesome punchline though.
00:46 jnthn In the profiling to work this out, I realized that stage mast spends loads of time inside serialize.
00:46 jnthn Like, a load
00:46 jnthn Because somewhere, there's a very slow lookup algorithm...
00:46 tadzik :)
00:47 jnthn So we can get a sizable win on Stage mast from that.
00:47 jnthn The GC one bothers me a little more, though.
00:47 jnthn Lemme try benchmarking something other than setting compilation...
00:58 jnthn bah, SEGV...
00:58 jnthn So, something's rotten...
00:59 dalek MoarVM/gen2-frames: d04f988 | jnthn++ | src/ (13 files):
00:59 dalek MoarVM/gen2-frames: Bring frames into the generational scheme.
00:59 dalek MoarVM/gen2-frames:
00:59 dalek MoarVM/gen2-frames: In theory, this is a sizable algorithmic improvement by decreasing the
00:59 dalek MoarVM/gen2-frames: number of gen2 roots. In practice, while it does seem to decrease the
00:59 dalek MoarVM/gen2-frames: variability of GC time by how often we do a full collect, it works out
00:59 dalek MoarVM/gen2-frames: a little slower overall.
00:59 dalek MoarVM/gen2-frames: review: https://github.com/MoarVM/MoarVM/commit/d04f988e0c
00:59 jnthn There it is, in the event anybody fancies some analysis...
01:35 dalek MoarVM: 9f235fa | jnthn++ | src/gc/ (4 files):
01:35 dalek MoarVM: Swiftly eliminate gen2 things in nurserly collect.
01:35 dalek MoarVM:
01:35 dalek MoarVM: Before, we put entries onto the worklist and then later chose not to
01:35 dalek MoarVM: visit them. With this, we never put them onto the list at all, which
01:35 dalek MoarVM: keeps the worklist smaller and thus saves work.
01:35 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9f235fa72f
01:36 jnthn That is an actual improvement, and a safe one.
01:36 jnthn 2s more off CORE.setting build time, and spectest time down from 358s to 344s.
01:38 diakopter nice!
01:48 jnthn Time for some rest
01:48 jnthn 'night
01:48 diakopter 'nite
02:24 jnap joined #moarvm
05:26 jnap joined #moarvm
06:27 jnap joined #moarvm
07:46 FROGGS joined #moarvm
07:50 FROGGS diakopter: about the name-to-codepoint mismatch... the first difference is between SQUARE GAL and HEXAGRAM FOR THE CREATIVE HEAVEN
07:50 FROGGS and it almost looks like if the difference between the given codepoint and the actual is the sum of the things in codepoint_extents up to the given codepoint
07:50 FROGGS but sadly the offset for HEXAGRAM FOR THE CREATIVE HEAVEN is ten and the sum of the extents is eight :/
08:00 moritz without knowing anything of the code, could the difference be caused by unassigned/reserved codepoints?
08:04 FROGGS moritz: this could be part of the problem
08:04 FROGGS but we take these holes into account, otherwise the offset would be >1k
08:05 FROGGS and to the worse: the lists get compacted by properties... so it is not that easy to see what is going on
08:10 camelia joined #moarvm
08:12 camelia joined #moarvm
08:21 camelia joined #moarvm
08:29 jnap joined #moarvm
08:31 odc joined #moarvm
09:29 jnap joined #moarvm
10:34 dalek joined #moarvm
11:31 jnap joined #moarvm
12:06 woolfy1 joined #moarvm
12:31 jnap joined #moarvm
13:26 arnsholt joined #moarvm
13:46 [Coke] diakopter: I'm back in from my normal machine, so all is fine.
13:55 jnap joined #moarvm
14:02 [Coke] still a few crashes in spectest.
14:03 [Coke] https://gist.github.com/coke/8250608 (moar crashes)
14:14 [Coke] still some outstanding solaris moarvm patches from andyD.
14:14 jnthn Some, or one?
14:14 * jnthn knows the one
14:14 jnthn I can go back through 'em though
14:24 [Coke] started out with 10 or so, last email talks about a single one.
14:24 [Coke] danger of email based patching.
14:25 jnthn Well, I know we applied a bunh
14:25 jnthn *bunch
14:37 jnap joined #moarvm
14:39 jnap1 joined #moarvm
15:09 dalek MoarVM: 9cd2299 | (Tobias Leich)++ | src/strings/unicode_ops.c:
15:09 dalek MoarVM: a property value code of zero is valid
15:09 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9cd2299477
15:49 benabik joined #moarvm
15:56 woolfy1 left #moarvm
15:59 woolfy joined #moarvm
15:59 woolfy left #moarvm
16:17 diakopter FROGGS: actually we can make 0 be an invalid one if you want
16:20 FROGGS I tried it but it messed something up... but I think it will help us in future
16:21 FROGGS but it is quiet possible that I am fixing right now what upset it before...
16:21 FROGGS made it upset*
16:21 FROGGS or so
16:22 diakopter btw thanks for redoing my braindead-ness :)
16:23 FROGGS ohh, it is quite fun actually
16:24 FROGGS a painful sort of fun, but still :o)
16:25 FROGGS it is nicely done, and that is where I enjoy hacking at it
16:25 diakopter in some ways.
16:25 diakopter in other ways it's poorly done
16:35 FROGGS you can say that about all kind of software
16:52 jnap joined #moarvm
16:55 dalek MoarVM: 71c2ec2 | (Tobias Leich)++ | / (3 files):
16:55 dalek MoarVM: add our very own union <:Assigned>
16:55 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/71c2ec24d2
17:06 cognominal__ joined #moarvm
17:06 benabik_ joined #moarvm
17:18 FROGGS joined #moarvm
17:25 [Coke] today's run: 28296 tests.
17:25 [Coke] s/tests/passes/
17:27 [Coke] m: say "moar probably at { 100*28296/28499 }% of JVM, give or take"
17:27 camelia rakudo-moar 58b1a2: OUTPUT«moar probably at 99.287694% of JVM, give or take␤»
17:27 [Coke] ^^
17:27 timotimo F YEAH :D
17:27 jnthn Whoa!!
17:27 [Coke] not sure if jvm is expected to improve today also.
17:27 timotimo that's what i call ready for release
17:27 timotimo only like 0.3% away from parrot, also
17:35 [Coke] m: say "moar at { 100* 28296/28439}% of parrot today, for sure."
17:35 camelia rakudo-moar 58b1a2: OUTPUT«moar at 99.497169% of parrot today, for sure.␤»
17:36 timotimo that is fantastic
17:47 [Coke] updated http://feather.perl6.nl/~coke/moar.out - S05 still biggest pain point with 257/446 failures.
17:48 [Coke] I'm also still seeing wordcase failure in S32-st/capitalize.t
17:49 diakopter FROGGS: speaking of casing, I still didn't implement the special casing thingies
17:49 diakopter but I did have it emit the data for it
17:49 diakopter just not the lookup logic
17:50 diakopter (one to two and two to one characters upper or lower casings)
17:50 diakopter (or even 3,4,5)
17:53 lizmat joined #moarvm
18:07 FROGGS I try to keep that in mind
18:08 diakopter you know, those crazy German things
18:09 FROGGS yeah, ß <=> SS will hopefully change some day
18:10 diakopter Util: heh typo
18:14 [Coke] BTW, the test we have for that is dubious.
18:54 eternaleye joined #moarvm
19:14 eternaleye joined #moarvm
19:34 dalek MoarVM: b4bfb46 | (Tobias Leich)++ | / (3 files):
19:34 dalek MoarVM: use the same logic for pc that we use for pvc
19:34 dalek MoarVM:
19:34 dalek MoarVM: pc=property code, pvc property value code
19:34 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b4bfb46482
19:51 jnthn .oO( Yeah, use that polyvinyl chloride logic! )
20:12 eternaleye joined #moarvm
20:25 eternaleye joined #moarvm
20:37 eternaleye joined #moarvm
20:48 eternaleye joined #moarvm
20:58 eternaleye joined #moarvm
21:18 eternaleye joined #moarvm
21:34 timotimo does moarvm build a memory-efficient string with the x operator already?
21:34 timotimo like, the same chunk of memory multiple times in the same rope?
21:35 eternaleye joined #moarvm
21:36 timotimo except that's probably not efficient if you have 1 character x'd a bunch of times, because then you have a whole lot of overhead from the pointers
21:37 jnthn FROGGS: Does 01-qregex.t in NQP now fail for you on Moar?
21:37 jnthn -------------------
21:37 jnthn t\qregex/01-qregex.t                (Wstat: 0 Tests: 748 Failed: 3) Failed tests:  428-430 TODO passed:   433-434, 436-440, 442-444
21:37 FROGGS jnthn:  not anymore
21:37 jnthn oh, did I miss a patch?
21:38 jnthn ah, yes...
21:38 * jnthn tries again
21:38 FROGGS this one https://github.com/perl6/nqp/commit/f9e23e6637
21:38 FROGGS need to fudge the test though
21:40 hoelzro FROGGS: I fixed that syntax highlighting bug you found!
21:40 hoelzro thanks for reporting it
21:40 hoelzro er, wrong channle
21:40 FROGGS ohh nice!!
21:40 FROGGS hoelzro++
21:40 hoelzro but whatever =)
21:41 jnthn FROGGS: Now I just get some TODO passed :)
21:41 FROGGS hoelzro: how is the update process btw? do you know that already?
21:41 eternaleye joined #moarvm
21:41 hoelzro FROGGS: for pygments?
21:41 FROGGS jnthn: which is not too bad :o)
21:41 FROGGS hoelzro: yeah
21:42 hoelzro yeah, *their* update process is really easy
21:42 timotimo we wait another 2 years
21:42 hoelzro I had my patch in there within a week, I think
21:42 hoelzro pygments.rb/linguist/GH deployment, on the other hand...
21:42 hoelzro well, you all know how that goes =)
21:42 timotimo well, at least linguist doesn't need to be updated
21:42 hoelzro true
21:42 hoelzro but I updated their language classifier
21:43 hoelzro but those are two separate pipelines, now
21:43 timotimo fair enough
21:43 FROGGS but still awesome to see it properly highlighted!
21:44 hoelzro \o/
21:44 timotimo yes, definitely
21:50 eternaleye joined #moarvm
21:54 dalek MoarVM: 35ee44f | (Tobias Leich)++ | / (3 files):
21:54 dalek MoarVM: every codepoint gets property <:Any>
21:54 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/35ee44fe54
22:11 FROGGS t/spec/S05-mass/named-chars.rakudo.moar ......... Failed 53/431 subtests
22:12 timotimo that's less than before?
22:12 FROGGS this is the only bigger issue left
22:12 FROGGS no, unchanged
22:12 timotimo OK
22:12 FROGGS the lookup but name is borked somehow, as if there are tiny gaps
22:13 FROGGS I spent a few hours yesterday on that topic but without any luck
22:15 jnthn Guess what happens when I add checking we don't pass excess named params?
22:15 jnthn Yeah, that's right, we do in various bits of the QAST -> MAST...
22:15 timotimo that should be fixed then :)
22:15 timotimo since it'd be wrong anyway, no?
22:15 jnthn Right.
22:16 jnthn Curiously, one of the fails involved not passing context along properly..
22:17 jnthn Well into the setting build now, so hopefully we'll be good from here.
22:17 timotimo sounds like that might give a tiny bit of performance improvement, too :)
22:18 jnthn Maybe, though don't see any in settinb build
22:18 timotimo fair enough
22:18 jnthn Ah, darn...
22:18 FROGGS it assploded?
22:20 jnthn aye
22:20 jnthn on setting load
22:20 jnthn oh, maybe my bad though
22:20 FROGGS hehe
22:26 * jnthn spectests and hopes for less fails, not more
22:28 FROGGS m-spectest: 1522.52user 57.10system 6:58.11elapsed 377%CPU (0avgtext+0avgdata 288640maxresident)k
22:29 jnthn 288640 - that's not bad.
22:29 jnthn Comapred to other backends, anyway
22:30 * FROGGS looks at the clogs
22:30 dalek MoarVM: 06c3d8a | jnthn++ | / (8 files):
22:30 dalek MoarVM: Add an op that asserts we've no excess named args.
22:30 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/06c3d8acd4
22:32 FROGGS from jan 18th:
22:32 FROGGS 23:33 moar: 1903.59user 61.68system 8:44.44elapsed 374%CPU (0avgtext+0avgdata 544556maxresident)k
22:32 FROGGS 23:33 parrot 2736.31user 176.74system 13:03.85elapsed 371%CPU (0avgtext+0avgdata 771712maxresident)k
22:32 FROGGS that mem usage dropped a lot!
22:32 timotimo whoa
22:37 jnthn Yeah, well, we leaked every single Int... :)
22:38 jnthn Note that we spectest in almost half the time Parrot does too
22:38 FROGGS jnthn: I "note" that every time :o)
22:39 FROGGS especially right now, since I am spectesting
22:41 jnthn I can't believe we had the mother of all leaks and our maxresident still came out lower...
22:42 timotimo agreed.
23:34 jnthn Hm, the inlining must improve something.
23:35 jnthn Gets me my lowest spectest time yet.
23:35 jnthn (Yes, without regressing stuff. :P)
23:40 benabik joined #moarvm

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