FROGGS r: say "\c[ARABIC LIGATURE TEH WITH MEEM WITH JEEM INITIAL FORM]".ord.fmt("%#x") 00:17
camelia rakudo-moar 1c37f3: OUTPUT«0xfd5f␤»
..rakudo-parrot 1c37f3, rakudo-jvm 1c37f3: OUTPUT«0xfd55␤»
benabik r: say "\c[ARABIC LIGATURE TEH WITH MEEM WITH JEEM INITIAL FORM]" 00:18
camelia rakudo-parrot 1c37f3, rakudo-jvm 1c37f3: OUTPUT«ﵕ␤»
..rakudo-moar 1c37f3: OUTPUT«ﵟ␤»
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␤»
..rakudo-moar 1c37f3: OUTPUT«0xfce4␤»
jnthn ARABIC LIGATURE TEH WRONG ON MOAR 00:20
FROGGS the comment in the file is correct though: /*29537*/"ARABIC LIGATURE YEH WITH HAH INITIAL FORM"/* FCDB */, 00:21
benabik Well, the code isn't paying attention to teh comments. 00:25
FROGGS I know
but it makes it a little easier to bisect
diakopter I was trying to track that down yesterday 00:26
didn't get very far
FROGGS yeah
I tried to hunt down a problem with the bitfield and gave up 00:27
I thought this might be easier
diakopter might be nice to enable some kind of super-verbose mode with the .c emission
for that bitfield
FROGGS yeah
jnthn Hmmm 00:37
Well, this didn't...quite...go to plan. 00:41
So we had an algorithmic issue in the GC.
diakopter oh?
jnthn Where anything that referenced a frame would end up on the gen2 roots. 00:42
diakopter ok.. :)
jnthn I've just tried teaching frames to know about generations.
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.
But it actually increases the overall runtime
It does successfully decrease the amount of time spent processing the gen2 roots list. 00:44
And chewing through the gen2 frames doesn't seem very costly either
Yet somehow we work out slower overall. o.O
Could be lexical store barriers... 00:45
There is one awesome punchline though.
In the profiling to work this out, I realized that stage mast spends loads of time inside serialize. 00:46
Like, a load
Because somewhere, there's a very slow lookup algorithm...
tadzik :)
jnthn So we can get a sizable win on Stage mast from that. 00:47
The GC one bothers me a little more, though.
Lemme try benchmarking something other than setting compilation...
bah, SEGV... 00:58
So, something's rotten...
dalek arVM/gen2-frames: d04f988 | jnthn++ | src/ (13 files):
Bring frames into the generational scheme.

In theory, this is a sizable algorithmic improvement by decreasing the number of gen2 roots. In practice, while it does seem to decrease the variability of GC time by how often we do a full collect, it works out a little slower overall.		 00:59
jnthn There it is, in the event anybody fancies some analysis...
dalek arVM: 9f235fa | jnthn++ | src/gc/ (4 files):
Swiftly eliminate gen2 things in nurserly collect.

Before, we put entries onto the worklist and then later chose not to visit them. With this, we never put them onto the list at all, which keeps the worklist smaller and thus saves work.		 01:35
jnthn That is an actual improvement, and a safe one. 01:36
2s more off CORE.setting build time, and spectest time down from 358s to 344s.
diakopter nice! 01:38
jnthn Time for some rest 01:48
'night
diakopter 'nite
02:24 jnap joined 05:26 jnap joined 06:27 jnap joined 07:46 FROGGS joined
FROGGS diakopter: about the name-to-codepoint mismatch... the first difference is between SQUARE GAL and HEXAGRAM FOR THE CREATIVE HEAVEN 07:50
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
but sadly the offset for HEXAGRAM FOR THE CREATIVE HEAVEN is ten and the sum of the extents is eight :/
moritz without knowing anything of the code, could the difference be caused by unassigned/reserved codepoints? 08:00
FROGGS moritz: this could be part of the problem 08:04
but we take these holes into account, otherwise the offset would be >1k
and to the worse: the lists get compacted by properties... so it is not that easy to see what is going on 08:05
08:10 camelia joined 08:12 camelia joined 08:21 camelia joined 08:29 jnap joined 08:31 odc joined 09:29 jnap joined 10:34 dalek joined 11:31 jnap joined 12:06 woolfy1 joined 12:31 jnap joined 13:26 arnsholt joined
[Coke] diakopter: I'm back in from my normal machine, so all is fine. 13:46
13:55 jnap joined
[Coke] still a few crashes in spectest. 14:02
gist.github.com/coke/8250608 (moar crashes) 14:03
still some outstanding solaris moarvm patches from andyD. 14:14
jnthn Some, or one?
jnthn knows the one
I can go back through 'em though
[Coke] started out with 10 or so, last email talks about a single one. 14:24
danger of email based patching.
jnthn Well, I know we applied a bunh 14:25
*bunch
14:37 jnap joined 14:39 jnap1 joined
dalek arVM: 9cd2299 | (Tobias Leich)++ | src/strings/unicode_ops.c:
a property value code of zero is valid
 15:09
15:49 benabik joined 15:56 woolfy1 left 15:59 woolfy joined, woolfy left
diakopter FROGGS: actually we can make 0 be an invalid one if you want 16:17
FROGGS I tried it but it messed something up... but I think it will help us in future 16:20
but it is quiet possible that I am fixing right now what upset it before... 16:21
made it upset*
or so
diakopter btw thanks for redoing my braindead-ness :) 16:22
FROGGS ohh, it is quite fun actually 16:23
a painful sort of fun, but still :o) 16:24
it is nicely done, and that is where I enjoy hacking at it 16:25
diakopter in some ways.
in other ways it's poorly done
FROGGS you can say that about all kind of software 16:35
16:52 jnap joined
dalek arVM: 71c2ec2 | (Tobias Leich)++ | / (3 files):
add our very own union <:Assigned>
 16:55
17:06 cognominal__ joined, benabik_ joined 17:18 FROGGS joined
[Coke] today's run: 28296 tests. 17:25
s/tests/passes/
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␤»
[Coke] ^^
timotimo F YEAH :D
jnthn Whoa!!
[Coke] not sure if jvm is expected to improve today also.
timotimo that's what i call ready for release
only like 0.3% away from parrot, also
[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.␤»
timotimo that is fantastic 17:36
[Coke] updated feather.perl6.nl/~coke/moar.out - S05 still biggest pain point with 257/446 failures. 17:47
I'm also still seeing wordcase failure in S32-st/capitalize.t 17:48
diakopter FROGGS: speaking of casing, I still didn't implement the special casing thingies 17:49
but I did have it emit the data for it
just not the lookup logic
(one to two and two to one characters upper or lower casings) 17:50
(or even 3,4,5)
17:53 lizmat joined
FROGGS I try to keep that in mind 18:07
diakopter you know, those crazy German things 18:08
FROGGS yeah, ß <=> SS will hopefully change some day 18:09
diakopter Util: heh typo 18:10
[Coke] BTW, the test we have for that is dubious. 18:14
18:54 eternaleye joined 19:14 eternaleye joined
dalek arVM: b4bfb46 | (Tobias Leich)++ | / (3 files):
use the same logic for pc that we use for pvc

pc=property code, pvc property value code		 19:34
jnthn
.oO( Yeah, use that polyvinyl chloride logic! )
 19:51
20:12 eternaleye joined 20:25 eternaleye joined 20:37 eternaleye joined 20:48 eternaleye joined 20:58 eternaleye joined 21:18 eternaleye joined
timotimo does moarvm build a memory-efficient string with the x operator already? 21:34
like, the same chunk of memory multiple times in the same rope?
21:35 eternaleye joined
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:36
jnthn FROGGS: Does 01-qregex.t in NQP now fail for you on Moar? 21:37
-------------------
t\qregex/01-qregex.t (Wstat: 0 Tests: 748 Failed: 3) Failed tests: 428-430 TODO passed: 433-434, 436-440, 442-444
FROGGS jnthn: not anymore
jnthn oh, did I miss a patch?
ah, yes... 21:38
jnthn tries again
FROGGS this one github.com/perl6/nqp/commit/f9e23e6637
need to fudge the test though
hoelzro FROGGS: I fixed that syntax highlighting bug you found! 21:40
thanks for reporting it
er, wrong channle
FROGGS ohh nice!!
hoelzro++
hoelzro but whatever =)
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
hoelzro FROGGS: for pygments? 21:41
FROGGS jnthn: which is not too bad :o)
hoelzro: yeah
hoelzro yeah, *their* update process is really easy 21:42
timotimo we wait another 2 years
hoelzro I had my patch in there within a week, I think
pygments.rb/linguist/GH deployment, on the other hand...
well, you all know how that goes =)
timotimo well, at least linguist doesn't need to be updated
hoelzro true
but I updated their language classifier
but those are two separate pipelines, now 21:43
timotimo fair enough
FROGGS but still awesome to see it properly highlighted!
hoelzro \o/ 21:44
timotimo yes, definitely
21:50 eternaleye joined
dalek arVM: 35ee44f | (Tobias Leich)++ | / (3 files):
every codepoint gets property <:Any>
 21:54
FROGGS t/spec/S05-mass/named-chars.rakudo.moar ......... Failed 53/431 subtests 22:11
timotimo that's less than before? 22:12
FROGGS this is the only bigger issue left
no, unchanged
timotimo OK
FROGGS the lookup but name is borked somehow, as if there are tiny gaps
I spent a few hours yesterday on that topic but without any luck 22:13
jnthn Guess what happens when I add checking we don't pass excess named params? 22:15
Yeah, that's right, we do in various bits of the QAST -> MAST...
timotimo that should be fixed then :)
since it'd be wrong anyway, no?
jnthn Right.
Curiously, one of the fails involved not passing context along properly.. 22:16
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 :)
jnthn Maybe, though don't see any in settinb build 22:18
timotimo fair enough
jnthn Ah, darn...
FROGGS it assploded?
jnthn aye 22:20
on setting load
oh, maybe my bad though
FROGGS hehe
jnthn spectests and hopes for less fails, not more 22:26
FROGGS m-spectest: 1522.52user 57.10system 6:58.11elapsed 377%CPU (0avgtext+0avgdata 288640maxresident)k 22:28
jnthn 288640 - that's not bad. 22:29
Comapred to other backends, anyway
FROGGS looks at the clogs 22:30
dalek arVM: 06c3d8a | jnthn++ | / (8 files):
Add an op that asserts we've no excess named args.
FROGGS from jan 18th: 22:32
23:33 moar: 1903.59user 61.68system 8:44.44elapsed 374%CPU (0avgtext+0avgdata 544556maxresident)k
23:33 parrot 2736.31user 176.74system 13:03.85elapsed 371%CPU (0avgtext+0avgdata 771712maxresident)k
that mem usage dropped a lot!
timotimo whoa
jnthn Yeah, well, we leaked every single Int... :) 22:37
Note that we spectest in almost half the time Parrot does too 22:38
FROGGS jnthn: I "note" that every time :o)
especially right now, since I am spectesting 22:39
jnthn I can't believe we had the mother of all leaks and our maxresident still came out lower... 22:41
timotimo agreed. 22:42
jnthn Hm, the inlining must improve something. 23:34
Gets me my lowest spectest time yet. 23:35
(Yes, without regressing stuff. :P)
23:40 benabik 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!