buggable ??? It's time for the monthly Accidental /win Lottery ??? We have 2 ballots submitted by 2 users! DRUM ROLL PLEASE!... 00:00
And the winning number is 42! Congratulations to Zoffix! You win a roll of duck tape!
00:17 timo joined 00:39 leont joined 01:12 Ven`` joined 01:55 ilbot3 joined 02:49 TimToady joined 03:10 squashable6 joined
AlexDaniel squashable6: status 03:35
squashable6 AlexDaniel, ⚠? Next SQUASHathon in 5 days and ≈6 hours (2017-10-07 UTC-12⌁UTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day
Zoffix Oh awesome! 04:24
Can never have too much ducktape 04:25
06:08 lizmat joined 06:49 domidumont joined
Geth MoarVM: 89ca8eb08e | (Stefan Seifert)++ | src/jit/graph.c
Make "Can't find nc_site value on spesh ins" non-fatal

No idea why, but some times spesh doesn't know the native call site value yet, but still tries to JIT compile the block. Make the error non-fatal as it'd be just a performance optimization.		 06:52
nine I'd really like to know how this ^^^ works
06:54 domidumont joined 08:58 domidumont joined 09:21 Ven`` joined 10:16 evalable6 joined 10:42 japhb joined
MasterDuke jnthn: think it makes sense to try and use the FSA for DecodeStream's buffers? 11:41
jnthn It's not clear that it'd help much; we don't know the size up front 11:48
And we often take the chars buffer and stick it directly into an MVMString 11:49
To avoid copying
Which was important for performance
But in the MVMString we don't store the buffer size, just the string length, and growing every string to store two numbers isn't desirable
So it's hard to relesae those using the FSA 11:50
For the byte buffers, it can make sense, though the longer term plan is that we'll start using MultiDimArray instead of VMArray for blobs coming from I/O, and since those are immutable in terms of size we can avoid the copying entirely of incoming byte buffers, and just keep a reference alive to the array object 11:51
So that leaves the headers that point to the buffers. Those may make sense, though for chars we already keep one of them around and re-use it in common cases 11:52
nine jnthn: do you have any idea about this? github.com/MoarVM/MoarVM/commit/89ca8eb08e 12:05
jnthn nine: 'fraid not
MasterDuke jnthn: thanks. i'll leave the char buffers alone for now and maybe save the byte buffers for later 12:06
nine So it's not something to be expected that I'm just not aware of?
jnthn No, it's odd. I mean, spesh isn't entirely deterministric, but it's an odd thing to go missing
I'd take a look at the spesh log at the stats info 12:07
To see what it logged
That may give some hints as to what's going on
MasterDuke nine: does setting MVM_SPESH_BLOCKING=1 change anything? 12:08
jnthn: speaking of FSA and VMArray...how do github.com/MoarVM/MoarVM/pull/689 and github.com/MoarVM/MoarVM/pull/711 look? 12:10
nine Still there with MVM_SPESH_BLOCKING=1
timotimo that ought to at least make any flopping go away 12:11
jnthn MasterDuke: Don't have time to review them at the moment
Will try next week, though really want to get even-moar-jit review complete first
MasterDuke sure, no hurry, just making sure it isn't forgotten 12:12
timotimo Memcheck: mc_main.c:5831 (vgMemCheck_is_valid_aligned_word): Assertion 'VG_IS_WORD_ALIGNED(a)' failed.
why does it do that, i wonder
lol. searching for vgMemCheck_is_valid_aligned_word on google finds me *drumroll* a match from the moarvm irclog 12:14
nine jnthn: does it make more sense knowing that the native sub got inlined into a caller? 12:18
jnthn nine: Oh 12:26
nine: Yes
nine: We don't re-do facts and stuff in that case yet
The presumption is that the code being inlined was already specialized 12:27
For the case of the caller
So at the moment we do no more than just splice it in
nine Oh, so the native sub is in fact not specialized but will be JIT compiled as part of the caller? 12:28
jnthn Well, it already was specialized 12:29
We inline specializations
timotimo it just forgot the facts in the mean time
jnthn lunch, bbiab
nine Oh, that way around
jnthn: ok, thanks for clearing that up!
So as a solution we'd have to retain the facts for when we inline the code later on? 12:30
timotimo we can mark the ncinvoke op noinline :P 12:32
MasterDuke jnthn, timotimo: any suggestions on an easy optimization for MVM_sc_find_object_idx? github.com/MoarVM/MoarVM/blob/mast...l/sc.c#L90 12:35
perf shows that the second most expensive function when doing `./perl6-m tools/build/install-core-dist.pl /home/dan/Source/perl6/install/share/perl6` 12:36
the largest value for count (in the loop on line 99) is 161211, which occurs 54727 times (the most of any of the values for count)
timotimo oh? interesting! 12:37
how often does it go through to th efor loop?
MasterDuke as opposed to hitting the cache? 12:38
timotimo yeah 12:39
MasterDuke not sure, let me log it 12:40
15344 cached, 62418 not 12:43
timotimo wow
i'm not sure what causes things to get cached 12:44
MasterDuke no idea here 12:45
timotimo i wonder if it's important that the indices have very specific values
i.e. can we sort by pointer value and binary search?
MasterDuke yeah, that's the only thing i could think of without knowing anything about the data 12:48
timotimo i mean, we can still have a sorted list of the pointers and an equivalent list of indices next to it 12:49
12:50 leont joined
MasterDuke timotimo: do you know if sc->body->root_objects ever reaches a steady state? 13:13
timotimo i do not; it probably depends on whether we're currently creating this stuff or have loaded it from disc at one point? 13:15
13:40 evalable6 joined 13:55 zakharyas joined 14:07 MasterDuke_ joined
Geth MoarVM: MasterDuke17++ created pull request #712:
Convert realloc plus memset 0 to recalloc		 17:00
17:18 domidumont joined
Geth MoarVM/fsa_valgrind_error_support: 4f68d71e92 | (Timo Paulssen)++ | src/core/fixedsizealloc.c
FSA size debug: cooperate with valgrind

when the free size is wrong, it gives the stack trace for where the corresponding data was allocated, how many bytes are marked "defined" by valgrind, and of course the current stacktrace. On top of that, it outputs the passed and expected size.		 17:25
MoarVM/fsa_valgrind_error_support: 483b3b8519 | (Timo Paulssen)++ | src/core/fixedsizealloc.c
FSA size debug: cooperate with valgrind

when the free size is wrong, it gives the stack trace for where the corresponding data was allocated, how many bytes are marked "defined" by valgrind, and of course the current stacktrace. On top of that, it outputs the passed and expected size.		 17:33
timotimo had a missing curly brace there
Geth MoarVM: timo++ created pull request #713:
FSA size debug: cooperate with valgrind
samcv releasable6, status 17:42
17:43 zakharyas joined
releasable6 samcv, Next release in 20 days and ≈1 hour. R6 is down. Changelog for this release was not started yet 17:44
samcv, Details: gist.github.com/bda894f10951580ec4...bc64bc1ad5
Zoffix releasable6: status 17:54
Geth MoarVM: usev6++ created pull request #714:
Fix getaddrinfo failing with EAI_HINTS on FreeBSD		 17:55
Zoffix see nothing down with R6 :\ 17:56
17:56 releasable6 joined
samcv good * 17:57
Zoffix \o
18:00 releasable6 joined
samcv Zoffix, so unicode changed some of the annotations for emoji from 4-5, like "man in business suit levitating" to man in suit levitating. so i'm going to have to make sure we use all versions since we started, version 4 18:18
Zoffix knows nothing about Unicode :) 18:19
samcv so you can do "man in business suit levitating: light skin tone" or "man in suit levitating: light skin tone". not sure why they changed it. since the name of the base character is "man in business suit levitating"
Zoffix, well most things are nonchanging, but unicode doesn't purport the emoji sequence names to never change. and so one they changed it slightly. and i want to make sure that we have backward compatibiitiy
since the names could change slightly 18:20
18:31 evalable6 joined 18:32 domidumont joined 19:15 zakharyas joined 19:30 geekosaur joined 20:13 leont joined 20:55 geekosaur joined 20:56 leont joined 21:32 buggable joined 21:43 leont joined 22:03 buggable joined 22:16 buggable joined 22:25 buggable joined 22:26 buggable joined 22:45 arnsholt joined 23:23 evalable6 joined 23:28 nebuchadnezzar 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!