Camelia, the Perl 6 bug

IRC log for #moarvm, 2013-10-12

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:15 benabik joined #moarvm
00:15 ggoebel6 joined #moarvm
00:26 FROGGS joined #moarvm
00:58 benabik joined #moarvm
01:56 dalek MoarVM: d525bd2 | jimmy++ | src/math/bigintops.c:
01:56 dalek MoarVM: Add missing MVMROOT to MVM_bigint_radix
01:56 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d525bd2a03
02:00 diakopter JimmyZ: that seems to fix the problem folks were having on the mac
02:00 diakopter JimmyZ: good find :)
02:00 diakopter JimmyZ: may I ask how you diagnosed and found it?
02:07 JimmyZ diakopter: I see jnthn++ fixed MVM_radix in the commit message, so I remember MVM_bigint_radix should be fixed too, since I ported these two to MoarVM
02:08 diakopter oh :)
02:08 JimmyZ ;)
02:10 diakopter oh.
02:11 diakopter nope, hit another one on the mac
02:11 diakopter oh wait
02:11 diakopter no, it's the same one
02:11 diakopter nm, sorry for the false hope :)
02:12 JimmyZ :P
03:17 foo_bar_baz joined #moarvm
03:42 jnap joined #moarvm
07:02 FROGGS[mobile] joined #moarvm
07:07 FROGGS[mobile] o/
09:33 FROGGS[mobile] joined #moarvm
10:05 woosley left #moarvm
10:10 grondilu joined #moarvm
10:45 cognominal joined #moarvm
11:04 diakopter o/
11:08 tadzik o/
11:16 jnthn afternoon o/
11:33 diakopter .oO( 240 km/h hurricane hitting India O_O )
11:36 jnthn Yes. Ouch. :(
11:37 diakopter India's weather service says storm surge of 11 feet; US weather service says 30 feet.
11:37 jnthn Makes sense. US feet are bigger, like everything in the US is bigger... :P
11:38 tadzik what surprises me is that US weather service is still operating :P
11:39 jnthn Though, operating != getting paid to operate...
11:39 moritz but if the US has bigger feet, the number should be smaller
11:39 diakopter "The US navy's weather service reported winds at sea were gusting at 314kph."
11:39 moritz (but come on, 11 feet isn't much for the Pacific Ocean; you don't need a Hurrican for that)
11:40 diakopter .oO( not too slow )
11:40 diakopter Our winds are pi today.
11:40 diakopter TIMES ONE HUNDRED
11:40 nwc10 the US Navy has gone metric?
11:40 moritz 0.1 kpi :-)
11:41 * grondilu has never heard of a wind speed over 300km/h on Earth
11:41 nwc10 is it feeling OK? Is this what a government shutdown does?
11:42 nwc10 "Pay us, or we go metric!"
11:42 moritz let's not pay them until it sticks :-)
11:43 grondilu they received a promise to be paid retroactively once the budget is voted.
11:44 diakopter http://www.usno.navy.mil/JTWC/
11:44 jnthn US. No!
11:45 moritz grondilu: that's, like, creating debt, isn't it?
11:46 grondilu well, a promise to pay is a debt, by definition.
11:46 moritz and I thought that was explicitly forbidding during shutdown
11:47 grondilu I guess thy made an exception.
11:47 grondilu *they
11:49 diakopter 138k people died in Myanmar in 2008 from a smaller cyclone.. 139,000 people died in Bangladesh in 1991 from a smaller cyclone. 300,000 people died in Bangladesh in 1970 from a smaller cyclone.
12:00 diakopter how many people is 1.2 crore people
12:01 diakopter 12000000
12:02 diakopter airport &
12:03 * jnthn hopes the most endangered folks will have managed to evacuate...
13:10 dalek MoarVM: 6b0e776 | jnthn++ | / (6 files):
13:10 dalek MoarVM: Add missing bindhllsym op.
13:10 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6b0e7760b0
13:23 jnthn To do to help Rakudo on Moar: port hllize, hllizefor ops (look at JVM impl)
13:44 FROGGS[mobile] Uhh, bindhllsym... nice
13:45 FROGGS[mobile] I've seen it complaining about that one when compiling moduleloader
13:46 FROGGS[mobile] jnthn: have you seen my note about uv_loop_delete?
13:49 jnthn FROGGS[mobile]: Yeah, but I'm not sure what to do about it...
14:48 diakopter FROGGS[mobile]: explain it more?
15:16 diakopter hm, now to see if master will merge into the gcorch branch
15:18 diakopter erm..
15:18 diakopter no conflicts!!?!?
15:18 diakopter weird..
15:20 timotimo that means there's only non-straightforward conflicts :(
15:20 diakopter :_
15:24 diakopter well, the gcorch branch ...... uhm
15:24 diakopter bootstrapped nqp just fine
15:24 diakopter uhm.
15:24 diakopter where went all the errors I was seeing
15:25 diakopter uhm.
15:26 timotimo uh
15:26 dalek Heuristic branch merge: pushed 76 commits to MoarVM/gcorch by diakopter
15:26 jnthn diakopter: Maybe many of them were things fixed in recent weeks that were always lurking, and you were unlucky enough to hit 'em with your branch.
15:26 timotimo yeah, hit them with a stick! hit 'em with a branch!
15:26 diakopter well, all tests successful
15:27 diakopter so, uh
15:27 JimmyZ what?
15:27 jnthn Any speed improvement? I guess the better gcorch is mostly about making multi-threaded better though...
15:27 timotimo have you tried tuning your gc parameters into the "omg super paranoid find all errors" mode?
15:27 JimmyZ time to merge gcorch to master?
15:27 diakopter oh wait.
15:28 timotimo there the errors are now :)
15:28 diakopter forgot I raised the gc ratio to 5000
15:28 timotimo so basically "never run"?
15:28 diakopter well, 50
15:28 jnthn gen2 never run
15:28 jnthn Wants to be 10ish :)
15:29 diakopter but it runs gen2 on the shutdown
15:29 diakopter but no code runs after it
15:29 diakopter but...
15:29 diakopter anyway I'll try nqp test again
15:31 diakopter lowered it to 10; nqp test was clean :S
15:31 diakopter so, uh
15:31 timotimo building nqp, too?
15:32 diakopter sigh.
15:32 diakopter trying
15:32 dalek MoarVM/gcorch: 4b16365 | diakopter++ | src/gc/collect.h:
15:32 dalek MoarVM/gcorch: back to normal ratio
15:32 dalek MoarVM/gcorch: review: https://github.com/MoarVM/MoarVM/commit/4b163651b0
15:32 timotimo if you can't succeed to break something, give it to a little kid and tell it "don't you break it!"
15:32 timotimo that's also how you split atoms
15:32 jnthn .oO( "nuclear family" )
15:36 diakopter yeah, built nqp from scratch and all tests successful
15:37 timotimo very nice! :)
15:37 jnthn \o/
15:37 jnthn diakopter++
15:38 diakopter so I guess it's ready for review :S
15:38 jnthn ;)
15:38 diakopter just ignore the use-tc-pointer-as-owner-instead-of-thread-id
15:38 diakopter I know an efficient way to fix that sometime
15:38 jnthn ok
15:38 jnthn I guess for now it makes all the objects bigger?
15:38 diakopter but it's not strictly necessary except to save memory
15:39 jnthn *nod*
15:39 jnthn I can see how it makes things easier this way
15:40 diakopter also it renamed owner to manager since it was being used for two things - in which thead's memory is the object allocated, and which thread has a lock on the object in shared mode... and so I removed the second sense for now...
15:41 diakopter so for objects that can enter shared mode they'll need an owner field
15:41 diakopter I mean, theoretically we could derive which thread allocated the object by studying its address
15:42 diakopter but that would be pretty onerous
15:43 diakopter heading to gate 7
15:43 diakopter &
15:43 diakopter s/7//
15:43 timotimo the moarvm gc will always be "stop the whole world" even in multithreaded situations, right?
15:45 jnthn Yes
15:46 JimmyZ stop the world works in <<Matrix>>
15:46 JimmyZ the movie :P
15:46 timotimo the dejavu thing would seem more like the matrix people use STM for their stuff
15:49 diakopter erm
15:49 diakopter well I must've been doing something wrong
15:49 diakopter because it doesn't run at all. :)
15:49 diakopter okay, that's more familiar.
15:49 diakopter I guess it was using the old build...
15:49 diakopter :S
15:49 timotimo oops :)
15:50 diakopter ok really akf
15:50 diakopter akf
15:50 diakopter afk
15:50 jnthn good flight
17:41 ssutch joined #moarvm
17:53 FROGGS joined #moarvm
19:05 rurban joined #moarvm
19:06 cognominal joined #moarvm
20:20 diakopter jnthn: heh, the frame cache isn't being used at all and I'm not sure why
20:20 diakopter (landed)
20:21 diakopter I'm actually not sure any frames are being freed either.
20:27 timotimo bah. frames are cheap
20:27 jnthn diakopter: I was looking at a profile the other day that suggested we were missing it a bunch
20:27 jnthn diakopter: If we're not freeing them then we'll be using a hell of a lot of memory :P
20:27 timotimo also, if you throw away frames, what do you do with photos?
20:27 diakopter jnthn: and indeed we do use a lot of memory.
20:28 jnthn diakopter: Could it be related? Find out in this week's episode of Moar Work Needed!
20:28 diakopter mine is invoking like 400k/s
20:29 gshank joined #moarvm
20:33 diakopter er
20:33 diakopter no
20:36 diakopter rhat's how many mallocs from frame invoke
20:38 timotimo 400.000 malloc calls due to frame entering?
20:38 timotimo per second?
20:38 jnthn Quite believable
20:38 jnthn And yeah, we'll be missing that frame cache.
20:39 jnthn That was a hot spot int he profile I did the other day
20:39 timotimo does the frame cache cache one frame to be re-used per ... frame-having-thingie?
20:42 jnthn arnsholt: omgz I just had win32-api-call.p6 work on JVM \o/
20:42 timotimo very cool! :)
20:43 jnthn un, mis-channel too :)
21:03 diakopter timotimo: actually it's like 70 per static frame or something
21:03 timotimo yeah, that'd do it :)
21:07 jnthn diakopter: I'm guessing some of those don't stay around though? Used during verificaiton?
21:25 diakopter jnthn: I think none get put on the cache list because none are hitting refcount 0
21:26 jnthn hmm
21:27 jnthn /* Decreases the reference count of a frame. If it hits zero, then we can * free it. Returns null for convenience. */
21:28 jnthn says MVM_frame_dec_ref
21:28 jnthn Is that really wise, if we didn't actually reach 0?
21:28 jnthn Hm, maybe yes.
21:29 jnthn I assume the comment about MVM_decr returning what the value used to be is also true?
21:30 jnthn ah, looks like
21:30 jnthn #define MVM_decr(addr) AO_fetch_and_sub1_full((volatile AO_t *)(addr))
21:32 jnthn diakopter: oh, I think I see it.
21:32 jnthn /* Initial reference count is 1 by virtue of it being the currently
21:32 jnthn * executing frame. */
21:32 jnthn MVM_store(&frame->ref_count, 1);
21:32 jnthn But we never actually subtract that when it ceases to be the currenlty executing frame.
21:34 diakopter o_O
21:34 diakopter it's not the exiting decrement?
21:35 diakopter there in er, returning
21:35 timotimo moarvm is going to become even faster?! ;)
21:36 jnthn return_or_unwind doesn't seem to decrement returner.
21:36 diakopter it used to :P
21:36 jnthn Decrements caller. :)
21:37 diakopter hey, all I know is when I added the frame cache the man-or-boy improved noticeably without measuring
21:37 diakopter like 30-40%
21:38 timotimo did it also start giving wrong results? :D
21:38 jnthn Well, lemme try adding the decrement
21:39 diakopter no..
21:39 cognominal joined #moarvm
21:39 diakopter er, scratch that no
21:39 diakopter was answering tt
21:41 jnthn Blow me, I think it just build without even passing 200 MB of RAM..
21:41 * diakopter rejects the offer
21:41 jnthn OK, optimzied build time
21:41 jnthn diakopter: I, uh... :P
21:42 timotimo wasn't that at over a gig of ram before?
21:42 diakopter whom can we blame for the sandbagging
21:42 jnthn I think it was hitting 2GB
21:42 diakopter yep
21:42 diakopter 2100MB
21:42 jnthn hah, now nwc10 might be able to pi it
21:42 jnthn bah, just blame me :P
21:43 diakopter heh.
21:43 timotimo why, that's amazing!
21:43 diakopter here I was optimizing 2 percent here, 5 percent there on the plane today
21:43 timotimo the last time i tried to build it, my computer froze up from the swapping. then i took a long nap.
21:45 diakopter jnthn: 5% of the time of the duration of the qregex test was spent in get_storage_spec until I refactored it to pass a pointer to an MVMStorageSpec... saved 5%
21:45 timotimo so you optimized away 100% of that time!
21:45 diakopter all that copying of structs on the stack
21:45 jnthn hah, -j6 now lets me run the NQP test suite in 9s
21:46 diakopter jnthn: try -j30 for fun
21:46 jnthn 8s
21:46 jnthn :P
21:46 benabik joined #moarvm
21:47 jnthn Anyway, biggest memory usage I see anywhere during the build is 163MB
21:47 diakopter hahahahahaha
21:47 jnthn One downside: 24-modules.t segfaults now.
21:47 diakopter hee.
21:47 diakopter probably just exposing some other bug
21:47 timotimo that's a trade-off you'd gladly make if you're on a raspberry pi ;)
21:48 jnthn yeah
21:48 jnthn I'll try and hunt it
21:48 jnthn Well, that's an improvement :)
21:49 dalek MoarVM: a0c41ad | jnthn++ | src/core/frame.c:
21:49 dalek MoarVM: Make sure to refcount-- frames we return from.
21:49 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a0c41adca0
21:51 diakopter jnthn++
21:52 diakopter jnthn: was that the only one that segfaulted/
21:52 diakopter ?
21:52 jnthn diakopter: 24-module.t is only one that segfaults 'cus of the above patch, yes
21:53 jnthn diakopter: It does the rest, and builds NQP, just fine with debugging and optimized build
21:53 diakopter heh ok
21:53 jnthn I'm suspecting autoclose
21:54 diakopter I'm suspecting ->sc
21:54 jnthn no, that looks reasonable...
21:55 * jnthn breaks out the debugger
21:55 diakopter I bet someone took out that returner decrement because it "fixed" bugs that were appearing... by keeping objects alive :)
21:56 jnthn oh...tricky
21:56 colomon joined #moarvm
21:56 jnthn No, I think I see what's going on now I know where it explodes.
21:56 diakopter do tell
21:56 jnthn autoclose thinks "oh, we don't need to allocate any ->work area 'cus it's just an autoclose frame"
21:56 jnthn But then the frame hits zero and ends up in the frame pool
21:57 jnthn Which then assumes it has a ->work
21:57 jnthn (at the point of re-use)
21:57 diakopter easy check is add a fix
21:57 diakopter erm.
21:57 diakopter easy fix is add a check
21:57 jnthn right
21:57 diakopter same for env?
21:58 jnthn trying a patch
21:59 diakopter oh, also...
21:59 diakopter it was spending 4% of time in get_env_hash
22:00 diakopter or whatever it's called
22:01 jnthn huh?
22:01 diakopter MVM_proc_getenvhash
22:01 jnthn wtf...
22:01 diakopter 4% of the qregex time in that
22:01 jnthn Why, ooc?
22:01 jnthn That sounds like something we want to make it not do...
22:01 jnthn I'm guessing it's doing it a lot of times?
22:01 diakopter oh wow.
22:02 diakopter string_substring and string_index are SLOW
22:02 diakopter 54 times
22:02 diakopter 100 calls to each of those string ops per call
22:02 diakopter er
22:02 diakopter 100 to substring
22:02 diakopter 50 to index
22:02 timotimo While looking for 'QAST.moarvm': no such file or directory - *still* getting this error while building stuff ... ?!?
22:02 * timotimo tries things
22:02 diakopter 50 to utf8_decode
22:03 timotimo i still need the moarboot branch, correct?
22:04 diakopter no
22:04 jnthn no, master
22:04 diakopter master
22:05 timotimo since when!
22:05 timotimo that may explain things :)
22:06 timotimo still telling me there's no QAST.moarvm to be found. weird.
22:06 timotimo i'll have to find out what's with that some day.
22:07 diakopter timotimo: need to realclean everything probably
22:07 jnthn timotimo: Can you gist me your moar and nqp build logs, so I can see what you're trying? :)
22:08 jnthn diakopter: Found our excessive getenvhash usage
22:08 jnthn multi method as_mast(QAST::CompUnit $cu, :$want) {
22:08 jnthn ...
22:09 jnthn if (nqp::getenvhash()<MVMCCDEBUG>) { say($cu.dump); }
22:09 jnthn That seems useless since you can get that with --target=ast :)
22:10 diakopter hee
22:10 diakopter yeah that was supposed to go away long ago
22:11 jnthn OK
22:11 dalek MoarVM: 88c3f16 | jnthn++ | src/core/frame.c:
22:11 dalek MoarVM: Fix case where we re-use a context-only frame.
22:11 dalek MoarVM:
22:11 dalek MoarVM: It will be missing a ->work, which is easily rectified.
22:11 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/88c3f16a7f
22:11 jnthn getenvhash does make the hash afresh each time, but I think it needs to
22:11 jnthn Otherwise tests will fail
22:11 jnthn Anyway, will remove the MVMCCDEBUG line :)
22:11 diakopter meh I'm sure there are ways to optimize it specially though if it's hot again someday
22:12 diakopter want some more hotspots?
22:12 jnthn Sure, though we may have new hotties after these fixes :)
22:12 diakopter pushing one
22:12 dalek MoarVM: d003447 | diakopter++ | src/ (31 files):
22:12 dalek MoarVM: help the optimizer a bit by making get_storage_spec not use so much stack and copying
22:12 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d003447c5a
22:12 dalek MoarVM: 9e54e55 | diakopter++ | src/core/frame.c:
22:12 dalek MoarVM: Merge branch 'master' of github.com:MoarVM/MoarVM
22:12 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9e54e55755
22:12 dalek MoarVM: f1e7917 | diakopter++ | src/core/frame.c:
22:12 dalek MoarVM: Merge branch 'master' of github.com:MoarVM/MoarVM
22:12 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f1e7917037
22:13 diakopter feel free to revert it if you don't want to do that
22:13 diakopter but it saves a bunch for me
22:13 jnthn looking
22:15 jnthn I'm a little worried that the new thing on tc will be fragile
22:15 diakopter as long as get_storage_spec doesn't recurse..
22:16 timotimo https://gist.github.com/timo/8210a8e008c9941ad26e - that's my output
22:16 jnthn Well, or we don't write code that wants to talk about two different thing's storage specs at the same time...
22:16 jnthn It's the latter one I worry about
22:16 jnthn Thing is...
22:16 diakopter ah.
22:16 jnthn I think I know a more efficient way to solve this... :)
22:16 diakopter ok how
22:17 jnthn For many of the REPRs, storage spec is always the same
22:17 diakopter my other idea was to pass pointers to the locals of values we wanted, and for the get_storage_spec to check each one, and if it's not NULL, populate it
22:17 jnthn So we just have a static MVMStorageSpec and return a pointer to that.
22:17 jnthn We change get_storage_spec to always return MVMStorageSpec *
22:17 jnthn So there's not copying OR setup work
22:18 diakopter 99.99% of the time was from the p6opaque one... oh wait
22:18 jnthn For things that *do* want to customize it, they want to do so by type
22:18 jnthn So we can just allocate one hanging from, say, P6opaqueREPRData
22:18 jnthn And just return the pointer to it
22:18 jnthn Then free it in free_repr_data
22:18 diakopter oh wait.
22:18 diakopter it wasn't the copying
22:18 diakopter bleh
22:19 diakopter ok revert it :)
22:19 jnthn I agree we should change this, just not like this...we should change it so it returns a pointer to something, then set it up one time and return the already set up thing :)
22:19 jnthn That should be a bigger saving
22:19 jnthn And not make me worry about the new thing off tc ;)
22:21 colomon joined #moarvm
22:22 diakopter right, like I said :P
22:22 jnthn Shall I do the revert?
22:23 diakopter yes plz.... .oO( making me grovel... )
22:23 timotimo Routine declaration requires a signature at line 4104, near "(MAST::Nod"
22:23 timotimo this is the real error, btw
22:24 diakopter anyway 6% of time is spent in get_attribute
22:24 diakopter because there are no slot hints
22:24 jnthn :)
22:24 jnthn I noticed that a load of those are related to invoke btw
22:25 jnthn When we do the lookup of the code ref in a code object
22:25 jnthn Fixing that would probably help avoid a bunch of the more costly get_attribute calls
22:25 diakopter no
22:25 diakopter these are all direct from the interpreter
22:26 jnthn oh
22:26 diakopter I'm looking at the call tree only
22:26 diakopter not the aggregate
22:26 jnthn OK, the profile I did of QAST.nqp compilation showed the path through invoke to get_attribute also has the no-hint issue
22:27 diakopter 5% of time is spent in at_key_boxed, in the uthash memcmp entirely
22:27 dalek MoarVM: 535fd59 | jnthn++ | src/ (31 files):
22:27 dalek MoarVM: Revert "help the optimizer a bit by making get_storage_spec not use so much stack and copying"
22:27 dalek MoarVM:
22:27 dalek MoarVM: While something in this space is helpful, this isn't the ideal way, as
22:27 dalek MoarVM: discussed on #moarvm.
22:27 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/535fd59175
22:27 diakopter 5% of time is spent in at_key_boxed, in the uthash memcmp entirely
22:28 jnthn hm
22:28 jnthn Well, that's kinda believable
22:28 diakopter 740k calls in 5 seconds
22:28 jnthn I guess it already has somewhere the "if the memory addresses are the same, we need not compare" opt?
22:28 jnthn oh, memcmp probably has that...
22:29 jnthn And it is probably hit less than I would think...
22:29 diakopter that's just direct from interp
22:31 diakopter 4m calls to mvmarray at_pos
22:31 diakopter (total time 1%)
22:48 grondilu one thing I don't understand though.  The first stage won't go in orbit, so it won't make a whole turn aroung Earth.  Therefore when it renters, it will be quite far away from the launching area.  Will it have to travel on this thanks to its propulsion?
22:49 timotimo that's why it can go horizontally
22:50 grondilu oops, that was the wrong channel, wasn't it?
22:50 timotimo yep
22:50 * grondilu reposts in #space
22:50 jnthn moar channels create moar confusion...
22:55 diakopter jnthn: what blocks getting the attr slot hints?
22:55 jnthn nothing afaik
22:55 jnthn just needs doing
22:55 diakopter well, what needs doing about it
22:55 diakopter also, what's needed to get the method cache
22:56 jnthn making sure nqp::hintfor is implemented
22:56 jnthn And then using it for QAST::Var node compilation
22:56 jnthn Just passing the hint to the getattr and bindattr instructions
22:57 diakopter 400k calls to find_method took 800ms
22:57 jnthn The "method cache" is really just a hash
22:57 jnthn The smarter thing is likely part of the specializer
22:58 jnthn oh btw...I had an idea on that stuff
22:59 jnthn I realized that we can use the AST we build for the specialization stuff not just to JIT, but potentially also to spit out refined bytecode that includes some "secret"/unsafe instructions (ones that you can never get past validation).
23:00 diakopter yah
23:00 jnthn Meaning I can play around with it without having to worry about the code-gen side of JIT and still get some performance wins as a result and a good way to make sure the "safe" things really are safe :)
23:02 jnthn Anyway, that ties into what you just asked in so far as, if we type-specialize and we know that the method we found was produced out of the method cache hash, not dynamically, then we don't need to look it up :)
23:02 diakopter yeah but find_method is only 2%
23:02 woolfy joined #moarvm
23:03 jnthn Sure, but it all adds up :)
23:03 jnthn Plus that is the step before going ahead and doing inlining of said method, if it looks worth it
23:13 diakopter okay, I ran a new profile
23:14 diakopter 33 seconds of qregex
23:14 diakopter roughly 1 million interpreter operations/second
23:14 jnthn That's while profiling yes?
23:14 diakopter yes
23:15 diakopter so probably a 10x slowdown
23:15 jnthn Was gonna say, t/qregex runs in less than 33s here :)
23:15 jnthn Right, that oom
23:17 diakopter jnthn: http://i.imgur.com/gnaHCgK.png
23:17 diakopter zoom in
23:18 diakopter wow.
23:18 diakopter only 1 gc run per second average
23:18 diakopter that's... not much.
23:19 jnthn That number of calls in MVM_interp_run is odd...
23:20 diakopter it's counting each switch loop for some reason
23:20 jnthn ah
23:20 diakopter almost as if it recognizes teh pattern as a tailcall-ish
23:20 jnthn This is instrumented, yes?
23:20 jnthn Not sampled?
23:20 diakopter yes
23:21 diakopter I unchecked "skip small functions"
23:21 diakopter er, exclude
23:22 diakopter the gc_free that is taking 4.29% is the one in mvmcode
23:23 jnthn Probably 'cus it decrements an outer and then ends up shoving stuff back into the frame pool
23:24 diakopter I'll look
23:25 jnthn MVM_sc_get_object is a bit hotter than I'd expected
23:25 jnthn Though I'm not worried about it
23:25 diakopter actually no, 3.6% of the 4.29% are calls to free after decrementing
23:25 jnthn I know once we JIT those will go away
23:25 diakopter which means the cache chain could use being longer :)
23:26 diakopter heading out & :) have fun
23:27 jnthn you too o/
23:30 grondilu left #moarvm
23:39 jnthn sleep &

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary