Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:48 epony joined 02:07 epony left 02:10 epony joined 02:52 epony left 02:54 epony joined
vrurg "Cannot move to outers or callers with non-traversable context" - what is that??? It's just an innocent nqp::ctx! 03:05
08:50 epony left 08:51 epony joined 10:00 sena_kun joined 10:49 sena_kun left
lizmat m: say (^Inf).race.grep(*.is-prime)[999999] 12:50
camelia 15485863
lizmat m: say (^Inf).race.grep(*.is-prime)[999999]
camelia 15485863 12:51
lizmat m: say (^Inf).race.grep(*.is-prime)[999999]
camelia 15485863
lizmat m: say (^Inf).race.grep(*.is-prime)[999999]
camelia 15485863
lizmat m: say (^Inf).race.grep(*.is-prime)[999999]
camelia 15485863
lizmat FWIW, this either produces the correct result (like here) or segfaults 50% of the time on a M1 12:53
m: say (^Inf).race.grep(*.is-prime).skip(999999).head 12:54
camelia 15485863
lizmat this crashes almost always for me
doesn't crash with MVM_SPESH_DISABLE=1 for me, but takes 3x as long 12:56
doesn't crash with MVM_SPESH_INLINE_DISABLE=1 either, and is only 35% slower 12:59
also crashes with MVM_SPESH_OSR_DISABLE=1 13:00
conclusion: something with inlining
found some differences in the spesh inline log between runs: 13:12
Can inline cont (16074) with bytecode size 38 into run-one (16121) => True
Can inline unspecialized cont (16074) with bytecode size 60 into run-one (16121) => True
Can NOT inline emit (17071) with bytecode size 610 into emit (17085): bytecode is too large to inline => True
Can NOT inline emit (17071) with bytecode size 616 into emit (17085): bytecode is too large to inline => True
afk& 13:14
14:37 epony left 14:47 sena_kun joined 15:05 epony joined
lizmat further data points: no such problems in Intel 16:04
a lot fewer crashes with .map({ $_ if .is-prime($_)}) 16:07
16:52 epony left 16:53 epony joined 20:36 epony left 21:15 epony joined 23:03 sena_kun left