|
🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm Set by lizmat on 8 June 2022. |
|||
| MasterDuke | ab5tract: but isn't that what the GC is for? to handle stuff that's thrown away so it doesn't leak? | 00:12 | |
| ab5tract | MasterDuke: yes, but why does it have more work to do on later iterations than early iterations if each iteration has ~X items to collect? | 07:03 | |
| japhb | ab5tract: Haven't looked at your code yet, but one thing that would make later GC iterations take longer is if something was leaking from the nursery to the older GC generation. GC runs usually go a series of short-ish nursery-only runs, followed by a longer "full" GC, which includes the entire older generation. If that older generation grows, it will need to do more work every GC cycle. | 07:11 | |
| ab5tract | Also, I would expect splice calls to automatically reuse the continuous memory segments of an array under the hood by shifting memory contents left and leaving some threshold length of free slots at the end, instead of actually re-shaping each time. apparently this should be cheaper | 07:12 | |
| *this should be cheaper according to Bjarne Stroustrap | 07:17 | ||
| www.youtube.com/watch?v=YQs6IC-vgmo | |||
| japhb: thanks for the pointers! ;) | 07:22 | ||
| japhb: looks like you were correct. the arrays weren't as bounded as I thought. | 07:33 | ||
|
08:20
MasterDuke left
09:06
sena_kun joined
09:38
Nemokosch joined,
Nemokosch left
11:31
vrurg_ left
|
|||
| ab5tract | that moment when you realize an unless should have been an if | 12:31 | |
|
14:04
Altai-man joined,
sena_kun left
14:09
vrurg joined
|
|||
| japhb | D'oh | 15:47 | |
|
19:40
kawaii left
19:41
kawaii joined
|
|||
| ab5tract | conclusion from all that: there is nothing wrong with the approach I was taking, my code had a subtle bug which meant compaction was never actually running, thus the arrays weren't being spliced and objects were leaking into the old generation pool (japhb++) | 19:49 | |
| Raku's GC can handle keeping up with 59fps with the number of objects the code is splicing | 19:51 | ||
| .vushu | A good GC benchmark 😃 | 19:52 | |
| btw if I want to contribute to rakudo what is the recommended step to take? | 20:15 | ||
| [Coke] | raku.org/community/ - two flavors of getting involved. | 20:20 | |
| .vushu | Thanks I will take a look at it. | 20:32 | |
| ab5tract | .vushu: I tried to create a bit of an onramp to contributing to RakuAST, which is the current rewriting of the compiler frontend: www.youtube.com/watch?v=pzLOZByxNpc | 21:28 | |
| .vushu | .ab5tract ah nice thanks I will definitely take a look at this! 😊 I began developing interest in compilers and wan't to contribute to Raku, since the language began to grow on me. | 21:34 | |
| ab5tract | awesome! you might find this enlightening: github.com/edumentab/rakudo-and-nq...als-course | 21:37 | |
| a bit old but still very relevant | |||
| .vushu | Cool I will add it to my learning curriculum 😀 | 21:39 | |
| ab5tract | enjoy! | ||
| .vushu | Will do! 👍 | 21:40 | |
|
23:09
Altai-man left
|
|||