samcv yeah if you build with clang i'm guessing you may get the same thing though 00:00
MasterDuke clang version 4.0.0-1ubuntu1 (tags/RELEASE_400/rc1) 00:03
same with or without _nocheck
samcv i get 1.6894568 with clang and 1.8 on gcc. but if i change to nocheck on clang i get 2.3 seconds
MasterDuke slightly slower in either case than gcc
samcv i have clang 4.0.1 00:04
you seem to have rc1?
mine says clang version 4.0.1 (tags/RELEASE_401/final)
hm
MasterDuke afk for a bit, but might be able to check on my arch linux machine afterward (using kubuntu 17.04 on this laptop)
samcv ok cool
i'm using: 00:17
my $a = slurp "tolstoy.txt"; use nqp; my $t1 = now; nqp::index($a, "abdiicate") for ^400; say now - $t1
where that txt is found here www.gutenberg.org/files/2600/2600-0.txt
doing it 400 times i get ~5 vs ~7. when you get back run that test and let me know
00:31 lizmat joined
MasterDuke on the laptop, with clang, that exact test gives ~10.2s for regular, 7.0s for _nocheck 00:32
on the laptop, with gcc, that exact test gives ~8.9s for regular, 7.4s for _nocheck 00:35
now trying on the desktop
on the desktop, with gcc, that exact test gives ~9.6s for regular, 9.5s for _nocheck 00:40
on the desktop, with clang, that exact test gives ~10.6s for regular, 10.7s for _nocheck 00:43
clang version 4.0.1 (tags/RELEASE_401/final)
gcc version 7.1.1 20170630 (GCC) 00:44
samcv: so it looks like _nocheck ranges from no speedup to 30% faster, depending on hardware and compiler 00:45
samcv yeah
that's still insane how much slower it is at times :\
MasterDuke it was never really slower for me 00:48
samcv yeah maybe i got it backwards my bad 00:49
but regardless it shouldn't make *that* much of a differenec for a 3+MB file
:\
oh well
maybe it's not always inlining properly or something?
MasterDuke heh, it's pretty small, i'd hope there's no problem inlining it 00:54
samcv not sure why else it would have such a difference in speed 00:59
MasterDuke no idea here 01:02
samcv clang says it is a mild hint to the compiler 01:05
i mean that's the same in gcc. they just make different choices i guess hm
that's what i'm guessing at least
well in configure.pl it detects clang as gcc. not sure how relevant that is 01:08
01:31 lizmat joined 01:52 ilbot3 joined
samcv on this test i'm getting 7.9163688 for clang and 11 seconds for gcc 02:24
only difference is --compiler flag
it's 13.75 before my grapheme caching change though. but still annoying i don't see as much improvement 02:27
and most people use gcc
03:51 sivoais joined 06:02 stmuk joined 06:13 unicodable6 joined
Geth MoarVM/master: 8 commits pushed by (Samantha McVey)++ 06:17
06:33 travis-ci joined
travis-ci MoarVM build errored. Samantha McVey 'Merge pull request #661 from samcv/grapheme_iterator_cached 06:33
travis-ci.org/MoarVM/MoarVM/builds/271568505 github.com/MoarVM/MoarVM/compare/d...998d5896b5
06:33 travis-ci left 06:59 brrt joined
brrt .tell nine not sure what is your intention with the SAVE_RV node, but i think | mov TMP6, R12 is suspscious, as iirc R!2 == TMP5 07:11
yoleaux brrt: I'll pass your message to nine.
brrt also, WORK[arg.v.i64], why?
i should be saying though, very cool work :-) 07:12
oh, i see 07:13
there's two more sane strategies you could us
*use
one, allocate an extra register (functionality for that exist in guess-which-branch); two; use the 'args' space for your frame to allocate the temporary 07:14
nine brrt: the intent of SAVE_RV is to move the return value into a callee saved register, so it will survive the call to MVM_gc_mark_thread_unblocked that I have to do between calling the function and boxing the return value
yoleaux 07:11Z <brrt> nine: not sure what is your intention with the SAVE_RV node, but i think | mov TMP6, R12 is suspscious, as iirc R!2 == TMP5
brrt (e.g. see what unless_i do)
TMP12 is not callee-saved
(or is it?) 07:15
r12
let me think before i say something silly
nine In the best case MVM_gc_mark_thread_unblocked doesn't even use r12 and thus we don't have to access memory at all.
brrt no, i think you're right
nine It is according to the comments :)
line 25
Written by a Bart Wiegmans. No idea how much he knows about JITs ;) 07:16
brrt not that much
depending on when it was written :-P
okay, right
r12 is callee saved, i renember now, that's conveniently uniform between windows and posix 07:17
giving that, you have a minor issue in your code :-P
you forgot the other part of callee-saved 07:18
nine which is?
brrt you have to save it for your caller
so in the function prologue/epilogue, your're going to need to store it
nine oooh
That kinda makes sense 07:19
brrt hmm…. now that i know what you want it for, if it is really just that short storage, you might be better of using the stack
nine Which means that I cannot save memory access at all by that
brrt we have ample stack space left for a pointer
and you can use a .define to define a symbolic represetnation of the stack position 07:20
nine Can I just use good old fashioned push/pop for that? Haven't seen that in JIT code so far
brrt you can but apparently on some (windows) platforms the official ABI is to have stack frames 16-byte-aligned 07:21
don't ask me why, and in fact i don't think it is practically required
as in, everything just works if you disregard it
other than that minor nitpick, do whatever feels natural :-) 07:22
nine++ for digging into this
nine Cool :) Thanks for those hints! 07:26
brrt np 07:38
samcv brrt, is there a way to compare code for a specific function 07:39
because i want to debug why gcc is like 20% slower on the KMP function
brrt it can be done, yes
i suppose you'd instruct objdump
samcv do you know how to do that? 07:40
brrt not offhand, no
you can basically just say gobjdump -d your_file.o 07:45
and it will prefix the symbols with the correct function names
it's generally useful
08:02 leont joined 08:08 zakharyas joined 08:17 robertle joined
samcv hm 08:21
brrt yeah, that's less useful than you might want 08:37
jnthn morning o/
brrt good hi jnthn 08:47
jnthn, re: COPY_ARRAY; a MVM_STATIC_INLINE couldn't take over the type implicitly 08:48
i could introduce a MVM_VECTOR_COPY, but i'd have to convert the array pointers to 'full' MVM_VECTOR structures, which means that we are storing the allocated size uselessly 08:49
(maybe a macro MVM_VECTOR_SIZE would be handy)
other than that, i agree with pretty much all your comments :-) 08:52
jnthn brrt: Yeah, just commented; I missed that detail 08:53
lizmat jnthn: something from perl6-users: can we rely on the main thread always having thread ID 1 ? 08:58
09:08 Skarsnik joined
jnthn lizmat: Umm...so far as VM-internal IDs go, presumably. For the native IDs, that'd be OS-specific and probably "no" 09:10
Also I'm not sure you can portably assume it across backends
brrt what about a method 'is-starting-thread' 09:11
jnthn Just store it somewhere and === it I guess :)
my $main-thread = $*THREAD; at startup
lizmat ok
thanks!
jnthn That'd be more robust/portable. 09:12
jnthn wonders why somebody wishes to do this :)
lizmat yeah, trying to figure that out as well :-)
brrt i'm going to be presumptive, and say, probably to do something in a react block 09:13
conditionally on the main thread
btw, i recently got my hands on 'Learning Perl' 09:21
and read the preface
it said 'Perl is an easy language to use, and a hard language to learn'
and i thought to myself
that pretty much explained the fate of perl in the last 20 years 09:22
Geth MoarVM/jit-legacy-cleanup: 19 commits pushed by (Bart Wiegmans)++
review: github.com/MoarVM/MoarVM/compare/2...b150b63d57		 09:23
09:53 Geth joined
Geth MoarVM/jit-legacy-cleanup: 84f70712b9 | (Bart Wiegmans)++ | src/jit/compile.c
Move size check into COPY_ARRAY

Is duplicated, so why not embed it, and make the code simpler.		 10:00
brrt jnthn, if no objections, i'm going to merge jit-legacy-cleanup :-) 10:17
jnthn brrt: All my comments are dealt with? :)
brrt i think so
jnthn Looks like it to me 10:18
+1
brrt (all systems go!)
re: the move of the sequence number from jit code to spesh, i'm not 100% positive, but should we be adding it to the spesh candidate, or to the spesh graph 10:19
i'm thinking candidate, but am i correct in thinking that the candidate is produced before the graph? 10:20
Geth MoarVM/master: 29 commits pushed by (Bart Wiegmans)++
review: github.com/MoarVM/MoarVM/compare/4...19caf7da3b		 10:25
jnthn Not any more
The candidate is now produced after code-gen time 10:26
But before JIT
brrt hmmmm 10:35
what would be the right place to assign a sequence number?
jnthn brrt: What's the purpose of the sequence number? 10:36
brrt to uniquely identify specific frames by time-of-specifalization (i.e. only when blocking)
so that you can have a spesh-bisect similar to jit-bisect
jnthn But...we already have that feature? 10:37
MVM_SPESH_LIMIT
brrt do we? 10:40
how do you do that without sequence numbers?
or well, i see how you would
jnthn There's a global count of how many frames we spesh'd
Well, actually, how many specializations we produced 10:41
brrt hmmm 10:42
so to build a bisect based on that would actually be really simple
10:44 travis-ci joined
travis-ci MoarVM build passed. Bart Wiegmans 'Merge pull request #669 from MoarVM/jit-legacy-cleanup 10:44
travis-ci.org/MoarVM/MoarVM/builds/271630723 github.com/MoarVM/MoarVM/compare/4...caf7da3b32
10:44 travis-ci left
jnthn samcv: Dunno if this warning means anything to you: 11:00
src/strings/unicode.c:73800:78: warning: unknown escape sequence: '\X' {"KEYCAP: 6",342},{"KEYCAP: 7",343},{"KEYCAP: 8",344},{"KEYCAP: 9",345},{"KEYCAP: \X{23}",346},
samcv not really i can fix it temporarily. i mean that is KEYCAP: #
which never worked anyway
11:02 brrt joined
jnthn Think I've figured out rt.perl.org/Ticket/Display.html?id=131961 11:04
samcv oh nice
also did you see the issue in moarvm/moarvm i opened about it requesting the same bytes forever
jnthn No
samcv well it requests 0 bytes for infinity for certain utf8 files
that are missing bytes at the end of the file 11:05
we hypothesized it kept asking for more since it expected more, but there was no more in th efile
so it just repeated forever
jnthn Hmm 11:06
Probably not a bug at MoarVM level
But rather in the Perl 6 I/O code, which is presumably mis-handling zero-length buffers
Or EOF or similar
dogbert17 oh, 131961 is it the Malformed utf8 problem 11:07
jnthn Yeah. I dunno how we'll get a test for it though :P
I mean, I don't really want to commit the huge file :)
I guess a smaller test is possible
dogbert17 I had a smaller golf
jnthn Ah, cool
dogbert17 sec
jnthn Maybe you'd like to do the test? :)
dogbert17 jnthn: irclog.perlgeek.de/moarvm/2017-09-02#i_15107306 11:08
jnthn grrr, DNS resolution failure on irclog 11:09
dogbert17 here's the gist of it:
create a file with this specific code: perl6 -e 'print "a" x (2**20 - 1) ~ "«"' > golf
then run: perl6 -ne '' golf
jnthn ah, cool
Presumably just .lines of the file works too 11:10
dogbert17 probably
[Coke] will be very happy :)
11:11 brrt joined
jnthn yay, got a test that fails before my fix and passes after 11:14
dogbert17++
dogbert17 jnthn++ 11:15
nice SPW talks btw
jnthn :) 11:17
Geth MoarVM: 1dd4486899 | (Jonathan Worthington)++ | src/strings/utf8.c
Correct buffer handling in UTF-8 fast->slow path

When transitioning between the two paths, we could incorrectly mark some bytes that made up part of a codepoint as having been consumed, when in reality we should have left them around for the next buffer.
timotimo fantastic! 11:19
Geth MoarVM: ee06f56f88 | (Samantha McVey)++ | 2 files
UCD: For sequences, convert from \x{ } to the Unicode codepoints

This doesn't affect using "\c[ ]" since names with # were not accessible but it *does* work with .parse-names or with the nqp call directly.
Currently the only thing that uses this is `keycap: #` which uses the \x syntax so that it parses correctly (though previous versions of the file had an actual `#` in there, which is why we didn't have this problem before).		 11:24
samcv fixed the unicode thing
ilmari why not just $name =~ s/ \\x \{ ([[:xdigit:]]) \}/chr hex $1/gex;? 11:28
jnthn lunch &
ilmari 1) \d doesn't match a-f, 2) do we really want to decode _multiple_ layers of \x escapes?
brrt (if we don't, will Damian be able to do cool things?) 11:32
ilmari this is parsing Unicode data files, isn't it? 11:35
not damiancrack
brrt Geth didn't show my push 12:02
ilmari which one? 11:25 < Geth> ¦ MoarVM/master: 29 commits pushed by (Bart Wiegmans)++ 12:04
(timestamp in UTC+1)
isn't it supposed to detect merges better? 12:05
Skarsnik do I need to patch the jvm backend for github.com/MoarVM/MoarVM/pull/659 ? 12:07
12:14 leont joined 12:39 zakharyas joined 12:49 brrt joined
Geth MoarVM: e0ece7f828 | (Jonathan Worthington)++ | 4 files
Flush standard handles at exit.
 12:58
13:01 brrt joined
brrt theres still a bunch of small changes in even-moar-jit to the legacy JIT 13:02
that i somehow missed
timotimo looks like i found the problem that causes different outputs for new and old heap snapshot formats 13:08
dogbert17 jnthn: did you see github.com/MoarVM/MoarVM/issues/653
jnthn Yeah, not yet sure what's going on there 13:09
dogbert17 I can't replicate MasterDuke's findings on my 32 bit box 13:10
13:13 travis-ci joined
travis-ci MoarVM build failed. Jonathan Worthington 'Flush standard handles at exit.' 13:13
travis-ci.org/MoarVM/MoarVM/builds/271676756 github.com/MoarVM/MoarVM/compare/e...ece7f8288a
13:13 travis-ci left
timotimo 100.61user 0.45system 1:08.87elapsed 146%CPU (0avgtext+0avgdata 722380maxresident)k 13:14
> 49.54user 0.51system 0:17.51elapsed 285%CPU (0avgtext+0avgdata 733140maxresident)k
i'm a bit surprised it doesn't change memory usage. that's quite good. 13:15
oh, hold on 13:20
that still has the change that prints all data to a text file
oh, no it doesn't
oh and i guess the first one had precompilation in it 13:21
dogbert17 I often get this when running spectests: 13:24
t/spec/S17-lowlevel/atomic-ops.t .................................. Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 18/28 subtests
timotimo that doesn't sound good 13:25
atomic ops not implemented on 32bit?
dogbert17 dunno, when running the file by itself it always passes
according to spectest something goes wrong with test 11 13:26
timotimo try having some load on your cpu
dogbert17 which is what I have when running the suite 13:27
timotimo time to work on variable-sized entries for collectables and references 13:30
dogbert17 timotimo: got it while under load 13:31
ok 10 - Updated value seen by non-atomic too
A IntLexRef container does not know how to do an atomic load
in block <unit> at repos/rakudo/t/spec/S17-lowlevel/atomic-ops.t line 45
IntLexRefContainer? 13:32
timotimo oh, huh, that's not supposed to happen
dogbert17 :(
13:35 MasterDuke joined
jnthn huh 13:35
Yes it does!
timotimo oh? 13:37
oh, it does know how to do that
not it does supposed to happen
(because grammar)
dogbert17 ah, that's the same error that MasterDuke got in github.com/MoarVM/MoarVM/issues/653 13:38
Geth MoarVM: 4e7821be4b | (Jonathan Worthington)++ | src/io/syncfile.c
Flush output buffer where needed.

This makes :rw and similar modes work out properly, along with ensuring tell gives the right output.		 13:41
13:55 Skarsnik_ joined
Geth MoarVM: 6260e6fceb | (Jonathan Worthington)++ | src/io/syncfile.c
Ensure write to unwritable handle fails right off.

This is relied on in Rakudo, since it doesn't try to track modes to the point of doing I/O (which is OK, so long as we behave consistently even when buffering is turned on).		 13:56
13:57 Skarsnik__ joined 14:01 Skarsnik_ joined
timotimo hmpf. simplest version of variable-length encoding for collectables compresses it down to 75% size :| 14:04
Geth MoarVM: 41e1b7cef5 | (Jonathan Worthington)++ | 5 files
Don't try and sync when flushing is enough.

At exit we only want to flush our own buffering, not try and fsync or whatever the platform equivalent is.		 14:06
14:07 brrt joined 14:09 jdv79 joined
timotimo the references on the other hand benefit vastly 14:11
jdv79 so I was looking into RT#127772. i don't this: github.com/MoarVM/MoarVM/blob/mast...rops.c#L51 14:12
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=127772
jdv79 looks like a useless stat call to me 14:13
jnthn To me also 14:15
Presuming that uv_fs_stat just passes along whatever stat does 14:16
jdv79 the docs suggest so, yes
ok, i'll continue under the assumption that i'm not missing something
thanks
14:22 AlexDaniel joined
timotimo 5637523 24M -rw-r--r--. 1 timo timo 24M Sep 4 16:36 new_format_after_compression 14:37
5637511 45M -rw-r--r--. 1 timo timo 45M Sep 4 16:34 new_format_before_compression
dogbert17 timotimo++ 14:40
timotimo original format is 23 megabytes btw 14:42
jnthn So the new format is larger? 14:43
timotimo a little bit, yeah
14:45 brrt joined
timotimo i can make the collectables chunks shrink down to about 75%, too 14:46
the reason i'm doing all this is to make parsing faster, though 14:47
and it is significantly faster :) 14:51
more than 4x
m: say 36_980_688 / 1_540_862 14:53
camelia 24?
timotimo 24 bits per reference on average 14:54
huh 14:57
m: 15_292_008 / 1_540_862 14:58
camelia WARNINGS for <tmp>:?Useless use of "/" in expression "15_292_008 / 1_540_862" in sink context (line 1)?
timotimo m: say 15_292_008 / 1_540_862
camelia 9.9243203?
timotimo the old format beats the new format significantly with regards to size here
the collectables part is also noticably bigger
what gives o_O
ahahaha 15:03
yeah, the $size-per-reference in the file is the original size pre-compression 15:04
15:04 brrt joined
timotimo 7.6 bytes per entry 15:08
brrt is planning to do some documentation fixes and reopen the PR for even-moar-jit 15:10
timotimo the collectables in the old format have 19.5 bytes per entry 15:13
i think it's 28 in the new format
9.7 chars per entry in the references one 15:15
(vs references in the new format having only 7.6 bytes per entry on average)
jnthn: do you think the size hit is acceptable for the performance gain, or should i put the 75% compression into the collectables section, too? 15:16
the new format seems to compress better. 3.5mb vs 3.2mb 15:17
timotimo BBL
15:37 travis-ci joined
travis-ci MoarVM build errored. Jonathan Worthington 'Don't try and sync when flushing is enough. 15:37
travis-ci.org/MoarVM/MoarVM/builds/271704634 github.com/MoarVM/MoarVM/compare/6...e1b7cef56e
15:37 travis-ci left
Geth MoarVM: 9fdd7b37c9 | (Jonathan Worthington)++ | src/spesh/optimize.c
Remove some dead returns.
 15:54
MoarVM: ab8032ebc0 | (Jonathan Worthington)++ | src/spesh/optimize.c
Better if_o/unless_o optimization in some cases.

When the test is for a type object, we would turn it into isconcrete. However, we may in some cases know the answer to that already. Thus, specialize the added isconcrete, and then re-specialize the branch in case we can now eliminate it.
timotimo nice
Geth MoarVM/heapsnapshot_binary_format: fdccbe3381 | (Timo Paulssen)++ | src/profiler/heapsnapshot.c
introduce a binary format for heapsnapshot

it starts with a version identifier to differentiate between the old format and this one. all records except the string heap are fixed sizes and the file ends in a table outlining the sizes of the individual segments.
... (7 more lines)		 16:00
MoarVM/heapsnapshot_binary_format: cac6b6d492 | (Timo Paulssen)++ | 7 files
WIP gc_describe functions for new spesh datastructures
MoarVM/heapsnapshot_binary_format: 15fac4b2ed | (Timo Paulssen)++ | src/profiler/heapsnapshot.c
make references variable-length, add halfway to index

this reduces the average size of references entries from 24 bytes to something more like 7.6 bytes on average in one example dataset. The old format took 9.7 chars on average in the same dataset.
the halfway point in the index serves to allow a second thread to start parsing half-way into the blob, which is what allows the new heap snapshot parser to be so fast.
timotimo (rebased on latest master)
not so happy about the commit in the middle, but without parts of that the heap snapshot profiler would crash immediately 16:01
Geth MoarVM: bdw++ created pull request #674:
Merge 'expression' JIT backend
jnthn Hm, it would appear that doing a BB elimiantion pass right after we have deleted a conditional can be quite a win 16:05
As it marks writers dead
And we pick up on that in PHI merges sooner
m: say 1.11 / 1.29 16:07
camelia 0.860465?
timotimo i'd like to have a quick way to read just a single char from a file handle in binary mode; i don't really want to allocate a buf_8 for every one-byte read, so would i have to add a new op?
jnthn Um 16:08
Just read a buf and pick things off it in Perl 6
timotimo that's what i'm doing right now; i created a MyLittleBuffer class that reads in big chunks and then i can .shift off of the buf i get from it
jnthn The buf allocation will probably be swamped by the fact that every call down to the I/O handle acquires a mutex
timotimo hm, that seems fair 16:09
are you +1 on making getc on a binary-mode handle work like .read(1)[0] ?
jnthn Not really...
timotimo OK
jnthn c means char
I'd rather we don't confuse those APIs
Of course you could put the thing in latin-1 mode and ord the char that comes back... :) 16:10
And then enjoy the buffering
timotimo then i'll have to keep a counter around rather than being able to just shift
so i suppose i'll keep my buf and buffer approach 16:11
jnthn About the calc above, somehow I've managed to get 14% off the write a million lines benchmark with the immediate BB cleanup thing I described
timotimo wow
jnthn Well, in combination with what I pushed a moment ago
timotimo is it because we don't iterate to fixpoint?
jnthn I think it may have saved a late-bound can
timotimo cool
jnthn But what that kind of size drop I also start to wonder if we might have pulled say below the inline limit also 16:12
*time drop
timotimo right
jnthn These kinds of things add up
timotimo they sure do 16:13
jnthn Currently doing spesh stressing 16:14
Before I commit this
I wonder if this'll cause wider improvemnets though
Yeah, 70% inlined to 80% inlined 16:19
uh, 85% sorry
timotimo *nice* 16:20
jnthn Now everything inside of say is inlined
In fact, say is the only thing that ain't inlined
Geth MoarVM: dd04dd8094 | (Jonathan Worthington)++ | src/spesh/optimize.c
Do dead BB elimination pass after branch deletion

This means that writers in eliminated basic blocks will be marked dead right away, which in turn means that we'll be able to be more certain in a bunch of PHI merges. The more precise type information can then lead to better downstream optimizations.
In a Perl 6 write a million lines benchmark, as well as the immediate gains this leads to a further inlining, giving 10%-15% time reduction and bringing the benchmark to within 1.2x of Perl 5.		 16:24
jnthn m: say 8306128726 / 9554038194 16:30
camelia 0.86938408214?
jnthn Similar sized reduction according to callgrind too
16:31 dogbert2 joined
timotimo i'll need a change in API for the heap snapshot profiler now 16:37
i currently write to a file handle i open right before i write the heap snapshot, but the hll code will want to specify the filename, except the only way to do that would require the filename to be decidde at the beginning of profiling rather than at the end 16:38
jnthn Ah, hmm 16:39
I think maybe we pass a hash of profiling options though?
timotimo right
jnthn So we could send the filename in that way
timotimo any worries about the filename being stolen in between start and finish of the profile run? 16:40
jnthn Not really, I mean it could in theory happen today 16:47
timotimo right 16:48
should i immediately kick out the old format from moarvm and just keep it around in the heapanalyzer? 16:49
jnthn I don't know there's much point having both, if you're confident the new one is working well 16:50
timotimo i should definitely test with more than one snapshot before i do the merge *cough* 16:52
16:54 robertle joined
timotimo hmm, if we have the filename up front already, it would perhaps be an interesting idea to stream out individual heap snapshots and later add the string heap, static frames, types, ... 16:54
jnthn Hmm, of the time that we spend doing the UTF-8 encoding, about 75% of it is in the codepoint iterator 16:55
timotimo: Yeah, that probably makes sense
timotimo in that case i'll have to juggle the sections around
but we might be able to save quite a bit of RSS over long-running programs
jnthn For sure 16:56
17:01 lizmat joined
jnthn dinner & 17:03
timotimo oops, 1.5 GB of heap snapshot
oops, hard drive filled up all the way 17:06
Skarsnik_ lol
timotimo throwing 9 gigs of backup stuff from the laptop to the fileserver 17:18
17:22 travis-ci joined
travis-ci MoarVM build failed. Jonathan Worthington 'Ensure write to unwritable handle fails right off. 17:22
travis-ci.org/MoarVM/MoarVM/builds/271700536 github.com/MoarVM/MoarVM/compare/4...60e6fceb24
17:22 travis-ci left
timotimo jnthn: would it ever be interesting to see what owner each individual collectable has? 17:24
17:55 leont joined 18:00 travis-ci joined
travis-ci MoarVM build passed. Jonathan Worthington 'Better if_o/unless_o optimization in some cases. 18:00
travis-ci.org/MoarVM/MoarVM/builds/271744461 github.com/MoarVM/MoarVM/compare/4...8032ebc055
18:00 travis-ci left 18:12 domidumont joined
timotimo there's still lots of bugs in handling multiple snapshots %) 18:30
18:32 solarbun1y joined 18:35 committable6_ joined 18:43 eater joined 18:48 ilmari[m] joined
timotimo just a copy-pasto, a change to some calculation not needing to factor in a header's size any more, and an off-by-one caught by my little ascii chunk headers 18:56
MasterDuke nice, about done? 18:59
Skarsnik_ should I restart the bots? 19:00
jnthn timotimo: Not really, I don't think 19:02
timotimo thought so 19:04
MasterDuke: nope, still got problems :D 19:08
MasterDuke heh, don't we all... 19:17
19:25 lizmat joined
timotimo while transporting my laptop to the dining room, i hit its edge against the door frame and it rebooted 19:26
MasterDuke hope stuff was backed up! 19:27
timotimo nothing was in peril
19:54 travis-ci joined
travis-ci MoarVM build passed. Jonathan Worthington 'Do dead BB elimination pass after branch deletion 19:54
travis-ci.org/MoarVM/MoarVM/builds/271755550 github.com/MoarVM/MoarVM/compare/a...04dd80945c
19:54 travis-ci left
Geth MoarVM/jit_nativecall: 16 commits pushed by (Stefan Seifert)++
review: github.com/MoarVM/MoarVM/compare/9...520d47068f		 20:40
nine rebased it on master and worked in brrt++'s changes to the JIT
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2017/09/04/...a-reading/ 20:59
21:17 dogbert2 joined
timotimo oh wow, that was a really bad miss 21:46
i've been grabbing the data from references into a uint8 even though only the first field will fit into that
in the old version
i've been looking for the error in all the wrong places 21:48
now the complete refs table as read by version 1 and version 2 match exactly 22:02
MasterDuke good deal 22:03
timotimo turns splitting back on
let's see if it properly calculates the sizes for both halves to match up 22:04
cool, they still match
the new heap snapshot format just came up smaller than the old one in an example test case 22:15
(i no longer write the kind of reference in a bigger integer since it's at most 2 bits anyway! 22:16
MasterDuke smaller and faster! does it also do julienne fries? 22:24
Geth MoarVM/heapsnapshot_binary_format: af10d049e6 | (Timo Paulssen)++ | src/profiler/heapsnapshot.c
fix accidental truncation of references values
MoarVM/heapsnapshot_binary_format: 7274060bc3 | (Timo Paulssen)++ | src/profiler/heapsnapshot.c
never store ref kind in more than 8 bit

currently there's only 2 bits dedicated to this.
22:24 Ven joined
timotimo 25% time spent in the gc when parsing those snapshots ... not such a great look :) 22:46
23:03 AlexDaniel joined
robertle square 23:04
timotimo MasterDuke: if you want, you can test the latest stuff i pushed to moarvm and the heap analyzer
timotimo goes to bed 23:06
samcv jnthn, how would you feel if for strands we cached a grapheme iterator? that way you could make subsequent calls to the same strand and get much faster access to sequential sections of the strand 23:13
jnthn Everything in MVMString and hanging from it must be immutable 23:42
An iterator is mutable
I'm not sure where else you'd be thinking of caching it
But if it's on MVMString or on a strand within it, then I don't see how that could be done without violating the immutability of strings 23:43
23:44 bisectable6 joined, committable6 joined, nativecallable6 joined, benchable6 joined, coverable6 joined, quotable6 joined, bloatable6 joined, greppable6 joined, unicodable6 joined, releasable6 joined, evalable6 joined, squashable6 joined, statisfiable6 joined
jnthn sleep time here; bbiab :) 23:46

Powered by Cro and the Raku® Programming Language.

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

Thank you!