| masak read that as "party-initialized callsites" | 03:20 | ||
|
03:24
TimToady joined
03:25
vendethiel joined
05:39
vendethiel joined
06:23
xiaomiao joined
07:23
vendethiel joined
07:29
FROGGS joined
07:50
vendethiel joined
08:11
domidumont joined
08:17
domidumont joined
08:25
zakharyas joined
09:58
leont joined
|
|||
| timotimo | it didn't really look like the benchmarks improved between yesterday and today (with regards to how well rakudo is doing) | 10:07 | |
| i tried to look out for the hash optimizations lizmat put in, but they weren't obvious | 10:08 | ||
| jnthn: you don't keep the timings .json files around, do you? | |||
| jnthn | um...they may be somewhere...don't copy them anywhere yet | 10:35 | |
| timotimo | normally you get multiple ones by virtue of extracting individual commit ids and getting one folder per build-folder as well as one folder (or json file?) per thingie | 10:47 | |
| but since you just build over "master" every time, that'll not happen, i expect | |||
| but i do think the json files gobble up more and more info the more they are "used" | 10:48 | ||
| rr-project.org/ - did i see this link here or somewhere else? | |||
| wow, liz says your optimizations and memory-leak-plugging for moarvm "could have dramatical memory savings for some applications" | 10:49 | ||
| i didn't realize it was this big of a deal | |||
| jnthn | timotimo: There was a serious I/O leak that could affect programs that did many slurps. | 10:53 | |
| Rest ranged from "minor leak" down to "missing cleanup at shutdown" | 10:55 | ||
| timotimo | ah, i see! | 10:58 | |
|
12:07
domidumont joined
12:43
cognominal joined
13:43
zakharyas joined
13:57
brrt joined
|
|||
| brrt | good * | 14:08 | |
| hey timotimo, that rr thing, looks really cool :-) | |||
| timotimo | i wonder how unhappy things like a GC collection make that | 14:10 | |
| brrt | hmm | 14:18 | |
| isn't gc pretty deterministic? | |||
| i mean, most JIT crashes are pretty deterministic | |||
| you run over a threshold after a certain allocations, and that typically always happens | 14:19 | ||
| timotimo | well, i just mean it has to track all this data so that reversing/replaying works properly, no? | 14:24 | |
| i actually have no clue how this thing works :) | |||
| brrt | neither do i | ||
| my suspicion: | 14:25 | ||
| - copy all disk io | |||
| timotimo | i just mean the semi-space copying gc will cause a lot of churn | ||
| brrt | - set timestamps and random seeds to known values | ||
| yeah, but why would you have to do that? | 14:26 | ||
| timotimo | no clue :) | ||
| as i said, i know nothing | |||
| brrt | if it would have to copy all your computations, then that would become too expensive | ||
| neither do i :-) | |||
| timotimo | mhm | ||
| brrt | but it looks cool | ||
|
14:51
camelia joined
15:43
domidumont joined
18:27
leont joined
|
|||
| timotimo | i'm thinking about perhaps adding some benchmarks to perl6-bench that stress nativecall | 18:52 | |
| maybe just one for some function that takes no arguments and returns an int, and one for some function that takes like ten arguments or so? | 18:53 | ||
|
19:28
vendethiel joined
|
|||
| jnthn | timotimo: Could do, yeah | 20:36 | |
| japhb | timotimo: +1 | 21:07 | |
| timotimo | i'm definitely not going to be able to write the perl5 equivalent of that | 21:10 | |
| and i'm not sure it'd be easy to write the same thing for nqp? | |||
| japhb | timotimo: By "perl5 equivalent" do you mean old-school XS or something like FFI or P5NCI? | 21:11 | |
| timotimo | hopefully something modern | 21:12 | |
| japhb isn't even sure what's used most often by new perl5 projects these days .... | |||
|
21:22
patrickz joined
21:50
leont joined
23:15
leont joined
23:47
vendethiel joined
23:51
cognominal joined
|
|||