|
Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes. Set by lizmat on 24 May 2021. |
|||
| lizmat | timo what is the cutoff point for in-situ strings again? | 09:54 | |
| feels to me those strings wouldn't need interning? | |||
| nine | They still would | 10:05 | |
| The interning is also to avoid duplication of those strings in the mbc files | |||
| Of those HLL Str objects. The low level strings are deduplicated anyway | 10:06 | ||
| lizmat | ok | 10:10 | |
| the current interning logic in RakuAST limits the number of interned strings to 64K | |||
| that feels... arbitrary ? | 10:11 | ||
| nine | I guess it's a reasonable compromise. It prevents excessive memory usage in extreme cases. 64k string constants is a lot | 10:17 | |
| timo | i only now realize that we were growing the synthetics table by 32 elements every time, so once you reach the few thousands, that's where you spend most of your time, copying the existing elements to the new array | 17:20 | |
| [Coke] | oops | 17:23 | |
| lizmat | doesn't that apply to any array that is being filled up ? | ||
| xiaomiao | usually you would grow things by a proportional factor, not a constant | 17:26 | |
| nine | Well there's still the question whether in this case observations about the past are a good predictor for the future. | 17:28 | |
| timo | indeed | ||
| in MVMArray we're currently growing proportionally up to a specific size and then linearly, which i don't like very much | |||
| in the case of the nfg synthetics table, we really grew by the same fixed number every time we needed to bump | 17:29 | ||
| lizmat | timo: fwiw, is that growing of the nfg synthetics table threadsafe ? | ||
| timo | yes, it is extremely threadsafe | ||
| lizmat | *phew* nice! | ||
| timo | normally, a program would encounter maybe a hundred or even two hundred synthetic graphemes in its time. more if it handles emojis a lot since they tend to have the skin tone modifiers and there's a few ones that have many codes in them like the family ones i think? | 17:30 | |
| nine | And of course, this being IT, every problem can be solved by adding another layer of indirection. In this case maybe an array of pointers to 32-element arrays? That would drastically reduce the number of reallocations (since you only need to reallocate the top level array) at the expense of one more pointer to chase per lookup | 17:31 | |
| timo | but here comes | ||
| À̅̀͐À̅̀͑À̅̀͒À͓̅̀À͔̅̀À͕̅̀À͖̅̀À̅̀͗À̅̀͘À͙̅̀À͚̅̀À̅̀͛À̅̀͜À̅̀͝À̅̀͞À̅̀͟À̅̀͠À̅̀͡À̅̀͢À̅̀ͣÀ̅̀ͤÀ̅̀ͥÀ̅̀ͦÀ̅̀ͧÀ̅̀ͨÀ̅̀ͩÀ̅̀ͪÀ̅̀ͫÀ̅̀ͬÀ̅̀ͭÀ̅̀ͮÀ̅̀ͯÀ̅́̀À̅́́À̅́̂À̅́̃À̅́̄À̅́̅À̅́̆À̅́̇À̅́̈À̅́̉À̅́̊À̅́̋À̅́̌À̅́̍À̅́̎À̅́̏À̅́̐À̅́̑ | |||
| À̅́̒À̅́̓À̅́̔À̅́̕À̖̅́À̗̅́À̘̅́À̙̅́À̅́̚À̛̅́À̜̅́À̝̅́À̞̅́À̟̅́À̠̅́À̡̅́À̢̅́Ạ̀̅́À̤̅́Ḁ̀̅́À̦̅́À̧̅́Ą̀̅́À̩̅́À̪̅́À̫̅́À̬̅́À̭̅́À̮̅́À̯̅́À̰̅́À̱̅́À̲̅́À̳̅́À̴̅́À̵̅́À̶̅́À̷̅́À̸̅́À̹̅́À̺̅́À̻̅́À̼̅́À̅́̽À̅́̾À̅́̿À̅́̀À̅́́À̅́͂À̅́ | |||
| :̓ | |||
| the nfg is built as a trie already | 17:32 | ||
| you use the table to go from number to codes, you use the trie to go from codes to number | |||
| adding a new entry creates new nodes in the trie, and a new entry in the table | |||
| Performance counter stats for 'rakudo -e my @combs = (0x300..0x36f)>>.chr; for ("A" X~ @combs X~ @combs X~ @combs X~ @combs).rotor(100) { .join("").say };': | 17:35 | ||
| 546.17 msec task-clock # 0.038 CPUs utilized | |||
| ^- rakudo spent 96% time waiting for STDOUT to drain to my terminal emulator | 17:36 | ||
| i think i want to file a bug with the terminal emulator about that haha | 17:43 | ||
| 95.08% 0.19% konsole libkonsoleprivate.so.25.04.0 [.] Konsole::Screen::displayCharacter(unsigned int) | 17:55 | ||