|
github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today Set by moderator on 19 May 2018. |
|||
|
01:17
Kaiepi joined
01:57
ilbot3 joined
|
|||
| moderator | github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today | ||
|
03:34
lizmat joined
05:37
shareable6 joined
07:51
domidumont joined
07:58
domidumont joined
|
|||
| lizmat | . | 09:34 | |
|
10:47
lizmat joined
|
|||
| ggoebel | japhb: I think your summary (irclog.perlgeek.de/moarvm/2018-05-..._16181160) is pretty much what the author of the article was saying... except that the author was pointing out that the existing prevailing cpu architecture while bound to provide some kind of backward compatible bridge to a legacy C model... is already significantly different. Spectre and Meltdown being examples of how the assumptions baked into C are | 11:04 | |
| oversimplification which gets things wrong. | |||
| reminds me of the quote "there is always a well-known solution to every human problem — neat, plausible, and wrong." -- H.L. Mencken | 11:05 | ||
|
11:26
shareable6 joined
11:37
brrt joined
|
|||
| brrt | good * #moarvm | 11:38 | |
| good news; i've replicated my dynasm issue on a small scale | |||
| (it is a label overflow issue, and these are the *worst*) | 11:39 | ||
| timotimo | i seem to recall | 11:41 | |
| it's a little like page breaking and footnotes and such | 11:42 | ||
| MasterDuke | timotimo: btw, where did you end up yesterday with that install-core-dist.pl thing? istr you had some ideas | 11:44 | |
| timotimo | i tried a thing that i thought would make things much better, which had no impact whatsoever, which is when i stopped | 11:45 | |
| MasterDuke | huh | 11:46 | |
| timotimo | my change was to make the search through the list end in setting the cached sc idx in the object | 11:47 | |
| so that we'd hopefully hit the cached path much more often | 11:48 | ||
| MasterDuke | so if that had no impact we're never looking up the same sc idx more than once? | 11:49 | |
| timotimo | it could be | 11:51 | |
| i think the bitmap approach for skipping empty entries more effectively could still help | |||
| samcv googles label overflow. gets results for wrapping text in CSS and text documents | 12:26 | ||
| timotimo | oh, that's weird | 12:28 | |
| irclog.perlgeek.de/moarvm/2017-08-31#i_15094824 | 12:29 | ||
| i think this is still the same basic issue, just a bit more devilish | |||
| brrt: how about we just insert some nops if we're not sure about this? | 12:30 | ||
| "just" :D | |||
| brrt | timotimo: it should not happen, period :-P | 13:05 | |
| timotimo | that's fair i suppose | 13:06 | |
| brrt | samcv: the problem is that x86 'jump' instructions can take one-byte, two-byte, or four-byte address offsets | 13:08 | |
| dynasm, in a vain attempt to be clever, tries to use the minimum amount of bytes | |||
| but there is a problem | |||
|
13:09
lizmat joined
|
|||
| brrt | if it uses e.g. 2 bytes rather than 1 byte for the 'jmp' offset, any labels after it move, as well | 13:09 | |
| the usual solution is to be pessimistic about how much space you'll need, and decrement if you need less | 13:10 | ||
| but somehow, that's not applied correctly here | |||
|
13:15
ggoebel joined
|
|||
| samcv | ah ok. makes perfect sense to me | 13:29 | |
| brrt | ok, there is something funky there with the encoding of rsp-relative registers that we are doing correctly, but for which we are not computing the offset correctly | 13:35 | |
| hmm. I can see it happen, but I have really no idea why :-( | 13:58 | ||
|
14:00
shareable6 joined
|
|||
| brrt | Hm... I can also disable that bit of cleverness, and it will work | 14:04 | |
| samcv | that's good at least | ||
| so the issue is the stack needs to be adjusted but it doesn't adjust right? | |||
| brrt | it might be a bit wasteful on code that uses a ton of tiny branches | ||
| it's the compilation of labels that goes wrong | 14:05 | ||
| basically, dynasm allows you to specify labels in a bunch of ways, and it will fix them up and link them | |||
| e.g. it will convert a label to 'jmp ->exit' to a 'jmp 0x1234' | |||
| samcv | is jmp relative or absolute? | 14:06 | |
| guessing it's relative which is why it can be variable bytes? | 14:07 | ||
| brrt | relative | 15:00 | |
| yeah | |||
| i'm of half a mind to get ourselves a better assembler... | 15:01 | ||
| samcv | well this seems to work. shifting the hash value by 0..31 | 15:15 | |
| not sure what to use to determine which bucket to use | |||
| i'm using tinymt to do it. and it has a random offset on creating the hash table. and on table expasnion it also chooses a random offset | 15:17 | ||
| no intellegent conflict resolution, though it should get a new offset on each table expansion so if we are getting conflicts in the buckets that should resolve them | 15:18 | ||
| and if not it'd prolly expand the buckets again and get another random offset | |||
| i gotta go out now, gonna do a PR if anybody wants to take a look | 15:22 | ||
| Geth | MoarVM: samcv++ created pull request #864: Rotate hash value randomly for each hash and on hash table expansion |
||
|
15:47
dogbert11 joined
|
|||
| brrt | hmm. i think i may have to do the increement trick earlier on in the process | 15:48 | |
| yeah, that must be it | 16:06 | ||
| MasterDuke | samcv: travis and appveyor are all red. missing include maybe? | 16:56 | |
|
17:58
shareable6 joined
18:07
lizmat joined
18:27
jsimonet joined
18:33
geekosaur joined
18:43
lizmat joined
18:44
Geth joined,
jsimonet joined
18:47
committable6 joined
|
|||
| samcv | oh nice. define hell | 19:12 | |
| yeah there's some weird things that happen when you go through multiple define's | |||
| this could be a different mistake though. but i know i had issues with what i thought should work. but doesn't | 19:13 | ||
| ok. forgot to commit one line | 19:14 | ||
| it does seem to make thing slower but i think that's wasting cycles getting a new pseudorandom number constantly which isn't really needed | 19:21 | ||
| gonna test again making it just increase the offset by 1 every time or something | |||
|
19:27
bloatable6 joined,
coverable6 joined,
releasable6 joined,
unicodable6 joined,
reportable6 joined,
statisfiable6 joined,
shareable6 joined
|
|||
| samcv | ok so i think i'm getting some overhead during the rotation operation. maybe there's a way i can optimize that | 19:30 | |
| ((hashv) << (rotate_num)) | ((hashv) >> ((sizeof(MVMhashv) * 8) - (rotate_num))) | |||
| ^ is what i'm doing | |||
| moritz | you can replace the * 8 by a bitshift, but I guess a compiler will do that for you anyway | 19:32 | |
| samcv | yeah. i'm guessing the sizeof(MVhashv) * 8 will be optimized away to a static number | ||
| en.wikipedia.org/wiki/Circular_shi...lar_shifts apparently cpu's have instructions that do this | 19:34 | ||
| well what they recommend is a little different | 19:35 | ||
| ok i seem to have gotten it to compile down properly | 20:01 | ||
| moritz: MasterDuke, it seems the issue is me not using static values. though i'm loathe to hardcode it based on the input size, though i guess i can just add an assert | 20:05 | ||
| hmm or maybe there's a different way. dunno | 20:07 | ||
| guess i'll make a function for that then and move it out of uthash.h | 20:17 | ||
|
21:40
squashable6 joined
|
|||