github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:13 sivoais joined 01:30 squashable6 left 01:33 squashable6 joined 02:53 zakharyas joined 03:29 zakharyas left 05:22 sena_kun joined 05:57 domidumont joined 06:02 domidumont left 06:20 domidumont joined 07:04 brrt joined 08:16 chloekek joined 08:19 brrt` joined 08:20 brrt left 09:10 chloekek left 09:16 brrt` left 09:18 Kaiepi left, Kaiepi joined 09:23 squashable6 left 09:25 squashable6 joined 09:51 brrt` joined 10:04 domidumont left 10:05 brrt` left 10:45 brrt` joined 10:53 nebuchadnezzar left, nebuchadnezzar joined
nwc10 good` *`, brrt` 11:24
11:26 brrt` left 11:35 domidumont joined 11:52 domidumont left 11:58 chloekek joined 12:08 domidumont joined 12:50 lucasb joined
timotimo i would like to go a step up from nqp::force_gc and to something like nqp::gc_control 13:01
13:01 pamplemousse joined
pamplemousse o/ 13:02
timotimo ohai 13:06
pamplemousse Hi timotimo 13:09
timotimo my brain is so fried, i'm having trouble figuring out how i'm using Concurrent::Progress wrong 14:03
can someone help me spot the mismatch that leads my progress to get to 17/16 instead of 17/17 or 16/16? 14:30
github.com/timo/p6-app-moarvm-heap...r/tree/WIP - the file "new" has log output with manual annotations what matches up 14:34
and line numbers/filenames to point where values get increased or decreased 14:35
14:35 brrt` joined
jnthn This is odd; a simple `for 1..10_000_000 { }` seems to never get any spesh logging after some stuff inside of the compiler 14:48
timotimo what the heck 14:50
timotimo investigates 14:51
jnthn Also, why on earth does src/spesh/worker.c have a bunch of manual rooting instead of using MVMROOT? 14:52
timotimo debugging reasons, you can't step inside of a macro which makes stuff really hard
i can revert that real quick if you'd like 14:53
jnthn Well, once you don't need it...
14:55 brrt` left
timotimo oh 14:56
now i remember
src/spesh/worker.c:227:6: error: macro "MVMROOT" passed 6 arguments, but takes just 3
227 | });
i couldn't figure out why this happened
but just replacing the MVMROOT with pushes and pops made everything work just fine
jnthn You can't use a declaration like `int foo, bar;` and have to do `int foo; int bar;`
timotimo fascinating 14:57
that changes things
nwc10 but beware of writing `int* foo, bar;` 14:58
actually, IIRC
but beware of writing `int *foo, bar;`
timotimo yeah that makes it work again
that's frickin ridiculous :) :) :)
nwc10 I remember that there's a gotcha, but foget which way round it is 14:59
timotimo it makes sense in a way, since the preprocessor doesn't really understand C syntax
it can't handle nested curlies right
so { blah, bloop } will look like two arguments to it
nwc10: well, the point is that we can't use , for variable declarations 15:02
because it makes the preprocessor unhappy
so the problem is not a problem after all :)
nwc10 Aha. I missed *that* bit. What I typed still holds for (regular) C 15:04
need to head out
timotimo :) 15:05
it's annoying that i now have to rebuild rakudo when i want to have telemeh 15:08
d'oh, i even need to Configure.pl for it to pick up the HAVE_TELEMEH flag 15:17
perhaps the runner shouldn't look for HAVE_TELEMEH at all, instead there could be a run-time function in moarvm that tells if it's compiled in or just stubbed
benchable6: 2019.03,2019.07,2019.07.1 for 1..10_000_000 { } 15:24
benchable6 timotimo, starting to benchmark the 3 given commits
timotimo, Ā¦2019.03: Ā«0.2111Ā» Ā¦2019.07: Ā«0.2001Ā» Ā¦2019.07.1: Ā«0.2023Ā»
timotimo, No new data found
timotimo benchable6: 2019.07.1,HEAD for 1..10_000_000 { } 15:25
benchable6 timotimo, starting to benchmark the 2 given commits
timotimo, Ā¦2019.07.1: Ā«0.2162Ā» Ā¦HEAD: Ā«1.6329Ā»
timotimo, benchmarked the given commits and found a performance difference > 10%, now trying to bisect
timotimo, Ā¦2019.07.1: Ā«0.2162Ā» Ā¦90ffa34: Ā«0.2233Ā» Ā¦HEAD: Ā«1.6329Ā»
timotimo oops?
bisectable6: 90ffa349c,190e84bb7 for 1..10_000_000 { } 15:27
bisectable6 timotimo, Using old=90ffa349c new=190e84bb7 in an attempt to do what you mean
timotimo, On both starting points (old=90ffa34 new=190e84b) the exit code is 0 and the output is identical as well
timotimo, Output on both points: Ā«Ā»
timotimo benchable6: 90ffa349c,190e84bb7 for 1..10_000_000 { }
benchable6 timotimo, starting to benchmark the 2 given commits
timotimo, Ā¦90ffa34: Ā«0.2340Ā» Ā¦190e84b: Ā«0.2217Ā»
timotimo, No new data found
timotimo benchable6: 46c05032d for 1..10_000_000 { }
benchable6 timotimo, starting to benchmark the 1 given commit
timotimo, No new data found
timotimo benchable6: 46c05032d,HEAD for 1..10_000_000 { } 15:28
benchable6 timotimo, starting to benchmark the 2 given commits
timotimo, Ā¦46c0503: Ā«1.6616Ā» Ā¦HEAD: Ā«1.6549Ā»
timotimo, No new data found
timotimo benchable6: 19e075ffa,46c0503 for 1..10_000_000 { } 15:29
benchable6 timotimo, starting to benchmark the 2 given commits
timotimo maybe someone can finish this hunt for me, i've got to be AFK for a bit
benchable6 timotimo, Ā¦19e075f: Ā«1.6217Ā» Ā¦46c0503: Ā«1.6491Ā»
timotimo, No new data found
15:37 pamplemousse left
timotimo let's try another 15:40
benchable6: 617999c15,3d5c5517b,9dfca9488,8e8868a23.f8768ae56 for 1..10_000_000 { } 15:41
benchable6 timotimo, starting to benchmark the 4 given commits
15:42 chloekek left
benchable6 timotimo, Ā¦617999c: Ā«Ā«run failed, exit code = -1, exit signal = -1Ā»Ā» Ā¦3d5c551: Ā«1.6140Ā» Ā¦9dfca94: Ā«1.6347Ā» Ā¦8e8868a23.f8768ae56: Ā«Cannot find this revision (did you mean ā€œ0f3c59cā€?)Ā» 15:42
timotimo, No new data found
timotimo grmbl
benchable6: 8e8868a23,f8768ae56 for 1..10_000_000 { }
benchable6 timotimo, starting to benchmark the 2 given commits
timotimo, Ā¦8e8868a: Ā«1.6277Ā» Ā¦f8768ae: Ā«0.2199Ā»
timotimo, No new data found
timotimo benchable6: d46a90848,19e075ffa for 1..10_000_000 { } 15:43
benchable6 timotimo, starting to benchmark the 2 given commits
timotimo, Ā¦d46a908: Ā«1.6450Ā» Ā¦19e075f: Ā«1.5965Ā» 15:44
timotimo, No new data found
timotimo benchable6: 9ea523dd4,4cdd2d10c,10ded7c93,db7af3e7d,43066b9d0,daebcd266 for 1..10_000_000 { } 15:48
benchable6 timotimo, starting to benchmark the 6 given commits
timotimo, No new data found
timotimo WDYM
benchable6: 9ea523dd4,4cdd2d10c,10ded7c93 for 1..10_000_000 { }
benchable6 timotimo, starting to benchmark the 3 given commits
timotimo benchable6: db7af3e7d,43066b9d0,daebcd266 for 1..10_000_000 { } 15:49
benchable6 timotimo, Ā¦9ea523d: Ā«1.6531Ā» Ā¦4cdd2d1: Ā«Ā«run failed, exit code = 1, exit signal = 0Ā»Ā» Ā¦10ded7c: Ā«Ā«run failed, exit code = 1, exit signal = 0Ā»Ā»
timotimo, No new data found
timotimo, starting to benchmark the 3 given commits
timotimo, Ā¦db7af3e: Ā«Ā«run failed, exit code = 1, exit signal = 0Ā»Ā» Ā¦43066b9: Ā«0.2386Ā» Ā¦daebcd2: Ā«0.2207Ā»
timotimo, No new data found
timotimo 9ea523dd4 looks to be the first slow one? | * 9ea523dd4 - Merge branch 'master' of github.com/rakudo/rakudo into grammar-with-failure 15:50
benchable6: 84b8b9b9e,3f699e26f for 1..10_000_000 { } 15:51
benchable6 timotimo, starting to benchmark the 2 given commits
timotimo, Ā¦84b8b9b: Ā«1.7012Ā» Ā¦3f699e2: Ā«1.6643Ā»
timotimo, No new data found
timotimo nope, it was already slow on the other side of the merge 15:52
benchable6: 636888c69 for 1..10_000_000 { }
benchable6 timotimo, starting to benchmark the 1 given commit
timotimo, No new data found
timotimo come on >:(
benchable6: 190e84bb7,c0b6cafc2 for 1..10_000_000 { } 15:53
benchable6 timotimo, starting to benchmark the 2 given commits
timotimo, Ā¦190e84b: Ā«0.2508Ā» Ā¦c0b6caf: Ā«0.2350Ā»
timotimo, No new data found
timotimo benchable6: 636888c69 for 1..10_000_000 { }
benchable6 timotimo, starting to benchmark the 1 given commit
timotimo, No new data found
timotimo committable6: 636888c69 for 1..10_000_000 { }
committable6 timotimo, Ā¦636888c: Ā«Ā»
timotimo committable6: 636888c69 for 1..10_000_000 { }; say now - INIT now
committable6 timotimo, Ā¦636888c: Ā«0.1837576ā¤Ā»
timotimo committable6: 3f699e26f for 1..10_000_000 { }; say now - INIT now 15:54
committable6 timotimo, Ā¦3f699e2: Ā«1.99528608ā¤Ā»
timotimo committable6: 5cd45f914 for 1..10_000_000 { }; say now - INIT now
committable6 timotimo, gist.github.com/a6b7c91fc3d89a7615...ec35f7ccd2
timotimo committable6: e119852c8 for 1..10_000_000 { }; say now - INIT now
committable6 timotimo, Ā¦e119852: Ā«Cannot test this commit (Commit exists, but a perl6 executable could not be built for it)Ā»
timotimo committable6: fa3d168c9 for 1..10_000_000 { }; say now - INIT now 15:55
committable6 timotimo, Ā¦fa3d168: Ā«1.585538ā¤Ā»
timotimo this is from renaming CORE folders?
anyway the problem seems to appear between 636888c69 - Merge pull request #3135 from ZhongnianTao/master, which is still good, and fa3d168c9 - Add missing line continuation which is already bad 15:56
between that are gitignore files, has-symbols test sub, tests for symbols in CORE and SETTING, handle new BOOTSTRAP/ dir in cleanup, JVM backend support for the new structure 15:57
someone will have to take over for me 16:05
16:05 domidumont left
jnthn Ah, I figured it out... 16:16
16:16 chloekek joined
jnthn It's the mechanism that tries to make sure we get a fresh spesh log buffer when we enter a new compilation unit 16:16
It puts an upper limit on how many times it's willing to use that 16:19
And apparently we load enough compilation units now to exceed it or some such problem 16:20
16:54 chloekek left
timotimo fascinating! 17:16
boy am i glad it didn't turn out to be a mistake on my part 17:17
17:45 domidumont joined 18:28 chloekek joined 18:56 domidumont left 19:24 pamplemousse joined 20:01 sena_kun left 20:18 MasterDuke joined 20:25 brrt joined
brrt \o 20:25
20:26 MasterDuke left
timotimo hoi brrt 20:26
20:26 MasterDuke joined
brrt hoi timotimo 20:33
20:35 Ven`` joined
MasterDuke if anyone is interested, i'm making progress on github.com/libtom/libtommath/pull/330, so hopefully in a little while (after it's merged and released and we update) moarvm/nqp/rakudo will have faster big integer stringification 20:40
timotimo "really big integer stringification" :)
MasterDuke heh, yes 20:45
20:52 Ven`` left
timotimo i removed loads of code from moar heapanalyzer to try to zero in on what's wrong 21:02
brrt my plan to remove the 'destructive' flag isn't quite as effective as I had in mind. yet 21:05
MasterDuke i feel like there's some sort of "indestructivable" pun to be made here, but it's not coming to me 21:08
brrt another time, maybe 21:12
timotimo github.com/timo/p6-app-moarvm-heap...r/tree/WIP - can someone have a look at the code? i simplified it drastically, all it requires is my version of Concurrent::Progress: github.com/timo/p6-concurrent-prog...ee/patch-1 21:18
oh, and a mvmheap file and a one-liner
perl6 -I . -M App::MoarVM::HeapAnalyzer::Model -e 'my $m = App::MoarVM::HeapAnalyzer::Model.new(file => "/tmp/ca.mvmheap".IO); my Supplier::Preserving $s .= new; start { react { whenever $s { .say } } }; my $foo = $m.get-snapshot(1, updates => $s); say $foo.perl' 21:19
i can't for the life of me figure out why it's upping the value one time more than the target
and it's been driving me mad for like two days now
21:42 pamplemousse left 22:20 chloekek left 22:41 MasterDuke left 22:43 pamplemousse joined 23:16 pamplemousse left 23:46 brrt left

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!