|
01:08
travis-ci joined
|
|||
| travis-ci | MoarVM build passed. Stefan Seifert 'Fix off-by-one error in uninline | 01:08 | |
| travis-ci.org/MoarVM/MoarVM/builds/328839703 github.com/MoarVM/MoarVM/compare/5...a08024edfe | |||
|
01:08
travis-ci left
01:17
unicodable6 joined,
quotable6 joined
02:57
ilbot3 joined
03:42
Kaiepi joined
03:50
klapperl joined
03:57
bloatable6 joined
06:26
domidumont joined
06:32
domidumont joined
06:34
brrt joined
07:40
brrt joined
07:42
brrt joined
|
|||
| samcv | have a ton more ucd2c.pl work i've been doing. removing more unneeded variables simplifying loops. making quoted strings not contain newlines inside them which make it hard to read | 07:44 | |
| and many more things. no real functional changes but it's making the code better | |||
|
07:50
domidumont joined
07:56
FROGGS joined
08:14
brrt joined
08:35
zakharyas joined
09:03
zakharyas joined
09:21
Kaiepi joined
09:32
brrt joined
10:30
brrt joined
10:31
brrt joined
|
|||
| jnthn | morning o/ | 10:32 | |
| samcv++ # ucd2c cleanups | |||
| nine++ # inline fixes | |||
| brrt | \o everybody | 10:33 | |
| indeed nine++ samcv++ | |||
| jnthn | o/ brrt | ||
| brrt is positively impressed by nine's perseverance | 10:34 | ||
| jnthn | That's pretty much half of debugging | 10:40 | |
|
10:46
zakharyas joined
|
|||
| lizmat | time for a bump ? | 11:06 | |
|
11:40
zakharyas joined
11:46
committable6 joined
12:06
brrt joined
13:48
zakharyas joined
13:52
zakharyas joined
14:14
bisectable6 joined
14:47
squashable6 joined
15:28
zakharyas joined
16:26
brrt joined
17:23
coverable6 joined,
benchable6 joined
17:28
domidumont joined
|
|||
| nine | Oh boy...the next issue occurs after speshing a function consisting of 1464 basic blocks and 147 registers | 17:35 | |
| And no less than 20 inlines | 17:36 | ||
|
17:43
brrt joined
|
|||
| timotimo | :D | 17:56 | |
| Geth | MoarVM: 4a0a912ef1 | (Stefan Seifert)++ | tools/spesh-bisect.pl New spesh-bisect.pl tool Finds the first MVM_SPESH_LIMIT value where test program breaks. Usage: tools/spesh-bisect.pl perl6 t/foo/bar.t Uses the process' return code for deciding whether the run was successful or not (like git bisect run) |
18:12 | |
|
18:13
zakharyas joined
18:15
zakharyas joined
18:31
geospeck joined
|
|||
| lizmat | jnthn: I think I've asked this before, but may be not | 18:38 | |
| if I look at the performance of "say (^Inf).hyper(:1000batch,:4degree).grep( *.is-prime )[5000]" | |||
| then there is hardly any gain increasing the :degree: values 5 - 8 only give marginal wallclock gains | 18:39 | ||
| whereas :8degree almost doubles in CPU usage | |||
| so it appears to be busy doing something, but not actual work :-) | |||
| is this something we can see improve in the future or not ? | 18:40 | ||
| jnthn | How many real cores do you have? | ||
| lizmat | 4 real / 8 virtual | ||
| jnthn | OK, so by the time you're in 5 you're beyond the real cores | ||
| And the work is the same, so competing over the same function units | |||
|
18:40
releasable6 joined
18:41
greppable6 joined,
reportable6 joined,
statisfiable6 joined,
nativecallable6 joined
|
|||
| timotimo | right, hyper threading helps mostly if the individual pieces of work are different | 18:41 | |
| like, one core is doing mostly floating point arithmetic, the other mostly shuffling data around or bitwise operations or whatnot | |||
| lizmat | ok, so you're saying, don't increase :degrees above real cores for .hyper | ||
| perhaps we need to doc this? | 18:42 | ||
| jnthn | We can but it's very workoad dependent | ||
| timotimo | well, if you're already .hypering just one sequence, maybe that means the workload is mostly the same? | 18:43 | |
| lizmat | ok, so you're saying "say (^Inf).hyper(:1000batch,:4degree).grep( *.is-prime )[5000]" is like a worst case | ||
| jnthn | The work is mostly in .is-prime, and | ||
| that's going to be a nice, tight, chunk of well-optimized C code | 18:44 | ||
| Presumably mostly doing integer, memory, and branch work | |||
| So yeah, it's the kind of case that's liable to wind up with more threads on the CPU, but not many more instructions being retired | |||
| lizmat | yeah, gotcha | 18:45 | |
| jnthn | A modern CPU core is like a pin board with tasks to be done on it, and lots of workers grabbing tasks that have all their dependencies available. Hyperthreading is two threads sticking stuff on the board, but there's only so many workers. :) | 18:46 | |
| The biggest wins are when the threads occupy different workers. | |||
| Then there's the times a disgruntled worker saw something on the pin board that was confidential and snitches about it down the pub. Thus Meltdown. :P | 18:48 | ||
| dinner & | |||
| nine | Apparently all remaining test failures are due to mis-spesh of the 'compile_var' monster (the one with 1464 BBs and 20 inlines) | 18:56 | |
|
19:43
dogbert17 joined
20:33
Ven`` joined
20:47
Kaiepi joined
20:50
evalable6 joined
|
|||
| lizmat | and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/01/15/...blue-note/ | 20:57 | |
|
22:20
leont joined
22:26
Ven`` joined
22:39
Ven`` joined
|
|||
| leont | Either spawn_async is leaking data, or uv_spawn takes ownership of the handles without documenting it, or I'm not understanding the code | 23:01 | |
| samcv | lizmat++ | 23:25 | |