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.
vrurg "Cannot move to outers or callers with non-traversable context" - what is that??? It's just an innocent nqp::ctx! 03:05
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
lizmat further data points: no such problems in Intel 16:04
a lot fewer crashes with .map({ $_ if .is-prime($_)}) 16:07