Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-05-26

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:05 geekosaur joined #moarvm
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
04:02 KDr2 joined #moarvm
05:04 samcv joined #moarvm
05:35 geekosaur joined #moarvm
06:57 domidumont joined #moarvm
07:02 domidumont joined #moarvm
08:06 zakharyas joined #moarvm
09:06 robertle joined #moarvm
10:29 AlexDaniel joined #moarvm
10:49 zakharyas1 joined #moarvm
11:16 MasterDuke timotimo: this is somewhat related to that discussion of a hardware implementatin of MoarVM https://blog.acolyer.org/2017/05/22/typed-architectures-architectural-support-for-lightweight-scripting/
11:25 zakharyas joined #moarvm
11:27 zakharyas1 joined #moarvm
12:18 domidumont joined #moarvm
12:36 MasterDuke MVM_radix and MVM_string_split (for example), both create the result like so: MVM_repr_alloc_init(tc, MVM_hll_current(tc)->slurpy_array_type)
12:37 MasterDuke and then MVM_repr_push_o int_box_type or str_box_type respectively
12:37 MasterDuke is there a reason those couldn't be bootintarray and bootstrarray?
14:29 JimmyZ MasterDuke: I think it can be bootintarray or bootstrarray.
14:32 MasterDuke JimmyZ: i don't see a whole lot of BOOT(Str|Int)Array's being created in MoarVM
14:32 MasterDuke is there a reason they aren't very common?
14:34 JimmyZ MasterDuke: MoarVM has no bootintarray or bootstrarray earlier.
14:35 JimmyZ MasterDuke: maybe just we don't need to it too much .
14:36 MasterDuke is there another option?
14:36 * JimmyZ can't understand it
14:38 JimmyZ only a little moarvm op  returns BOOT(Str|Int)Array
14:40 MasterDuke MVM_string_split returns a MVMObject * that's created by `MVM_repr_alloc_init(tc, MVM_hll_current(tc)->slurpy_array_type)`. could it instead just return a MVMString **
14:41 JimmyZ I don't think you can
14:41 MasterDuke or from the other direction, it's a list_o in NQP, what's the most efficient way to make it a list_s?
14:42 JimmyZ nqp knows nonthing  about MVMString **
14:42 JimmyZ they only knows list_o or list_s
14:42 JimmyZ and so rakudo
14:43 JimmyZ or knows list_i
14:44 MasterDuke and is creating BOOT(Str|Int)Arrays the only way to create list_(s|i)s?
14:44 JimmyZ BOOT(Str|Int)Arrays is list_o
14:44 JimmyZ BOOT(str|int)Arrays is list_s or list_i
14:50 MasterDuke JimmyZ: do you know of any downside to converting e.g. MVM_radix and MVM_string_spit to return BOOT(Str|Int)Arrays?
14:52 JimmyZ you mean bootintarray and bootstrarray?
14:53 JimmyZ MasterDuke: I don't think there will be any downside.
14:54 JimmyZ MasterDuke: I wanted to do it, but there were no bootintarray and bootstrarray
14:54 MasterDuke JimmyZ: and upsides? will that be more efficient?
14:55 JimmyZ MasterDuke: less GC
14:55 JimmyZ MasterDuke: maybe faster for compiling rakudo etc.
14:56 JimmyZ MasterDuke: and less allocation
14:56 MasterDuke ah ha. maybe i'll try to make that change
14:59 JimmyZ MasterDuke: there is MVM_bigint_radix too, but this one seems that it can't be chaned.
14:59 MasterDuke oh?
14:59 JimmyZ MasterDuke: because of bigint
15:00 MasterDuke ha, right, of course
15:51 * nine didn't realize that the new jit was an extension of the old jit rather than a replacement
15:57 * JimmyZ too
15:59 * MasterDuke three
16:39 brrt joined #moarvm
16:39 brrt .tell nine that it is supposed to be one of those 'viral replacement' deals
16:39 yoleaux brrt: I'll pass your message to nine.
16:40 timotimo yo brrt
16:40 brrt i.e. ultimately nothing passes through the old jit and everything through the new one, but until that happens the 'infrastructure' for the JIT remains stable
16:40 brrt \o timotimo
16:42 timotimo i'll suspend my laptop and go hunt food
16:46 brrt reasonable plan
16:59 domidumont joined #moarvm
17:17 robertle joined #moarvm
17:29 camelia joined #moarvm
17:47 japhb joined #moarvm
17:51 brrt joined #moarvm
18:25 brrt ugh, sp_fastcreate breaks and i have no idea why
18:41 timotimo well, how did you implement it?
18:52 brrt as a template
19:12 bisectable6 joined #moarvm
19:24 brrt joined #moarvm
19:34 timotimo obviously :)
19:35 timotimo i had hoped to maybe see the code and take a wild guess
20:18 brrt https://gist.github.com/bdw/62320648e0fe0be34684298f4f51b8d5 take a look
20:18 brrt that's all info i have
20:21 timotimo brrt, are you making sure to set a 32bit value for the owner in the header?
20:21 timotimo otherwise you'll be setting stuff in the flags i bet
20:22 MasterDuke 50% more movs in the new jit output. timotimo you promised fewer of them!
20:22 brrt joined #moarvm
20:22 timotimo heh.
20:23 timotimo this is just a single piece of code
20:23 timotimo i told you we onl yget fewer movs if there's chunks of consecutive new-jitted instructions
20:25 timotimo brrt: did you read my random idea?
20:25 brrt yeah, seen it
20:25 timotimo is it useless? does setf already know about field sizes?
20:26 brrt MasterDuke: that's true, but those things can be solved by an optimizer
20:26 brrt not sure
20:26 brrt but the mov's seem to be correctly sized
20:26 timotimo hm, ok
20:26 timotimo tbh, i have some difficulty understanding what's going on inside the assembly output
20:54 brrt joined #moarvm
20:55 brrt we load the constant size (0x88)
20:55 brrt we set up the arguments (rdi = r14, rsi = rcx (= our constant))
20:56 brrt we call the function (that works as advertised, i checked)
20:56 brrt we return and move the return value to the allocated register (rdx)
20:56 brrt we restore our constant to rcx from memory
21:40 timotimo and more afk and such
21:49 Geth ¦ MoarVM: robertlemmen++ created pull request #604: new "hardware_concurrency" op
21:49 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/604

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary