02:48
ilbot3 joined
04:21
brokenchicken joined
06:07
geekosaur joined
06:45
TimToady joined
09:22
TimToady joined
11:09
domidumont joined
11:15
domidumont joined
|
|||
jnthn | I'm guessing wildly about phones here, but it may be that multiple slower cores is more power-efficient (or easier to do power-management on) than one really fast core. Perhaps ditto for heat. Both matter plenty for phones. | 11:34 | |
Geth | arVM/master: 6 commits pushed by jnthn++ | 11:45 | |
arVM: cc8a133a28 | MasterDuke17++ | 5 files Fix format strings that warn during compile Change to the suggested types+modifiers. |
|||
arVM: ac79dfb2a6 | (Jonathan Worthington)++ | 5 files Merge pull request #501 from MasterDuke17/fix_warnings_during_compile Fix warnings during compile |
|||
timotimo | a veritable deluge of mails directly after the release :) | 11:51 | |
jnthn | :) | 11:54 | |
timotimo didn't read the PR description of inactivate-async-tasks until now | 12:20 | ||
interesting | |||
managing memory is difficult, yo | 12:23 | ||
jnthn | Indeed. | ||
Anyway, with that merged we should see a lot less leaks in thing using Proc::Async and friends. | |||
timotimo | i mean ... virtual memory means that if the array grows unboundedly and we never touch the slots near the beginning, and make sure to null them out properly, they'll just be dedup'd :P | 12:24 | |
jnthn | haha | 13:15 | |
That's horrible, but yes :P | 13:16 | ||
We'll still fix it though, it's good for locality :) | |||
timotimo | aye | 13:17 | |
interesting. that "riptide" gc does its "draining" (aka DFS to set marking bits) in parallel without considering what thread an object belongs to, and they CAS the mark bits in parallel | |||
(extra bonus: the words "parallel" line up in my terminal right there | |||
) | |||
dogbert17 | o/ | 14:37 | |
deafening silence :) | 14:38 | ||
m: class SQLString { }; my $stringy = Str.^find_method("Stringy"); my $handler = $stringy.wrap(method () { SQLString.new(:str(callsame)) }); say "foo".Stringy # should this loop indefinitely? | 14:39 | ||
camelia | rakudo-moar 8a6bfc: OUTPUT«(timeout)» | ||
14:57
Ven joined
|
|||
dogbert17 | and another question, what does this message mean? MoarVM panic: Zeroed owner in item added to GC worklist | 15:16 | |
Geth | arVM: MasterDuke17++ created pull request #510: Change tabs to spaces |
15:25 | |
samcv | guys so our strings aren't always stored in one long string or they are? looking at how we find a needle's inside haystack | 15:40 | |
we just call MVM_string_substrings_equal_nocheck which does memcmp(a->body.storage.blob_8 + starta,..) | |||
so it would seem as if they are continuous regions of memory? or is there something i'm not seeing | |||
timotimo | oh hey samcv :) | 15:43 | |
samcv | hey | ||
timotimo | strings can be "ropes" | ||
MasterDuke | samcv: i don't know much about the internal representation, but if you're planning on working on string searching you might be interested in github.com/MasterDuke17/MoarVM/tre..._for_index | ||
timotimo | which is a list (can be a tree) of references to other strings including offset and length | ||
looking forward to you commenting on my PR on UCD, samcv :) | 15:45 | ||
samcv | yeah about tho check it out now | ||
timotimo | but the next ~hour&half will be spent on the road and i should really rather not stare at screens, lest i projectile-vomit people to death | ||
samcv | hah | ||
timotimo | we're still waiting on one person, though | 15:46 | |
samcv | i think switching to memmem instead of memcmp would bring us a pretty big improvement | 15:48 | |
also i'm not sure how we get different locations comparing how we are doing, in case it uses ropes or something | |||
timotimo | i wasn't aware of memmem, actually | 15:52 | |
substrings_equal_nocheck will fall back to grapheme iterators if one of the strings is a rope | 15:53 | ||
i'd expect memcpm to be as fast as memmem, as memcmp can already abort when a single byte differs | 15:54 | ||
oh | 15:56 | ||
"C's memcmp is actually pretty slow because it tries to preserve useful string comparison semantics" - sounds like the writer of this SO question confused memcmp with strcmp? | |||
oh wait a minute | 15:58 | ||
substrings_equal_nocheck isn't about "where in this string is another string", it's about "is the n graphemes after offs equal to the first(?) n graphemes in the other" | 15:59 | ||
but yeah, finding a string in another would be right for memmem | |||
okay, time to drive | 16:00 | ||
samcv | see ya soon | 16:03 | |
timotimo | re | 17:28 | |
i see you didn't comment on my cod e:S | 17:29 | ||
samcv | timotimo, will soon. have a question, is it able to parse multiple 0 values for one base 40 int? | 18:34 | |
like if we have 3 codepoints with no name in a row, that would be value 0. | |||
so we can save a lot of space by not having to use three 0's and just have one | |||
18:58
geekosaur joined
|
|||
timotimo | how often do codepoints not have names? | 19:04 | |
it doesn't currently handle that, but it totally can | |||
iirc i keep the state around for the Decoder | |||
so it keeps the queue, and there's the eos_signaled bit that could perhaps have something to do with this | |||
samcv: ^ | |||
samcv | uhm | 19:05 | |
timotimo | i'm currently attending the Anime Season Kickoff Frenzy, in which many first episodes of anime shows are being shown | ||
not really able to communicate a bunch | 19:06 | ||
samcv | ah kk. well looks like we're ignoring blank characters. but i think there are enough that we should just treat it as a stream of data to be decoded | ||
shouldn't require too much change, but basically if we see a 0 in the highest place, then we still need to retain the smallest place which is a number, or if there's multiple 0's places then we need to assign to a diff cp | 19:07 | ||
timotimo | right. we already don't have "places" any more when we're looking through them | 19:08 | |
i.e. the queue already contains the up-to-40 numbers as individually addressable things in the queue | 19:09 | ||
and we can pull individual ones out | |||
samcv | yeah | ||
timotimo | so when we get three 0s, it'll be fine to take a single one for each call to nom_a_string | 19:10 | |
of course it'[l have to go into the encoding part, too | 19:13 | ||
maybe it'd | |||
be interesting to adopt a queue-like approach to the code that encodes | |||
samcv | yeah. gotta adjust the encoding part | ||
timotimo | so we'll split the code that wants to emit up-to-40-numbers from the code that takes care to take triplets of it and makes 16bit numbers | ||
it'll also handle setting up the very last bit | 19:16 | ||
samcv | i will make a function which we just push our strings to, and then we call at the end to get our hash table | 19:17 | |
err not hash table, but uh, array | |||
timotimo | that sounds doable | 19:18 | |
it'd be nice if we could generalize the code for generating compressed stuff so we could also use different tables to generate the sequence names | 19:28 | ||
samcv | ah | ||
yeah | |||
timotimo | we can put the character table and the level one (and more) tablet behind pointers that live in the decoder in the C code | 19:29 | |
so we can just switch them out to decode other stuff, like sequence names | 19:30 | ||
samcv | unless $no-empty # yeah this is the variable that needs to be true to begin generating null names | ||
yea | |||
should also factor in the memory we lose by storing the string, and maybe those strings should be encoded? (the shift levels?) | 19:31 | ||
timotimo | could definitely do that | 19:32 | |
we might have to make the queue longer then, so that we can just decode a whole second-level string into it at any time | 19:33 | ||
otherwise we'd have to store more state in the decoder to tell when we're in a second-level string and how long it'll go for | |||
*shrug* | |||
samcv | yeah | 19:34 | |
timotimo | but since the Decoder will live on the stack (since it doesn't have to be long-lived ever) it can be big | 19:35 | |
20:28
domidumont joined
21:41
zakharyas joined
22:10
BinGOs joined
|