timotimo i wanted to look something up. lo and behold: github goes down a minute before that 00:44
geekosaur yep 00:47
geekosaur too as it turns out
status.github.com/ first graph kinda tells you all you need to know
timotimo yeah
it went "boop"
01:14 vendethiel joined
diakopter so... there's a reason the deserialize code is so slow.. it's not making use of the cached scid slot 01:27
trying to fix all the small mallocs I think isn't the right direction to diagnose 01:28
05:36 vendethiel joined 06:21 vendethiel joined 06:50 vendethiel joined 07:14 vendethiel joined 07:22 domidumont joined 07:23 domidumont joined 07:28 domidumont joined 08:00 vendethiel joined 08:03 FROGGS joined 08:09 zakharyas joined 08:47 brrt joined 09:24 leont joined
brrt i've reduced asm fibonacci to 8 instructions :-) 09:36
and a loop of only 5 instructions 09:37
jnthn Can we code-gen that loop from NQP code yet? ;) 09:38
brrt no 09:41
it requires xchg, and i have *no idea* on how to tile that
which kind of suggests that peephole optimizations may be a better way to go 09:42
gist.github.com/bdw/df7231ee485a4cd001ca 09:44
well, except if we made a 'swap' node, but then you'd have to find some way to introduce it 09:45
09:45 vendethiel joined
brrt quite possibly during optimization 09:49
timotimo hm. how fast does fibonacci grow beyond the 64 bit range? how fast does it go beyond 32bit? 10:10
brrt i have nooooo idea 10:12
well, i have some idea
iirc, the ratio of fibonacci numbers trends to 1.69 after a while 10:13
so it would be log(MAX_64_BIT)/log(1.69)
brrt hums 'math! *oompf* what is it good for?'
timotimo heh. 10:14
brrt its 1.61, btw 10:16
10:43 brrt` joined 11:17 vendethiel joined 12:06 vendethiel joined 12:32 vendethiel joined 13:00 vendethiel joined
timotimo i don't know much about the deserialization code yet; do we have more details about what diakopter pointed out? 13:05
brrt not me 13:06
timotimo i thought the cached scid slot was used when objects first get created and added to an SC 13:09
but i expect i'm wrong about that belief
brrt i have no idea myself 14:48
15:07 lizmat joined 15:11 lizmat joined 15:57 cognominal joined, ggoebel15 joined 16:01 Hotkeys left 16:09 vendethiel joined 16:47 vendethiel joined 17:15 vendethiel joined 17:20 Hotkeys joined 17:21 Hotkeys left 17:31 domidumont joined 17:39 FROGGS joined 17:57 leont joined, vendethiel joined 18:21 tony-o_ joined
tony-o_ any ideas on this one: gist.github.com/tony-o/c082d1057989d8af8d93 ? 18:21
timotimo turn off jit? 18:28
download more ram? :S 18:29
jnthn tony-o_: Not really...it does look like some kind of "out of memory" 18:30
Or "can't allocate executable memory" maybe
tony-o_ timotimo: lol 18:31
jnthn Can check that by MVM_JIT_DISABLE=1 since I think that's the only thing that does it
timotimo yup
tony-o_ okay, was afraid of it just being out of mem and not much i can do to remedy that particular problem
giving jit a try now 18:32
:-( thank you 18:34
timotimo that solves the issue? 18:35
do you have any kind of security stuff active?
dalek arVM: a030701 | jnthn++ | docs/ChangeLog:
Update ChangeLog for 2016.01.
 18:39
tony-o_ nah it didn't solve the issue but i'm trying to set up a daily build for travis-ci and i'm doing it on an AWS micro server 18:46
so i'm not super worried about it not building, i'm building a vm right now to play around with trying to get that to work
timotimo oh, a micro server, eh? 18:47
you do realize how much ram it takes to compile the core setting?
we do want to reduce that amount, but ... yeah, it's a bunch.
tony-o_ i don't but i'm assuming now that it's more than .5Gb :-)
timotimo i think so, yeah 18:48
the good thing is:
on amazon, you can actually download more ram
tony-o_ may have to look at that if this test works 18:51
timotimo you can just time the build on your local machine and see its maxrss reported 18:52
can you create a swapfile on a micro instance? :D
tony-o_ i can give it a shot, i think if it's one process that needs more ram than is available it will still poop out though 18:55
timotimo could be
and the core setting compilation process will definitely do that to you 18:56
it's by far the biggest part of all of compiling rakudo
19:37 leont joined 20:44 lizmat joined
mst 814 21:21
bah
diakopter this code is new to me 21:46
dalek arVM: f4485fe | jnthn++ | VERSION:
Bump VERSION.
 21:56
jnthn [Coke]: I'm really tight for time (need to sleep soon, morning meeting). I'll cut the release, but don't have time to do portfile stuff 22:02
diakopter jnthn++
[Coke] jnthn: I'm hoping our new porter maintainer will take that on going forward. 22:03
jnthn ah, ok :) 22:11
22:17 ely-se joined
ely-se How does MoarVM implement world stopping during GC cycles? 22:17
It's hard to figure out from the source code.
diakopter there are safe points, and plenty of places in the code that tell the GC that thread is at a safe point 22:18
ely-se how are those implemented? 22:19
diakopter so if the GC needs to cycle the areas, it waits for all the threads to reach a safe point
almost always there is just one thread, so it doesn't have to wait
ely-se I see. 22:20
jnthn ely-se: Every GC allocation is such a safepoint; see also GC_SYNC_POINT
ely-se ah ok :) 22:21
I grepped "safepoint" and couldn't find much of interest
I like the way JVM implements safepoints.
diakopter which is? :) 22:23
ely-se It avoids expensive atomic operations by accessing memory that is sometimes inaccessible (mprotect(2)), in which case it handles the segfault
diakopter cute 22:24
jnthn We don't do any atomic operations at the safepoints themselves
ely-se there is a CAS in GC_SYNC_POINT
22:24 FROGGS joined
jnthn There is? 22:24
#define GC_SYNC_POINT(tc) \ 22:25
if (tc->gc_status) { \
MVM_gc_enter_from_interrupt(tc); \
}
ely-se orchestrate.c line 464
diakopter yes, the cheap read of gc_status there is meant to fail in the fast path
jnthn The "do we need to GC" check done at non-allocating safepoints is tc->gc_status
diakopter fail = read false :D
jnthn ely-se: That bit isn't about safepoints though, that's about getting the threads to build consensus once we're already at one.
ely-se ah ok 22:26
jnthn I've little doubt the JVM approach is smarter than what we're doing, though.
ely-se I should read the comments.
jnthn At least, they've had about 1,000 times the budget, so they'd better have come up with something smarter :P
diakopter if for some reason gc_status is out of sync across cores, we don't care if the GC has to wait a bit longer for it to be sync'd
ely-se but UB! 22:27
thanks for the help. it's time to sleep. :)
bey!
diakopter jnthn: I think our approach is better XD 22:28
jnthn OK, 2015.01 tagged
uhhh
2016.01 tagged
(relax, I got the tag right :P)
[Coke]: www.moarvm.org/releases/MoarVM-2016.01.tar.gz 22:30
I'll do the website update at the weekend or so :) 22:40
timotimo now that you know so much javascript, i bet you could make links cycle colors of the rainbow 22:45
flussence aaack!
geekosaur the <marquee> of the 2010s? 22:48
flussence I'd say hamburger menus claim that throne... (literally mystery-meat navigation) 22:50
jnthn Just 'cus you *can* do something doesn't mean you should :P 22:59
Sleep time...'night all o/ 23:00
diakopter o/
23:11 vendethiel joined 23:47 vendethiel joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!