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