|
02:38
librasteve_ left
08:57
sena_kun joined
|
|||
| timo | has anyone used Grammar::Debugger or Grammar::Tracer recently? | 10:33 | |
| lizmat | about a year ago, when I started the =rakudoc handling, why ? | 10:47 | |
| did it bitrot? | |||
| notable6: weekly | 10:48 | ||
| notable6 | lizmat, 1 note: 2024-12-10T12:59:58Z <antononcube>: rakuforprediction.wordpress.com/20...aku-set-3/ | ||
| lizmat | notable6: weekly reset | ||
| notable6 | lizmat, Moved existing notes to “weekly_2024-12-23T10:48:43Z” | ||
| timo | i'm not entirely sure. i seemed to recall it didn't work when i last tried it? two months ago or so maybe | 10:49 | |
| lizmat | It's a Raku Community module now | 10:52 | |
| so go for it :-) | |||
| I can give you a zef upload bit if necessary | 10:54 | ||
| timo | i kind of wish we had a common standard way for module authors to put benchmarks in their distros, maybe in xt/, for the purposes of measuring long-time changes in rakudo and moarvm performance | 11:04 | |
| so we could do something similar to a blin run, but for benchmarks found in ecosystem modules | 11:05 | ||
| lizmat | bt/ ? | 11:06 | |
| timo | .o( backtraces ) | 11:07 | |
| lizmat | I was thinking "benchmark tests" | 11:12 | |
| timo | what i'd like to see at the very least is standardised ways to handle setup and teardown, and a way to specify size of the "workload" to check how scaling behaves, and maybe a rough guideline to create essentially an estimation for what workload size corresponds to what run time. also it'd be important to consider multithreading and multi-processing in this, as well as necessary external | ||
| components. say, a postgres database has to be running in order to sensibly benchmark a postgres client library, i imagine | |||
| and we probably want to measure some performance counters instead of wallclock time, since other activity on the system that runs the benchmark can easily make timing data become worthless :) | 11:31 | ||
| lizmat | in that respect I would love to see cpu time / thread metrics | 11:33 | |
| timo | most performance counters can be impacted by other stuff on the system; i think if there's more load, the program may be context-switched away more often, CPU caches evicted causing an increase in cache misses, stuff like that :| | 11:35 | |
| i guess if we have to ensure whatever the "benchmark runner" is doesn't get distracted :) | 11:36 | ||
| then we can also use cpu time for measurement | |||
| lizmat | and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/12/23/2024-...-the-dots/ | 11:57 | |
| patrickb | I've used Grammar::Tracer recently when creating Rainbow. worked like a charm. | 13:06 | |
| timo | oh, ok that's good! | 13:07 | |
| lizmat | ab5tract: I wonder whether we should allow "is revision-gated" as well, indicating the lowest language level being supported | 16:04 | |
| ab5tract | That’s how I originally implemented it but nine didn’t like that | 16:08 | |
| lizmat | ah, ok :-) | ||