github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:02 sena_kun joined 00:04 Altai-man_ left 02:01 Altai-man_ joined 02:04 sena_kun left 04:02 sena_kun joined 04:04 Altai-man_ left
nwc10 good *, #moarvm 05:22
06:01 Altai-man_ joined 06:04 sena_kun left 07:29 zakharyas joined 08:03 sena_kun joined 08:04 Altai-man_ left
jnthn morning o/ 09:19
moritz \jnthn 09:21
nwc10 \o
moritz (there are now vowels in jnthn, so adding an o seems wrong) :D
10:02 Altai-man_ joined 10:04 sena_kun left 11:02 squashable6 joined 11:36 zakharyas left 12:03 sena_kun joined 12:04 Altai-man_ left 12:48 zakharyas joined 12:59 AlexDani` left 14:01 Altai-man_ joined 14:04 sena_kun left 14:45 AlexDani` joined, AlexDani` is now known as AlexDaniel 14:46 AlexDaniel left, AlexDaniel joined
Geth MoarVM/hash-cleanup-MVP: 39 commits pushed by (Nicholas Clark)++
review: github.com/MoarVM/MoarVM/compare/2...436250eca1		 14:58
nwc10 from the department for "I can't believe it doesn't SEGV"
it's not just "It compiles; ship it"
but it's not done yet. 14:59
jnthn: that still has those assert in it. I've not cleaned them up yet.
jnthn That and The Pain! 15:02
nwc10 I rebased that commit to HEAD
it was about 37
and likely to get lost
jnthn cleanup slight undersells what this branch does :) 15:03
nwc10 er 15:04
jnthn *slightly
nwc10 most of it is getting to the good place
last 2 commits are the reasonable part
turned out that I didnb't have lvalue_fetch implemented in the new thing yet
so need to do that
so
1) lvalue fetch
2) iterators
3) randomisation
and then
it's probably good to consider merging 15:05
but there are a couple more optimisations that could go in
also, much of the earlier commits in it (right up to the ones that take randmoisation *out*) could be reiviewed and cherry-picked right now.
if we think that this is a good direction.
15:09 dogbert17 left 15:10 Kaeipi joined, patrickb joined 15:13 vesper joined 15:14 elcaro_ joined, vesper11 left, [Coke]_ joined, [Coke]_ left, [Coke]_ joined, dogbert17 joined 15:17 synthmeat joined
nwc10 (what you don't have there is the development code and its regression tests. Which have a bit more stuff implemented that's not yet ported) 15:23
anyway, works on "my" machine, and my machine 15:24
we run on both kinds of OS - debian and raspbrian. (er, oh, Raspberry Pi OS, or whatever it rebranded to)
samcv: and that's why I've been asking all these stupid questions :-) 15:43
lizmat: and that's why I don't want to rewrite ucd2c.pl
lizmat hmmm... not sure what the reason is 15:44
nwc10 39 commits down, still have a few more to create 15:45
completely reworking the hash code
lizmat because reworking the hash code is more useful ? 15:47
nwc10 we'll see when we get to the point of benchmarking it
but I think that it already halves the memory overhead
(the memory the hash structures need. the deadweight) 15:48
lizmat that would be way cool
moritz I think regex captures would *really* benefit from the way that some javascript compilers optimize hashes 15:49
jnthn nwc10: This also, iiuc, gets us to it being a single blob of memory for the table, no linked lists, etc?
15:49 nebuchadnezzar joined
lizmat moritz: and how is that ? 15:49
moritz that is, they create anonymous classes with attributes that correspond to the keys
nwc10 jnthn: yes, but right now it's using two so that ASAN can hate me more.
moritz so that they get a very compact storage for precisely the current hash 15:50
jnthn Two blobs?
lizmat moritz: so implicit pseudo-hashes under the hood :-)
nwc10 yes
moritz lizmat: right
and in regexes, the combinations of keys in those matches would probably be pretty low
jnthn This should help a lot with the whole concurrent hash abuse crasehs too.
*crashes
nwc10 jnthn: yes, there are two malloc() calls right next to each other. It's trivial to replace them with 1 malloc() call (would actually be a call to the FSA) and then calcuate the sceond ponter.
jnthn OK, nice 15:51
nwc10 jnthn: sadly I think not. because open adress hashes move elements around when they insert or delete elements.
jnthn And then when we're using the FSA we can do the whole free at safepoint dance, and yay, safety :)
nwc10: We don't have to give correct answers. We just have to not SEGV.
nwc10 so any inserts on thread A will move things around for thread B's reader
jnthn That's fine so long as they don't read outside of the memory block, though? 15:52
nwc10 we will SEGV. I managed to make the hash fsck code SEGV by having inconsistent shapes
jnthn Ah, darn.
nwc10 yes, probably darn
lets get to Minimum Viable Product
and then see what else can be optimised/improved
it doesn't yet do everything that the current code does.
jnthn Yeah. I think this design is certainly more likley to be fixable than the previous one. 15:53
Though maybe at a slight cost
16:03 sena_kun joined 16:04 Altai-man_ left 17:26 zakharyas left 17:37 patrickb left 17:40 patrickb joined 18:02 Altai-man_ joined 18:05 sena_kun left 18:56 Merfont joined 18:57 Kaeipi left 19:11 zakharyas joined 19:29 MasterDuke joined 19:30 [Coke]_ is now known as [Coke] 20:02 sena_kun joined 20:05 Altai-man_ left 20:25 zakharyas left 21:00 MasterDuke left
Geth MoarVM/hash-cleanup-MVP: 5 commits pushed by (Nicholas Clark)++ 21:07
nwc10 a bug fix - utter daftness with the bucket shift, exposed by trying to build the new code on arm
(Which has different semantics for shifting by an amount larger than the size of the integer)
IIRC it's all undefined behaviour. I certainly wasn't meanign to do it 21:08
and ptr_hash_table.h etc is now the new fangled thing.
21:57 [Coke] left 22:01 Altai-man_ joined 22:05 sena_kun left 22:35 [Coke] joined 22:37 squashable6 left 22:41 squashable6 joined 23:12 patrickb left 23:30 AlexDaniel left 23:51 AlexDaniel joined, AlexDaniel left, AlexDaniel 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!