github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:45 sena_kun left 01:01 sena_kun joined
timotimo if you do mp_init_copy to initialize i_cpy, then you'll have to also mp_clear(i) so that the buffer it hangs on to gets freed 01:28
i assume the whole dance is there just to avoid clearing that buffer immediately after making a copy of it 01:30
02:46 sena_kun left 03:00 sena_kun joined 03:19 tobs left 03:23 tobs joined 04:46 sena_kun left 05:00 sena_kun joined 06:00 nativecallable6 joined, notable6 joined, greppable6 joined 06:01 linkable6 joined, releasable6 joined, coverable6 joined, benchable6 joined, unicodable6 joined, sourceable6 joined, quotable6 joined 06:02 statisfiable6 joined, evalable6 joined, bisectable6 joined, reportable6 joined, tellable6 joined, squashable6 joined 06:03 shareable6 joined, bloatable6 joined, committable6 joined 06:45 sena_kun left 06:59 sena_kun joined 07:31 domidumont joined 07:32 domidumont left 07:34 domidumont joined 07:49 AlexDaniel joined, AlexDaniel left, AlexDaniel joined 08:28 zakharyas joined 08:46 sena_kun left 09:01 sena_kun joined 10:16 Kaiepi joined 10:46 sena_kun left 11:01 sena_kun joined 12:03 AlexDaniel left 12:21 zakharyas left 12:45 sena_kun left 12:58 lucasb joined 13:01 sena_kun joined 14:06 zakharyas joined 14:17 gugod joined 14:42 AlexDaniel joined, AlexDaniel left, AlexDaniel joined 14:44 sena_kun left 14:56 AlexDaniel left 15:01 sena_kun joined 16:04 brrt joined, hungrydonkey joined
brrt good * 16:05
tellable6 2020-01-29T10:05:07Z #moarvm <jnthn> brrt I don't have time to look myself for a bit, but in case you do: github.com/MoarVM/MoarVM/issues/1230
brrt .tell jnthn that I'm aware, and have a theory on how to fix it
tellable6 brrt, I'll pass your message to jnthn
brrt (but for whatever reason, or reasons, I haven't had much time to spend on MoarVM lately :-( ) 16:06
16:15 hungrydonkey left, hungrydonkey joined, hungrydonkey left 16:16 hungrydonkey joined 16:33 brrt left 16:38 zakharyas left 16:39 zakharyas joined 16:45 zakharyas left 16:47 sena_kun left 17:00 sena_kun joined 18:02 hungrydonkey left
lizmat and another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/02/03/2020-...eleasalot/ 18:04
18:10 domidumont left 18:31 patrickb joined 18:46 sena_kun left 19:01 sena_kun joined 19:42 domidumont joined 19:43 domidumont left
patrickb brrt: Spontaneous GSoC project idea: A mod_moar Apache or Nginx module. You did mod_parrot back in the day. What's your opinion about such a thing? Worth it? Could you imagine mentoring? 19:47
tellable6 patrickb, I'll pass your message to brrt
patrickb brrt: By the way, did you hear back from pamplemousse? 19:48
tellable6 patrickb, I'll pass your message to brrt
20:45 sena_kun left 21:00 sena_kun joined 21:07 brrt joined 21:44 patrickb left
timotimo m: say 0x7ff 22:15
camelia 2047
timotimo m: say 0x7ffff
camelia 524287
timotimo ho-hum, for all numbers between 0 and 16k we'll be using 127 * 1 + 2047 * 2 + 14k * 3 bytes 22:16
so maybe just using 16bit numbers for everything is a save rather than a waste 22:17
MasterDuke what do we use now?
timotimo moarvm bytecode 22:22
12 bytes per number
MasterDuke that seems a lot 22:24
timotimo it is
having an int array with 3 bytes per number is also better than a pushcode op which would have 6 bytes per number 22:27
m: say 16 * 9, " kilobytes saved"
camelia 144 kilobytes saved 22:28
timotimo out of 14 megabytes, that's about 1%? 22:29
MasterDuke i see all those prepargs; invoke_v;, but what is generating them? 22:34
timotimo surely there's also a few low-hanging fruit with regards to unnecessary frames
just scrolling up a tiny bit shows me that this line: 22:35
(die "Incorrect number of elements for non-associative operator: expected 2, got {nqp::elems(list)}")
gets its own frame for the nqp::elems part
and the frame also goes the extra mile and saves $_ away before 22:37
BBL 22:38
22:47 sena_kun left 22:49 brrt left 23:02 sena_kun joined 23:46 hungrydonkey joined