|
00:11
greppable6 joined
00:24
greppable6 joined
00:34
greppable6 joined
01:48
ilbot3 joined
03:00
brrt joined
05:34
domidumont joined
05:41
domidumont joined
05:59
brrt joined
06:12
domidumont joined
06:14
brrt joined
|
|||
| brrt | i recall having a 'is this expr tree equivalent to this other tree' that would be pretty useful for the optimizer | 06:38 | |
|
06:46
brrt joined
06:52
Ven joined
07:12
brrt joined
07:26
zakharyas joined
07:39
nine joined
07:40
camelia joined
|
|||
| brrt | i'm thinking of things that really need fixing prior to merging. it's not that much anymore | 07:42 | |
| i guess we would like to have a proof-of-concept type specialization in the JIT | |||
| nwc10 | as in, "soemthing that demonstrates that the API actually will work as planned" before committing to the API? | 07:44 | |
| brrt | yes | 07:45 | |
| same for the optimizer, i guess | 07:46 | ||
|
07:48
camelia joined
07:52
Ven joined
|
|||
| brrt | hmm | 08:14 | |
| maybe i'm just going to reorganize the plan file to indicate what really needs doing | |||
| jnthn | morning! o/ | 08:43 | |
| brrt | morning jnthn | 08:44 | |
| would you have some time today to discuss the plan of action for merging even-moar-jit | |||
| i mean, i'm running out of blockers | |||
| jnthn | brrt: Yes, I can make time for that :) | 08:46 | |
| brrt | nice :-) | ||
| i'm at $dayjob atm, so i don't have time right now myself | 08:47 | ||
| jnthn | :) | 08:48 | |
| Me too, but Perl 6 is my $dayjob at the moment :) | |||
| brrt | hehe | 08:50 | |
| that's nice | |||
| i'm in perl5 land, still, which is also pretty nice | |||
| jnthn | Mine varies, which is also quite nice in that I get to see new stuff now and then :-) | 08:52 | |
|
08:59
robertle joined
09:55
Ven joined
10:42
robertle joined
11:02
AlexDaniel joined
11:48
harrow joined
12:52
bisectable6 joined
14:56
greppable6 joined
|
|||
| robertle | if I want to return a number from a moar op, but want to return undef in some cases, what do I do? return a MVMObject*? I currently use a MVMint64 which can't do undef. if that is right, how do I create the object from the int? MVM_repr_box_int? | 15:19 | |
| jnthn | That sounds like an odd thing to want to do at op level | ||
| MVM_repr_box_int is the way to get an int object though | 15:20 | ||
| And you can find the type to pass for it for the current language via hll_config | |||
| robertle | I am only fooling around, trying to learnn | 15:21 | |
| jnthn | (See src/core/hll.h for relevant functions) | ||
| Ah, OK ;-) | |||
| Than carry right on :-) | |||
| robertle | as a toy project, I want to make the thread scheduler default to a number of threads that is the number of cores on the system rather than 16 | ||
| I reckoned that determining the number of cores is best done in the VM, as it is target-specific | |||
| jnthn | I think there's a libuv function to get that | 15:22 | |
| robertle | so I added a op for that, and wired ti through nqp into rakudo where it is used | ||
| instead of the 16 that is | |||
| jnthn | Trouble is | ||
| robertle | now the part that determines the numebr of cores is operating system specific, so if I can't figure it out I still want to use 16 | ||
| but I don't want to put the number 16 into moar, rather into rakudo where it was | |||
| hence the idea to returna number or undef i the vm doesn't know | 15:23 | ||
| or can't be asked ;) | |||
| jnthn | The right number of threads is really a dynamic rather than a static property | ||
| robertle | if lubuv has a poortable way to determine the number of cores, that would be great, will hceck | ||
| jnthn | I think I saw it in uv.h, yeah | ||
| Either way it's useful information to expose | |||
| robertle | right, but currently it is static and 16, I would make it static and depenmding on the hardware | 15:24 | |
| of course you could still override through env | |||
| jnthn | Sure, though my eventual plan is that it will auto-tune | ||
| Like adding threads when it looks like stuff is deadlocked | |||
| But otherwise trying not to create so many | |||
| robertle | that sounds super | 15:25 | |
| jnthn | Though the number of cores is a goodish factor into that | ||
| Zoffix | Autotune? Will we be releasing a lot of poor quality music? :D | ||
| jnthn | so it's a useful op to have however we do it | ||
| Zoffix: haha :D | |||
| robertle | as I said, just fooling around | ||
| jnthn | So far as "don't know" goes though, I'd just return 0 | ||
| There's no semi-predicate issue because if a machine has 0 cores it in, well, what's running our code :D | 15:26 | ||
| *in it | |||
| robertle | right, that is better than undef, or at least lighter | ||
| now that uv function removes the need to do anything platform-specific, which is a shame because that's one of the things I was trying to play with | 15:29 | ||
| timotimo | Zoffix: you don't seem to know about "Auto-tune The News", which is good quality music ;) | 15:30 | |
| jnthn | I have a really bad idea. If it's me who works on the scheduler auto-tuning thing, then I could give a talk...then we can autotune the video. :P | 15:31 | |
| Zoffix | :) | 15:32 | |
| jnthn | If it works for the news, it's sure to work for Perl 6 talks too :P | 15:33 | |
| timotimo | only new perl6 talks | 15:34 | |
|
15:41
greppable6 joined
16:18
mst joined
16:36
greppable6 joined
16:37
greppable6 joined
16:54
domidumont joined
17:20
domidumont1 joined
17:25
domidumont joined
|
|||
| timotimo | does HASH_DELETE somehow impact the value pointed at by the hash? it seems to null out the st | 17:46 | |
|
17:50
robertle joined
|
|||
| timotimo | time fore --optimize=0 | 17:50 | |
| rr isn't helping me very much because i only get to see "it's inside the HASH_DELETE (or HASH_BIND) macro", but not what code it's executing, and the disassembly isn't helping terribly much | 18:24 | ||
|
19:56
brrt joined
|
|||
| brrt | \o | 20:07 | |
| timotimo | o/ | 20:36 | |
|
20:51
committable6 joined
|
|||