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:00 reportable6 left 00:03 reportable6 joined 01:13 japhb left
MasterDuke ooh, i think i have a relatively simple change that speeds up startup/deserialization. not by a whole lot of wallclock, but instructions reported by callgrind for `raku -e ''` do go down: as is, with MVM_SPESH_BLOCKING=1, and with MVM_SPESH_DISABLE=1 01:21
we deserialize almost 90k VMArrays. in it's deserialize(), we loop over the number of elems, and switch based on the array type what we read. but the array type doesn't change per element, so it's a bit of code duplication, but just moving/copying the loop inside each case makes a difference 01:26
with MVM_SPESH_DISABLE=1 we go from ~626k to ~623k instructions and with MVM_SPESH_BLOCKING=1 from ~1.135b to ~1.132b instructions 01:31
01:34 japhb joined
Geth MoarVM: MasterDuke17++ created pull request #1738:
Speedup VMArray's deserialize()...
Voldenet nine: and high level code will require some additional allocations which will increase startup time, it's a good tradeoff though 03:48
MasterDuke: I've read some blogpost about rust doing 2x more instructions than C code in the same time and vtune revealed that cpu itself was able to optimize it very well, keep that in mind 03:59
04:29 linkable6 left, evalable6 left 04:30 evalable6 joined 04:31 linkable6 joined
Woodi "everything is a first class object" - do that means that it need to be created via mop or can be just loaded or allocated in ready shape from C ? what exactly are unavoidable costs ? becouse years flys... 04:40
also got thinking: benchmarks show nqp and rakudo is more costly - so maybe there things need to be optimized ? like in startup path using only primitive types like native arrays instead of hashes, uint64_ counters instead of packed numbers, etc ? 04:42
and removing things that keep allocating and deallocating on startup... 04:44
06:00 reportable6 left 06:03 reportable6 joined 07:03 bloatable6 left, notable6 left, sourceable6 left, greppable6 left, committable6 left, benchable6 left, bisectable6 left, shareable6 left, unicodable6 left, squashable6 left, quotable6 left, coverable6 left, reportable6 left, releasable6 left, nativecallable6 left, statisfiable6 left, evalable6 left, tellable6 left, linkable6 left, coverable6 joined, evalable6 joined, sourceable6 joined 07:04 statisfiable6 joined, releasable6 joined, reportable6 joined, tellable6 joined, notable6 joined, bisectable6 joined, nativecallable6 joined, committable6 joined, linkable6 joined, benchable6 joined 07:05 greppable6 joined, shareable6 joined, unicodable6 joined, quotable6 joined 07:06 bloatable6 joined, squashable6 joined 07:38 sena_kun joined
timo1 the majority of our classes get their layout, i.e. fields and attributes and such, deserialized cheaply, not created with MOP calls during startup 08:12
i don't know what you mean by packed numbers 08:13
nine probably boxed numbers 08:17
timo1 ah
08:25 harrow left 08:52 harrow joined 10:30 sena_kun left 12:00 reportable6 left, reportable6 joined 14:37 epony left 14:44 epony joined 18:00 reportable6 left 18:01 reportable6 joined 18:36 sena_kun joined 20:17 bisectable6 left, bloatable6 left, notable6 left, nativecallable6 left, committable6 left, statisfiable6 left, tellable6 left, sourceable6 left, shareable6 left, unicodable6 left, releasable6 left, benchable6 left, greppable6 left, reportable6 left, evalable6 left, squashable6 left, coverable6 left, linkable6 left 20:18 squashable6 joined, sourceable6 joined, greppable6 joined, reportable6 joined, bisectable6 joined, evalable6 joined, releasable6 joined, bloatable6 joined 20:19 benchable6 joined, unicodable6 joined, coverable6 joined, notable6 joined, shareable6 joined, linkable6 joined, tellable6 joined, committable6 joined 20:20 nativecallable6 joined, statisfiable6 joined 22:09 sena_kun left