github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 6 May 2018.
00:17 statisfiable6 joined
MasterDuke should the gc_seq_number ever be -1 (if there haven't been enough GCs for it to wrap around)? 01:43
01:56 ilbot3 joined
moderator github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
02:45 Kaypie joined 03:25 nativecallable6 joined 05:38 zakharyas joined 06:21 nwc10 joined 06:33 quotable6 joined 06:52 domidumont joined 06:59 domidumont joined 07:03 robertle joined 07:57 jsimonet joined 08:13 zakharyas joined 09:22 zakharyas joined
Geth MoarVM: samcv++ created pull request #855:
Implement a optimized memmem 32 bit search 4-15x faster
10:07
10:19 domidumont joined
timotimo MasterDuke: can you give me the script that gives you the 0 vs 1 discrepancy? 10:35
Geth MoarVM: a519028373 | (Timo Paulssen)++ | src/profiler/instrument.c
commit a missing break statement
10:45
MoarVM: a91b3d465a | (Timo Paulssen)++ | src/profiler/instrument.c
insert prof_allocated in the exact right place

must be after all PHIs, but since insert_ins puts the instruction after the one given in the arguments, we have to take a step back first.
MoarVM: 37d5b9850d | (Samantha McVey)++ | src/strings/ops.c
Factor out the memmem wrapper for searching Grapheme32 blobs

Also rename some variables in MVM_string_char_at_in_string to make it more clear what the haystack is.
10:46
MoarVM: e71ba73815 | (Samantha McVey)++ | 4 files
Implement a optimized memmem 32 bit search 4-15x faster

This is a modification of the memmem used in FreeBSD to allow us to quickly search 32 bit strings. This is much more efficient than searching by byte since we can skip every 4 bytes instead of every 1 byte, as well as the fact that in a 32 bit integer, some of the bytes will be empty, making it even less efficient. ... (6 more lines)
MoarVM: 6e2b54c7d1 | (Samantha McVey)++ (committed using GitHub Web editor) | 4 files
Merge pull request #855 from samcv/changes

Implement a optimized memmem 32 bit search 4-15x faster
11:06 travis-ci joined
travis-ci MoarVM build failed. Timo Paulssen 'insert prof_allocated in the exact right place 11:06
travis-ci.org/MoarVM/MoarVM/builds/375831423 github.com/MoarVM/MoarVM/compare/8...1b3d465afb
11:06 travis-ci left
Geth MoarVM: eefd9a4362 | (Timo Paulssen)++ | src/profiler/instrument.c
fix off-by-one in profile's GC dumping
12:02
samcv timotimo: wondering if you can take a quick look at this code github.com/samcv/MoarVM/commit/f8f...a7a9bc5R50 12:27
almost certain it's right and all tests pass. but i'm pretty sure i'm ok casting and reading the blob as 64 bit integers moving 32 bits down at a time 12:28
timotimo oh, you mean with regards to endianness?
lizmat no, just in general ( samcv's answer to me here verbally) 12:30
samcv timotimo: well that could be too, but there shouldn't by any endianess issues since i'm comparing like and like 12:32
and just treating it as raw data
though i may want to get ahold of a 32 bit computer and make sure reading 64 bits at a time isn't slower on that system. 12:33
12:34 travis-ci joined
travis-ci MoarVM build failed. Samantha McVey 'Implement memmem_two_uint32, up to 45% faster index of short 32bitstr 12:34
travis-ci.org/samcv/MoarVM/builds/375867773 github.com/samcv/MoarVM/compare/87...f4b9c1b309
12:34 travis-ci left
samcv ah nqp wanted a newer version i guess 12:34
12:43 travis-ci joined
travis-ci MoarVM build failed. Samantha McVey 'Implement memmem_two_uint32, up to 45% faster index of short 32bitstr 12:43
travis-ci.org/samcv/MoarVM/builds/375871214 github.com/samcv/MoarVM/compare/f8...00f7892a19
12:43 travis-ci left 13:22 ilbot3 joined
moderator github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
13:57 Kaypie joined 14:11 committable6 joined, quotable6 joined, undersightable6 joined
Geth MoarVM/master: 10 commits pushed by (Bart Wiegmans)++, (Elizabeth Mattijsen)++
review: github.com/MoarVM/MoarVM/compare/e...92140315de
16:10
MoarVM: b38df02a86 | (Samantha McVey)++ | 2 files
Ensure `make realclean` cleans 3rdparty/cmp

The `cmp` lib had not been added to Makefile.in and setup.pm yet. Make sure make realclean deletes the object file and runs make clean in the directory.
16:29
timotimo oops :S 16:36
build systems, eh? who understands 'em!
16:36 lizmat joined
samcv also. i'm having this issue unrelated to that 16:38
timotimo: heh
fatal: failed to update remote for submodule '3rdparty/dyncall'
and for some reason it has no remote. so i just delete the folder and then git checkout 3rdparty/dyncall and run ./Configure.pl again and it works. but then the next run i get that error again
i can ignore it, and things still build but
timotimo does "git submodule sync" do anything for that? 16:42
16:47 dogbert17 joined 16:50 statisfiable6 joined
lizmat .tell brrt merged your jit opcodes, test-t ~2.5% faster :-) 16:56
yoleaux lizmat: I'll pass your message to brrt.
samcv timotimo: no 16:57
error: could not lock config file /home/samantha/git/MoarVM/.git/modules/3rdparty/dyncall/config: File exists
i get this message though
ah i removed /home/samantha/git/MoarVM/.git/modules/3rdparty/dyncall/config.lock and it did work i think
\\o/ yay
lizmat .tell brrt looks like these are new opcodes to target: hllizefor, ctxlexpad, threadlockcount, capturenamedshash. the first 3 of these seem pretty generic for any type of async code running 16:58
yoleaux lizmat: I'll pass your message to brrt.
timotimo weird, is any git process still running?
samcv timotimo: nope. i think it got left behind
17:36 lizmat joined 18:27 Geth joined 18:47 unicodable6 joined
lizmat perl6 t/spec/S01-perl-5-integration/basic.rakudo.moar 18:57
19:20 brrt joined
brrt \\o 19:20
yoleaux 16:56Z <lizmat> brrt: merged your jit opcodes, test-t ~2.5% faster :-)
16:58Z <lizmat> brrt: looks like these are new opcodes to target: hllizefor, ctxlexpad, threadlockcount, capturenamedshash. the first 3 of these seem pretty generic for any type of async code running
brrt thanks! 19:30
.ask jnthn given that MVMHLLConfig does *not* start with an MVMCollectable header, can I safely assume that therefore, it doesn't ever move?
yoleaux brrt: I'll pass your message to jnthn.
brrt I suppose I can...
given that i already do for the original hllize 19:39
jnthn brrt: Yes, it's just malluc 19:40
yoleaux 19:30Z <brrt> jnthn: given that MVMHLLConfig does *not* start with an MVMCollectable header, can I safely assume that therefore, it doesn't ever move?
brrt hmm, but in this case, the hll name comes from a register, and i don't know if it is a proven constant 19:42
timotimo at least in the template jit we do have facts available 19:43
like "known value"
jnthn If it is constant then yeah, the fact will be set :) 19:46
brrt hmm
timotimo we use that for reprop devirt, remember? 19:47
brrt i do
i'm wondering if i can get away with only compling hllizefor if we can get the hll name as a constant 19:48
jnthn Probably it'd hit nearly all the cases 19:49
brrt I think so too 19:51
anyway, i'm off for tonight
19:54 Kaypie joined 20:29 robertle_ joined 20:48 jnthn1 joined 20:57 ilmari[m] joined
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/05/07/...-solution/ 21:35
21:38 ilmari[m] joined
MasterDuke timotimo: nice quick fix on the profile issue 21:48
timotimo well, your pinpointing made it easy
jnthn lizmat++ # weekly 21:50
21:53 nativecallable6 joined, unicodable6 joined
MasterDuke timotimo: i'm sort of annoyed i didn't see the fix myself. i looked for gc_seq_number, but then didn't follow what was done with gc_seq_num. but my excuse is it was late and i was tired... 21:55
timotimo that's just fine 21:56