[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 [05:22] good *, #moarvm [06:01] *** Altai-man_ joined [06:04] *** sena_kun left [07:29] *** zakharyas joined [08:03] *** sena_kun joined [08:04] *** Altai-man_ left [09:19] morning o/ [09:21] \jnthn [09:21] \o [09:21] (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 [14:45] *** AlexDani` is now known as AlexDaniel [14:46] *** AlexDaniel left [14:46] *** AlexDaniel joined [14:58] ¦ MoarVM/hash-cleanup-MVP: 39 commits pushed by (Nicholas Clark)++ [14:58] ¦ MoarVM/hash-cleanup-MVP: review: https://github.com/MoarVM/MoarVM/compare/263239406129^...77436250eca1 [14:58] from the department for "I can't believe it doesn't SEGV" [14:58] it's not just "It compiles; ship it" [14:59] but it's not done yet. [14:59] jnthn: that still has those assert in it. I've not cleaned them up yet. [15:02] That and The Pain! [15:02] I rebased that commit to HEAD [15:02] it was about 37 [15:02] and likely to get lost [15:03] cleanup slight undersells what this branch does :) [15:04] er [15:04] *slightly [15:04] most of it is getting to the good place [15:04] last 2 commits are the reasonable part [15:04] turned out that I didnb't have lvalue_fetch implemented in the new thing yet [15:04] so need to do that [15:04] so [15:04] 1) lvalue fetch [15:04] 2) iterators [15:04] 3) randomisation [15:04] and then [15:05] it's probably good to consider merging [15:05] but there are a couple more optimisations that could go in [15:05] 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. [15:05] if we think that this is a good direction. [15:09] *** dogbert17 left [15:10] *** Kaeipi joined [15:10] *** patrickb joined [15:13] *** vesper joined [15:14] *** elcaro_ joined [15:14] *** vesper11 left [15:14] *** [Coke]_ joined [15:14] *** [Coke]_ left [15:14] *** [Coke]_ joined [15:14] *** dogbert17 joined [15:17] *** synthmeat joined [15:23] (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:24] 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) [15:43] 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 [15:44] hmmm... not sure what the reason is [15:45] 39 commits down, still have a few more to create [15:45] completely reworking the hash code [15:47] because reworking the hash code is more useful ? [15:47] we'll see when we get to the point of benchmarking it [15:47] but I think that it already halves the memory overhead [15:48] (the memory the hash structures need. the deadweight) [15:48] that would be way cool [15:49] I think regex captures would *really* benefit from the way that some javascript compilers optimize hashes [15:49] 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 [15:49] moritz: and how is that ? [15:49] that is, they create anonymous classes with attributes that correspond to the keys [15:49] jnthn: yes, but right now it's using two so that ASAN can hate me more. [15:50] so that they get a very compact storage for precisely the current hash [15:50] Two blobs? [15:50] moritz: so implicit pseudo-hashes under the hood :-) [15:50] yes [15:50] lizmat: right [15:50] and in regexes, the combinations of keys in those matches would probably be pretty low [15:50] This should help a lot with the whole concurrent hash abuse crasehs too. [15:50] *crashes [15:50] 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. [15:51] OK, nice [15:51] jnthn: sadly I think not. because open adress hashes move elements around when they insert or delete elements. [15:51] And then when we're using the FSA we can do the whole free at safepoint dance, and yay, safety :) [15:51] nwc10: We don't have to give correct answers. We just have to not SEGV. [15:51] so any inserts on thread A will move things around for thread B's reader [15:52] That's fine so long as they don't read outside of the memory block, though? [15:52] we will SEGV. I managed to make the hash fsck code SEGV by having inconsistent shapes [15:52] Ah, darn. [15:52] yes, probably darn [15:52] lets get to Minimum Viable Product [15:52] and then see what else can be optimised/improved [15:52] it doesn't yet do everything that the current code does. [15:53] 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 [21:07] ¦ MoarVM/hash-cleanup-MVP: 5 commits pushed by (Nicholas Clark)++ [21:07] ¦ MoarVM/hash-cleanup-MVP: 63baa73329 | Re-implement MVMUniHashTable as a Robin Hood Hash. [21:07] ¦ MoarVM/hash-cleanup-MVP: a1d13eed3b | Re-implement MVMIndexHashTable as a Robin Hood Hash. [21:07] ¦ MoarVM/hash-cleanup-MVP: f352a5c195 | Refactor MVM_uni_hash_insert in terms of MVM_uni_hash_lvalue_fetch. [21:07] ¦ MoarVM/hash-cleanup-MVP: 4e503a456c | Re-implement MVMPtrHashTable as a Robin Hood Hash. [21:07] ¦ MoarVM/hash-cleanup-MVP: f638928418 | XXX To the pain! [21:07] ¦ MoarVM/hash-cleanup-MVP: review: https://github.com/MoarVM/MoarVM/compare/77436250eca1...f6389284189b [21:07] a bug fix - utter daftness with the bucket shift, exposed by trying to build the new code on arm [21:07] (Which has different semantics for shifting by an amount larger than the size of the integer) [21:08] 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 [23:51] *** AlexDaniel left [23:51] *** AlexDaniel joined