|
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 | |