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