| timo | I threw tsan at rakudo and I've been trying to figure out if I can do something about any of the data races it's reporting; there's surely some that aren't a problem because the rest of the system is built to take them into account | 00:13 | |
| but I don't know enough about the nitty-gritty details of atomics and memory models to figure all of that out | 00:14 | ||
|
00:32
kjp left
00:33
kjp joined
00:35
kjp left,
kjp joined
10:50
sugarbeet left
11:00
sugarbeet joined
12:05
Nicholas left
13:06
Nicholas joined
|
|||
| lizmat | hmmm ... looking with a fresh eye at ParaSeq code, found this: | 13:51 | |
| if nqp::atomicload_i($!unhandled) { | |||
| nqp::atomicdec_i($!unhandled); | |||
| I assume that's a race condition, right ? | |||
| timo | indeed, you would want to have a compare-and-set, or depending on what exactly the rest of the code does, use the result from an unconditional decrement? | 13:52 | |
| sorry, compare-and-swap is the correct term | 13:53 | ||
| there's also test-and-set which is a similar kind of thing | 13:55 | ||
| lizmat | right | ||
|
14:02
apogee_ntv joined
|
|||
| lizmat | not really in the right mindset for this atm.. will look at it tonight... | 14:04 | |
| looks like in interesting underlying library: raku.land/zef:apogee/CRoaring | 17:58 | ||
| apogee_ntv | Yeah it's great, the API is really clean too. | 17:59 | |
| lizmat | does it build on Windows ? | 18:00 | |
| apogee_ntv | It's used in most high perf tag search engines via various levels of indirection. | ||
| With great difficulty. | |||
| lizmat | meh | ||
| apogee_ntv | It doesnt help that I don't know the Windows C ecosystem at all, so I don't even really know how to do a Build script for it. | 18:01 | |
| My guess is if you have mingw it will probably be fine | 18:02 | ||
| raku.land/zef:apogee/Roaring::Tags I mostly wrapped it to build this | 18:06 | ||
| lizmat | well, feels like this might be a useful addition to the MoarVM core | 18:14 | |
| but **only** if it can be built on Windows | |||
| apogee_ntv | I will try to take a look at how to build on Windows later today or tomorrow. I should be able to spin up a VM. | 18:22 | |
| lizmat | ++apogee_ntv | 18:24 | |
| apogee_ntv | What compiler should I be testing on? Best to use what's used in the moarvm release process? | 18:25 | |
| lizmat: Looks like it builds fine, just have to make a defs file for the symbols you want to export: github.com/m-doughty/CRoaring-Raku...0301908884 | 18:38 | ||
| lizmat | and now I wonder how easy it could be made to support 1, 2, 4 bit native (shaped) arrays | 18:39 | |
| timo | i'm not sure this can do what you want it to | 18:41 | |
| lizmat | ah... ok | ||
| timo | it only stores a large one bit array very efficiently | ||
| lizmat | right... | 18:42 | |
| timo | you can't have the same number twice, or store an order of the numbers | ||
| lizmat | hmmm...in that light: ah... ok, I guess I shoulda've read the docs :-) sorry for the noise here | ||
| timo | i assume the algorithm doesn't generalize to multisets (which would allow one value to appear multiple times) or ordered sets (so you can have an order of items stored) | 18:43 | |
| lizmat | Otoh, I wonder if this could be of use in regexes ? | ||
| timo | it could still be interesting for our unicode database | ||
| lizmat | right | ||
| timo | yeah, in regexes for character classes / sets | ||
| lizmat | replace several deep hash lookups by a single bit union? | ||
| timo | hm? | 18:44 | |
| lizmat | nvm... I would need to think about this more | 18:45 | |
| timo | which hashes were you thinking of? | ||
| lizmat | the uniprop ones ? | 18:49 | |
| timo | ah, I'm not sure we have nested hashes there, isn't it mostly one huge flat table? | 18:50 | |
| after you go from a name of the property to an index, i think that's where hashes end | 18:51 | ||
| lizmat | ah... ok... that makes sense | 18:52 | |
| ShimmerFairy is probably the most up-to-date in that area nowadays ? | 18:53 | ||
| timo | not all properties are bits, of course, but in theory you can just assign multiple consecutive bits to a single property of a single codepoint, but then the operations like and/or/xor and such are perhaps not meaningful / useful any more | 18:56 | |
| lizmat | yeah... also makes sense :) | ||
| timo | i'm not saying there's nothing to be gained though | ||
| with an ahead-of-time-known set of values you can also look into Perfect Hashing | 19:00 | ||
| not sure how well it applies to unicode properties though | 19:01 | ||