|
00:16
mojca joined
04:42
vendethiel joined
06:03
mojca joined
07:04
domidumont joined
07:09
domidumont joined
07:40
FROGGS joined
08:02
zakharyas joined
08:51
mojca joined
09:42
vendethiel joined
10:42
vendethiel joined
12:06
colomon joined
12:30
mojca joined
13:09
zakharyas joined
13:48
Util joined
14:37
psch joined
|
|||
| dalek | arVM: 43edc3f | jnthn++ | src/ (2 files): Don't allocate second GC semi-space until needed. This knocks 4MB off threads that finish before they ever GC (including the main thread in programs that are single-threaded.) |
14:44 | |
| MoarVM: 824748d | jnthn++ | src/ (5 files): | |||
| MoarVM: Don't keep an MVMStaticFrame array in MVMCompUnit. | |||
| MoarVM: | |||
| MoarVM: We hardly ever did lookups in it, and could replace those few places | |||
| MoarVM: that did with lookups via the coderefs array, just with an extra level | |||
| MoarVM: of indirection. Saves 134KB off Rakudo base memory, plus a bit extra | |||
| arnsholt | Oh, that first one is neat! Does it change startup time appreciably as well? | 14:49 | |
| jnthn | arnsholt: No; calloc is really quite cheap :) | 14:52 | |
| And the second one doesn't also | 14:53 | ||
| arnsholt | Yeah, I assumed that'd be the case. But allocations are one of those things that suddenly slow things down in some cases, so figured it'd be worth asking =) | 14:55 | |
| jnthn | massif says we go from a heap of 57,571,688 to a heap of 53,383,024 with those two patches, anyways. | 14:56 | |
| For perl6 -e "say(1)" | 14:57 | ||
|
15:20
domidumont joined
15:32
domidumont joined
16:12
frwtv joined
|
|||
| frwtv | what is the advantage of having a smaller heap? | 16:18 | |
| I'm almost sure that lazy allocation is already performed by the operating system | 16:22 | ||
| timotimo | frwtv: why wouldn't it be good to not ask for as much space up front if it's not necessary? | 16:29 | |
| the closer to "reality" the memory usage is, the more sensible decisions tools and admins can make about things | |||
| frwtv | it depends, keeping a fixed value for the memory "cost" of a thread can also be a good in term of provisioning | 16:40 | |
| a branch can cost a pipeline | |||
| timotimo | if you have a thread that does most of its work with native values, for example, and you join() it before it does its first GC run, it won't ever cost the second semi-space | ||
| and as we gain escape analysis and start allocating our Scalars on the stack instead of the heap, and kick out unnecessary *LexRef/*AttrRef objects as well as temporary Int, Num or Str boxes at some point, we'll be getting much further without doing GC | 16:41 | ||
| in the future, it might happen that we make the semi space size tunable or even self-tuning | 16:42 | ||
| frwtv | if in the future the people will start to use lot's of this kind of micro-thread (with auto-parallelization and such) then it makes sense | 16:45 | |
| timotimo | hm, i thought we'd probably be using a thread pool for that kind of thing, so threads would end up long-living after all | ||
| frwtv | you might not need to run the GC for those threads | 16:49 | |
| timotimo | yes | ||
| after a time :) | |||
| but if i remember correctly we force a gc run when we join threads, too | 16:50 | ||
| in any case, we'll see about that when we get there | |||
| the patch itself is easy enough to revert | |||
|
16:51
FROGGS joined
17:21
domidumont joined
18:00
mojca joined
18:33
zakharyas joined,
vendethiel joined
20:19
mojca joined
21:07
pyrimidine joined
21:30
sivoais joined
23:15
vendethiel joined
23:45
mojca joined
23:55
vendethiel joined
|
|||