github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:08 lizmat left
Geth MoarVM: MasterDuke17++ created pull request #896:
Add parens to expressions to silence clang warning		 01:39
MoarVM: MasterDuke17++ created pull request #897:
Add pragma to switch to silence clang warning		 01:49
02:18 Kaiepi left 02:20 Kaiepi joined 05:08 Kaiepi left 05:09 Kaiepi joined 05:13 Kaiepi left, Kaiepi joined 05:25 brrt joined
brrt \o 05:30
05:50 stmuk joined 05:52 stmuk_ left 05:57 Kaiepi left 05:58 Kaiepi joined 06:23 kanopis joined, kanopis left 06:24 robertle_ left, kanopis joined 06:42 domidumont joined
Geth MoarVM: 513000322d | (Bart Wiegmans)++ | 2 files
Revert "Revert "Implement JIT template for ctxcallerskipthunks""

This reverts commit f66ebd4bdb45ee25cdda29d48a0c7eb7cd066d36.
Problem was in raw fragment with labels pointing out of the code.		 06:48
06:48 domidumont left 06:49 domidumont joined 07:10 travis-ci joined
travis-ci MoarVM build errored. Bart Wiegmans 'Revert "Revert "Implement JIT template for ctxcallerskipthunks"" 07:10
travis-ci.org/MoarVM/MoarVM/builds/400755711 github.com/MoarVM/MoarVM/compare/4...3000322dc5
07:10 travis-ci left 07:12 brrt left 07:16 brrt joined 07:30 domidumont left, domidumont joined 08:12 zakharyas joined
brrt hmm, completely removing auto-casting may be impossible as we often rely on compile-time information of the sizes of operands 08:52
I know of a way to fix that but...
Geth MoarVM/jit-expr-refactor: 7 commits pushed by (Bart Wiegmans)++ 09:14
09:21 lizmat joined 09:23 brrt left 10:05 stmuk_ joined 10:07 stmuk left 10:48 brrt joined 10:55 zakharyas left 11:28 lizmat left 11:48 lizmat joined 12:23 zakharyas joined 12:24 Kaiepi left 12:29 Kaiepi joined 12:58 zakharyas left 12:59 brrt left, brrt joined 13:01 zakharyas joined 13:05 synopsebot_ left, synopsebot joined 13:10 lizmat left 13:17 brrt left 13:19 lizmat joined 13:22 domidumont left 13:24 domidumont joined
Geth MoarVM: 930fd477e6 | (Jonathan Worthington)++ | src/spesh/facts.c
More precise handling of reads of deopt-marked ins

Previously, we would consider reads by an instruction that might deopt post-optimization as if they were being read after that deoptimization, and so could preserve write instructions for the sake of deopt when there was no need to do so. With this change, we will not. This allows a small number of additional instruction deletions. For example, the ... (5 more lines)		 13:42
jnthn It's something :) 13:43
yoleaux 13:03Z <Zoffix> jnthn: reminder that you're listed as a stakeholder for "start in sink attaches error handler" feature for 6.d: github.com/perl6/6.d-prep/blob/mas...or-handler
jnthn ooh, I still want to do that :)
I can also reproduce the NQP compile crash with JIT disabled 13:44
timotimo wow, small change to make that work 13:45
jnthn Next week I'll also 13:46
1. Separate out the "deopt usages" form the normal usages, so we can see the difference
2. Use that to let us be far more aggressive if we end up with no instructions at all that might deopt in the result 13:47
No SEGV without JIT in 24d3b5b. SEGV in 5ef61a7. 13:51
The one commit between them is a documentation patch.
Yeah, it's 5ef61a7. 13:52
No idea why, or how on earth it can magically work under the JIT 13:53
But obj is null. 13:54
In shift_o
timotimo how does it handle the case where MVM_spesh_args isn't being called by args_from_callinfo? 13:55
it just doesn't do optimizations?
jnthn Well, on the normal path we have the type tuple available and it sources the data from that 13:56
ah, world up time, bbl :) 13:57
*cup :)
timotimo ah!
i thought the world was going to end
and i was wondering how you'd manage to "be back"
14:00 robertle left 14:02 travis-ci joined
travis-ci MoarVM build failed. Jonathan Worthington 'More precise handling of reads of deopt-marked ins 14:02
travis-ci.org/MoarVM/MoarVM/builds/400891053 github.com/MoarVM/MoarVM/compare/5...0fd477e646
14:02 travis-ci left 14:14 brrt joined 14:36 lizmat left 14:44 lizmat joined 14:50 robertle joined
Geth MoarVM: ef41080c10 | (Bart Wiegmans)++ | 2 files
[JIT] Use '^addrf' macro for setf, getf

For consistency		 14:54
brrt i'm a bit stuck on cast insertion
a): it works now, and it is useful (it allows you to write templates without much concern for the size of operands) 14:55
b): it requires a (partially redundant) walk of the tree directly after tree assembly 14:56
c): which prevents us from assigning sizes to nodes during the template precompilation phase
d): and makes it harder to correctly optimize the code (as you'll have to take into account operand sizes) 14:57
15:04 lizmat left 15:06 Kaiepi left 15:07 Kaiepi joined 15:12 travis-ci joined
travis-ci MoarVM build failed. Bart Wiegmans '[JIT] Use '^addrf' macro for setf, getf 15:12
travis-ci.org/MoarVM/MoarVM/builds/400921292 github.com/MoarVM/MoarVM/compare/9...41080c105f
15:12 travis-ci left 15:21 domidumont left 15:56 zakharyas left
Geth MoarVM/in-situ-strings: 6 commits pushed by (Timo Paulssen)++, (Bart Wiegmans)++ 16:14
brrt ^ rebase 16:30
16:30 brrt left 16:43 domidumont joined
dogbert17 .seen samcv 16:43
yoleaux I saw samcv 13:03Z in #perl6: <samcv> so there may not be a way to do that yet
dogbert17 looks as if the MoarVM build is broken on 32 bit systems atm 16:44
.tell samcv commit 3ef2acf0f breaks the build on 32 bit systems 16:54
yoleaux dogbert17: I'll pass your message to samcv.
dogbert17 .tell samcv take a look at gist.github.com/dogbert17/ab6953e0...cdf984bf60 16:57
yoleaux dogbert17: I'll pass your message to samcv.
Geth MoarVM: ugexe++ created pull request #898:
Remove unnecessary MVMROOT		 17:08
17:15 domidumont left 18:32 Kaiepi left 18:35 Kaiepi joined 18:46 robertle left
samcv dogbert17: is there a way i can build 32 bit mvm on a 64 bit computer 19:13
yoleaux 16:54Z <dogbert17> samcv: commit 3ef2acf0f breaks the build on 32 bit systems
16:57Z <dogbert17> samcv: take a look at gist.github.com/dogbert17/ab6953e0...cdf984bf60
geekosaur would have to install a 32-bit toolchain in wow 19:16
Geth MoarVM: a3e38fd823 | (Samantha McVey)++ | src/strings/uthash.h
Fix the 32 bit build

It got broken with the newest hash changes due to an ommited #define line.		 20:02
dogbert17 samcv++, that was quick :) 20:05
20:20 travis-ci joined
travis-ci MoarVM build failed. Samantha McVey 'Fix the 32 bit build 20:20
travis-ci.org/MoarVM/MoarVM/builds/401034468 github.com/MoarVM/MoarVM/compare/e...e38fd82338
20:20 travis-ci left 20:51 lizmat joined
samcv timotimo: i've been thinking about the robin hood hashing a lot today 21:38
timotimo have we discussed this before? i don't seem to remember 21:39
samcv and we would need to make changes to the implementation (compared to the "I made the fastest hash table" post. Since it suffers an issue if hashes get put into the same location, or near
when you reach the limit you expand the table, and that would run us out of memory during an attack. what i propose would be to have a slow path, which allows us to have variable length sections of the table 21:40
timotimo that was something distinct from the presentation that advocated linear scans over bucket lists?
samcv uh well similar
linear scans don't reorder anything while robin hood reorders things so they are as close as possible to where they are "supposed" to me 21:41
*be
though alternatively we could not have a slow path and just let things flow over on attack, though usually we will have max 4 or so items per position. and resize when there's no more room in the array near that position 21:42
21:43 MasterDuke left
timotimo what do you mean by "let things flow over"? 21:43
jnthn samcv: Does that approach results in read operations potentially becoming write operations? 21:44
samcv well go past where they should ideally be
timotimo ah, yes
jnthn I forget the exact idea, but have vague memories of robin hood hashing doing that
samcv and so we'd resize if it fills the section, and in normal course that is fine
jnthn: uh not sure
what you mean
but i would want poisoned sections to not impact performance of non-poisoned sections 21:45
timotimo if a read on the hash table can cause it to change internally, we can no longer say concurrent read access is safe
jnthn My vague recollection of robin hood hashing is that a lookup in the hash might move things
samcv so in a linked list that is not an issue, only 'poisoned' buckets will be slower
jnthn: only insertion
jnthn OK. So long as we don't make read operations into write operations, it's OK. 21:46
We must be able to safely read from a hash that's not being mutated from many threads.
I must have misremembered what robin hood hashing does, so false alarm :)
samcv but the issue with open addressing is: you can make a timing attack, and just try to keep hitting the same area
and that is not totally avoidable. but we just need to make sure that it doesn't slow down non-poisoned sections 21:47
jnthn: though slightly a side note: this script spends almost all its time in garbage collection gist.github.com/84266a6b5fc34af0eb...0f5fc24937 21:49
67%
jnthn o.O 21:50
21:50 MasterDuke joined
jnthn That's...more than a little unusual 21:50
timotimo is there a lot of red and orange in the profiler's gc tab?
jnthn oh, wait...a million element hash?
samcv yes but that's not the main issue
timotimo does it take long to iterate over a hash that's mostly empty? 21:51
samcv every addition to the hash causes an allocation
of a new string
jnthn Right, that's not surprising.
Since hashes have string keys, so it has to coerce
samcv but the script adds a million items, then deletes every 2nd item. then adds them back, deletes every 3rd item, adds it back etc
timotimo right, because they all stick around
they all stick around, so they all go in the old generation
that means the nursery won't actually shrink much from doing a gc run 21:52
jnthn Yeah, that can indeed be a problem
timotimo same problem when you make a list of a few million Int objects
jnthn The second problem is that the hash keeps pointing to new nursery entries
And so it has to be walked in full every single GC run
static.googleusercontent.com/media.../43823.pdf 21:53
timotimo yeah, that would help
we'd know to immediately be allocating in the gen2 and would barely run gc at all 21:54
jnthn Indeed 21:56
samcv anyway this is the burn down a.uguu.se/XAA2lr4GjZfD.png 21:58
or flame graph
timotimo i'd assume it gets a little confused by the jit 21:59
samcv though not sure why it's doing MVM_coerce_n_s
since it should be an int
jnthn I said that a moment ago. Hash keys are always strings.
samcv ah
wait what does that have to do with nums?
timotimo we tend to "smart_numify" everything everywhere 22:00
and that makes nums
jnthn That's a good question. Probably NQP's fondness for nums...which we probably want to kill off.
samcv though you'd see something similar with MVM_coerce_i_s afaik
timotimo i'd like it to be gone
i'd say run it again with MVM_JIT_DISABLE
jnthn Yes 22:01
Hmm, why is so much time in gc_free which in turn calls HASH_ITER_FIRST_ITEM? 22:02
samcv well it must be doing something with a hash iterator. and that's the only that shows up because most are macros 22:03
jnthn If it was gc_mark I'd understnad it
samcv i haven't pushed HASH_ITER_FIRST_ITEM as a static inline
jnthn Because the GC has to iterate the hash
To know what's in it
free does too to free it but I don't see where the hash is freed
Unless at program termination but then it'd not be under MVM_coerce_n_s 22:04
Oh, the stack trace looks odd in other ways too
timotimo i think it's only below coerce_n_s because the jit confuses stack frames
jnthn Yeah, think you're right
Geth MoarVM: 4373eecdc5 | (Jonathan Worthington)++ | 4 files
Store deopt usage separate from normal usage

So that we can understand which things are kept alive for deopt and which are being used for real. There's no behavior change from this, it's simply making it clearer to see what lives only for the sake of deopt in the spesh log. However, keeping this information separately will allow us to do some further opts in the future.		 22:05
samcv well it looks pretty similar without jit
though you can test it yourself and maybe you'll notice more than me 22:06
jnthn Yeah, will have a look.
Something looks a bit off
As in, it feels like there's more going on that the things I know about
MasterDuke jnthn: you had some fix recently (related to inlining perhaps) that you said might be applicable to the profiler 22:07
samcv i mean i though the biggest issue with adding so many things to the hash would be having to FSA every hash entry and then freeing after removing. but it turned out differently 22:08
timotimo reading line annotation strings from the wrong compunit?
MasterDuke timotimo: that sounds plausible
samcv though it seems to create and destroy a crazy amount of hashes
since HASH_MAKE_TABLE is usually never visible 22:09
jnthn MasterDuke: Yes, timotimo would know if the profile also has that issue
timotimo i think that's not a problem as the instrumentation happens to the bytecode before spesh runs
so there won't have been inlines
samcv it's just when the hash expands since that happens many times for one hash, instead of once
jnthn afk for a bit
22:23 travis-ci joined
travis-ci MoarVM build failed. Jonathan Worthington 'Store deopt usage separate from normal usage 22:23
travis-ci.org/MoarVM/MoarVM/builds/401076856 github.com/MoarVM/MoarVM/compare/a...73eecdc556
22:24 travis-ci left 22:47 lizmat left

Powered by Cro and the Raku® Programming Language.

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

Thank you!