02:28
zakharyas joined
04:02
FROGGS_ joined
05:26
zakharyas joined
07:49
Ven joined
07:50
FROGGS joined
08:18
Ven joined
08:30
rurban_ joined
08:54
brrt joined
09:13
kjs_ joined
10:11
kjs_ joined
|
|||
lizmat sees daylight again for the second time today | 10:30 | ||
brrt | :-) | 10:46 | |
i see cloudlight mostly | |||
lizmat | well, it got a bit darker here, like an early onset of the setting of the sun | 10:49 | |
10:56
colomon joined
11:32
kjs_ joined
11:50
Ven joined
12:21
Ven joined
|
|||
[Coke] | new moarvm is visible in the port list. whee. | 12:35 | |
hopefully will make some progress on nqp this weekend. | |||
brrt | yay | ||
FROGGS | \o/ | 12:42 | |
timotimo | brrt: you think perf could tell us what's wrong with the performance? | 13:33 | |
13:34
kjs_ joined
13:40
nebuchadnezzar joined
13:56
kjs_ joined
14:10
retupmoca joined
15:09
FROGGS[mobile] joined
16:13
Ven joined
|
|||
jnthn | timotimo: You may get more insight from callgrind or so | 16:37 | |
timotimo | mhm | 16:40 | |
hoelzro | [Coke]++ | 16:53 | |
dalek | arVM: aa450df | jnthn++ | src/6model/serialization.c: Re-enable lazy deserialization. Provide a #define for easily turning it on/off also. We'll see what the ecosystem fall-out is; even if there is any, we really want to have this on for the startup and memory use, so we should discover and debug the issues ahead of the next release. The pre-comp tests in the spectest suite are no worse with this turned on. |
16:58 | |
FROGGS[mobile] | I can do a ecosystem smoke if you want | 16:59 | |
jnthn | Feel free. | 17:00 | |
FROGGS[mobile] | and we can easily diff to the 2015.03 run | ||
jnthn | Right | ||
I'm going to have more tuits starting soon also, so I'll be in a better position to debug any fallout | 17:01 | ||
17:05
FROGGS joined
|
|||
hoelzro | jnthn: I tested my test for RT #122773 with your lazy deserialization change, and it doesn't break :thumbsup: | 17:28 | |
synopsebot | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=122773 | ||
jnthn | Yeah, I can the test file that's in and it seemed happy | 17:29 | |
There were other pre-comp fixes in the meantime | |||
hoelzro | jnthn++ | ||
jnthn | So I guess one of those nailed the real issue. | ||
FROGGS | "This has been fixed on MoarVM; the issue is still outstanding on JVM." | 17:32 | |
hoelzro | FROGGS: I'm trying it on the JVM now =) | 17:33 | |
hoelzro wonders if the corresponding roast test is skipped on JVM | |||
17:34
colomon joined
|
|||
japhb | jnthn: What are your 2015.04 goals? Which is to say, what's up next on the docket? | 17:56 | |
jnthn | Next major goal is NFG | 17:57 | |
(In Moar) | |||
Also thinking lots about sized/shaped array stuff | 17:58 | ||
In the backbrane at least. :) | |||
Will keep on with the native array stuff a bit too, since that's not perfect yet | 17:59 | ||
Wanting to land the various box/unbox and ref/deref opts in spesh I've started in on too | 18:00 | ||
In May, concurrency and I/O things probably will rise to the top of the pile. | 18:01 | ||
hoelzro | FROGGS: it's still outstanding on JVM =( | 18:11 | |
I was hoping that NQP or Rakudo had a change that fixed the issue for everyone | 18:12 | ||
FROGGS | :/ | 18:26 | |
hoelzro | although | 18:27 | |
there could be something in NQP that was largely copied over from JVM -> Moar, and was fixed in the latter, but not the former | 18:28 | ||
(or Rakudo, for that matter) | |||
FROGGS | yeah, the question is: what fixed it? | 18:31 | |
hoelzro | sounds like a job for git-bisect! | 18:32 | |
jnthn | I blame FROGGS! | ||
:P | |||
FROGGS | Ć².Ć³ | 18:33 | |
FROGGS thinks that it might help the he look angry | |||
hoelzro | jnthn: you blame FROGGS for fixing it? =) | ||
jnthn | Yes :D | ||
FROGGS++ fixes lots of things :) | |||
FROGGS | hmmm, I cannot remember touching something in that area | 18:34 | |
18:36
rurban_ joined
|
|||
jnthn | ah well :) | 18:38 | |
Dammit, why can drunk annoying people be rich enough to afford first class... :/ | |||
FROGGS | :/ | 18:39 | |
18:41
kjs_ joined
|
|||
FROGGS | jnthn: that's the only ecosystem regression: testers.p6c.org/reports/37368.html | 19:03 | |
jnthn: I just had to run it, right? I did not have to enable anything, right? | |||
jnthn | right | 19:04 | |
Just build with latest Moar | |||
(I didn't bump MOAR_REVISION etc) | |||
FROGGS | jnthn: you see the used versions at the top of the report | 19:05 | |
moar 2015.3.6.gaa.450.df - that looks good | |||
jnthn | yes | 19:07 | |
except the weird dots :P | 19:08 | ||
FROGGS | jnthn: I'm not to blame this time :o) | 19:11 | |
but, you get used to the dots | |||
nwc10 | jnthn: I appreciate that the release ship has sailed, but I was a bit, um, unthinking. | 19:16 | |
Could you correct "PPC32" and "PPC64" to "Power (32 and 64 bit)" | 19:17 | ||
I believe that that is correct (or nearly correct) and certainly far less incorrect than PPC | |||
jnthn | nwc10: Correct it where? | 19:18 | |
nwc10 | the website | ||
and whatever file in the repo | |||
aha, not in the repo | |||
jnthn | The website is in a repo, but asking you to fix it does no good since you don't have a commit bit :( | 19:19 | |
nwc10 | sorry, I'm not *that* useful | ||
jnthn isn't especially sure what was wrong with the original rendering :) | 19:20 | ||
dalek | href="https://moarvm.org:">moarvm.org: 1403e08 | jnthn++ | index.html: Wording tweak. |
||
nwc10 | if I understand it correctly, PPC is just one variant of the Power family | 19:22 | |
from a decade ago | |||
so saying "PPC" is sort of "so great, and you're y2k compliant too?" | 19:23 | ||
jnthn | ah, ok | ||
Turns out they marketed PPC too well so I thought that was the entire line :P | |||
nwc10 | I think this at times. Hence I made the mistake | 19:24 | |
jnthn | Not sure if marketing win or fail :) | ||
japhb: You've asked before about half-precision floating point. Any idea how portably available that is? | 19:39 | ||
japhb: gcc.gnu.org/onlinedocs/gcc/Half-Precision.html suggests "not" | |||
S09 mentions "16-bit floating-point is also considered optional in this sense." | 19:47 | ||
japhb | en.wikipedia.org/wiki/PowerPC has a little of the history of POWER/Power/PowerPC/PPC and such | 19:57 | |
I found it interesting that IBM won the contracts for all three of CPUs for the previous generation of gaming consoles. Apparently in the early days Sony/Microsoft/Nintendo didn't realize that IBM was essentially having the design teams sitting together, which is why mysteriously they had the same clock ratings and such. | 19:58 | ||
.oO( Gee, 4.2 GHz is awfully specific to have identical on different consoles ... ) |
19:59 | ||
jnthn: It might be worth looking at the LLVM docs, since it's used for doing GPU cross compiles, IIRC. | 20:00 | ||
jnthn: 16-bit FP ("half") is pervasively supported on GPUs and in any graphics software that supports HDR rendering or intermediates; see www.openexr.com/ for the library that kick-started this. | 20:01 | ||
As you note, it's supported directly on ARM, but also see: software.intel.com/en-us/blogs/201...structions | 20:02 | ||
jnthn | japhb: OK. I think I'm inclined to class this as something I'm happy to have go in, but don't personally feel it's a great use of tuits for me to focus on. | 20:09 | |
'cus it'll need a bunch of Configure probes to do. | 20:10 | ||
japhb | jnthn: I'm fine with that. Most important to me is that we not design it to break, like assuming a 16-bit value is a short int. | 20:13 | |
jnthn | japhb: Given that'd be int/num confusion, I don't see it happening. | 20:14 | |
japhb | (I wasn't expecting us to do that, I just meant that as an example.) | ||
I'm basically fine with not having it available soon, as long as it's not hard to add later, is all I'm saying. :-) | 20:15 | ||
jnthn | ah, oK :) | 20:17 | |
dalek | arVM: 0c95c4b | jnthn++ | src/6model/reprs/MVMArray.h: Add type codes for bit-packed array sizes. |
20:18 | |
japhb | *Way* more useful to me is 32-bit and 64-bit int/float "reinterpretation", which these days I assume will come from CUnion support. | 20:20 | |
20:39
kjs_ joined
20:42
TimToady joined
20:45
FROGGS joined
|
|||
timotimo | oh wow | 20:47 | |
no wonder devirting reprops made things break | |||
i mean, performance wise | |||
jnthn | Oh? | 20:48 | |
timotimo | i had "return jgb_consume_reprop(...)" in the jgb_consume_ins switch | 20:49 | |
wait | |||
that's not wrong | |||
mrrr | 20:50 | ||
dalek | arVM: 74c1982 | jnthn++ | src/6model/reprs/MVMArray.c: Fix a possible buffer-overrun in existspos. |
20:51 | |
arVM: 01be8e3 | jnthn++ | src/6model/reprs/MVMArray.c: First steps to handling bit-packed arrays. This gets them recognized in compose/deserialize_repr. Also factor out some repeated code to make this change easier. |
|||
timotimo | and now configure.pl refuses to accept my moar because it's "too old" | 20:54 | |
dalek | arVM/jit_devirtualize_reprops_2: cfff29d | timotimo++ | build/probe.pm: Merge branch 'master' into jit_devirtualize_reprops |
20:55 | |
arVM/jit_devirtualize_reprops_2: b5962a0 | timotimo++ | src/jit/graph.c: when failing from consume_reprop, do it loudly |
|||
timotimo | er | ||
did not mean to push | |||
i wanted to rebase this | |||
dalek | Heuristic branch merge: pushed 22 commits to MoarVM/jit_devirtualize_reprops_2 by timo | ||
timotimo | my brane seems to still be napping | 20:56 | |
dalek | Heuristic branch merge: pushed 22 commits to MoarVM/jit_devirtualize_reprops_2 by timo | 20:57 | |
timotimo | ah, got it | 21:07 | |
dalek | arVM/jit_devirtualize_reprops_2: ceeb4b5 | timotimo++ | src/jit/graph.c: no longer bail from many unhandled repr ops |
21:08 | |
timotimo | that was a dumb mistake :) | ||
i'll walk by my desktop quickly and turn it on so that i can run benchmarks | 21:34 | ||
now that i'm not accidentally bailing on a whole lot of jitted frames | |||
dalek | arVM/jit_devirtualize_reprops_2: ac1ca37 | timotimo++ | src/jit/graph.c: fill out switch-case, revert pointer "hack" |
21:50 | |
timotimo | benchmarks will commence now | 22:03 | |
22:24
moritz joined
|