| IRC logs at
Set by AlexDaniel on 12 June 2018.
07:38 domidumont joined
nwc10 good *, #moarvm 07:57
08:49 domidumont left 08:53 sena_kun left 09:00 frost-lab joined 09:01 zakharyas joined 09:02 zakharyas left, zakharyas joined 09:03 sena_kun joined
MasterDuke hey hey 09:34
jnthn: would it make sense to add the capability to "reset" spesh? or would the incoming ability to remove specific optimizations be sufficient? 09:36
i was thinking of this because there were a couple cases recently where people were benchmarking by running several similar pieces of code in a single script, but the later pieces were "artificially" slowed down because spesh had optimized for the first piece 09:39
i.e., the pieces when run by themselves had much more similar timings than when timed as part of a single script 09:41
09:56 cog left 09:57 cog joined 10:00 lizmat joined
jnthn MasterDuke: No, I think they should just run those in separate processes, pretty much. Spesh is only one source of noise. 10:05
Of course dropping bad choice specializations is also a good thing, and may help such situations too 10:06
MasterDuke k 10:13
10:41 Kaiepi left 10:51 squashable6 left 10:52 squashable6 joined, squashable6 left 10:53 squashable6 joined 10:55 domidumont joined 11:25 Kaiepi joined 11:33 avarab left 11:34 avar joined 11:35 Kaiepi left, frost-lab left 11:37 Kaiepi joined 11:52 zakharyas left 12:55 zakharyas joined
MasterDuke i've been thinking about and i wonder if it'd make sense to just get rid of nqp::time_n and change nqp::time_i to return nanoseconds 14:43
greppable6: nqp::time_n 14:52
greppable6 MasterDuke, 33 lines, 5 modules:
MasterDuke those shouldn't be terribly difficult to create PRs for. and if doing so means now() is much faster, maybe they can be converted to use it instead of the nqp op 14:54
is there a strong reason i don't know about for having time available as num/floating point? 14:58
moon-child not afaik. If you need high precision, way to go is fixedpoint + 14:59
MasterDuke java and javascript only gives millis, but they can just multiply by 1000000 instead of the current behavior of dividing by 1000.0 15:08
wrong window 15:09
lizmat MasterDuke++ 15:16
re nqp::time_i and nqp::time_n
but perhaps to remain a little compatible, add a new nqp::time_ii ?
to at least make the transition easier ? 15:17
inside core and outside of it ?
MasterDuke greppable6: nqp::time_i 15:26
greppable6 MasterDuke, Found nothing!
MasterDuke there really aren't that many uses of time_(i|n) in the core. ~30 in nqp and ~70 in rakudo 15:28
15:34 rba left, rba joined, zakharyas left 15:35 bonsaikitten left 15:36 xiaomiao joined 15:38 nine left, avar left, nine joined, avar joined, avar left, avar joined 15:39 lizmat left
MasterDuke hm, if there's only one variant of an op it doesn't have an '_(i|n|s|o)', right? so i'd be removing `time_n` and changing `time_i` to just `time` 16:32
16:37 zakharyas joined 16:42 Kaiepi left 16:43 Kaiepi joined
jnthn Yes, that's follow the convention 16:57
*followed 16:58
MasterDuke moarvm changes only took a couple min, but time for dinner, etc. hopefully will see how easy nqp/rakudo changes are this evening 17:02
17:19 MasterDuke left
nine jnthn: why is BB 0 not a successor of blocks that are covered by an exception handler? 17:20
jnthn If it were, we'd not have a unique dominator. iirc, BB0 is always empty and largely there for this purpose. 17:32
(To be clear, not block that dominates all other blocks of the graph) 17:34
17:41 domidumont left
nine What is the mechanism then that's supposed to tell the phi builder to consider writes that happened before a handler area? I.e. in `set r1(1), 1; [FH Start] die; set r1(2), 2; [FH End] takehandlerresult r2(1); phi r1(3) r1(1) r1(2) return_i r1(3);` we definitely need that phi, since it's not guaranteed that the set r1(2), 2 happens 17:42
17:43 patrickb joined
nine All other types of branching are handled via successors respectively the dominance frontier set 17:43
jnthn Successor edges 17:44
Maybe there's an edge missing? 17:45
nine Which one would that be?
If it's successors, then I'd say that every BB that contains a throwish op such as invoke must have an edge either to BB 0 or at least to the BB containing the takehandlerresult op 17:47
(if covered by a FH)
jnthn Potentially to the handler part of all handlers that we are in 17:49
Which is what I've done in another project recently, anyway
That'd in principle mean the edges for BB 0 to the handlers could go away 17:50
Well, modulo inlining fun
Yeah, looks like that (extra successor edges) is exactly what's needed. I think they may well already be added for control exception handlers, though...hmm 17:52
See 17:53
nine Ah, yes, now that I see that I did wonder why control exception handlers are handled specially there but not others 17:54
jnthn And then
nine There is extra code for making that differentiation which I assumed was there for a very good reason
jnthn But what's a bit curious is that a return exception handler is a control exception handler 17:55
So it should already be getting these edges
nine The method in question is 17:56
I.e. it's not about the return control exception but an adhoc exception thrown by find_symbol 17:57
jnthn Ohh...this is a catch handler
I bet Rakudo's code-gen always introduces sufficiently many blocks to never really trip this (and/or the presence of the CATCH succeed handlers makes up for it somehow) 17:58
Thus why we've got away with it for so long
But yeah, I'd solve this by introducing the edges for all kinds of exception 17:59
nine I do have the suspicion that the flapper in t/spec/S17-supply/return-in-tap.t is caused by this, too, but have not yet been able to confirm it
Ok, I can work with this. Thanks a lot! :)
jnthn Welcome 18:00
nine++ # no fear of spesh :)
18:22 lizmat joined 18:44 vrurg left 19:02 vrurg joined
patrickb o/ 19:04
19:06 vrurg left
nwc10 \o 19:07
patrickb nwc10: I'd value your opinion on 19:08
nwc10 right now is so I can't really look 19:10
19:19 zakharyas left
patrickb Mo hurry. 19:28
20:36 vrurg joined 21:06 vrurg left, vrurg joined 21:09 patrickb left 21:10 zakharyas joined 21:12 MasterDuke joined
MasterDuke whoops, removing them means nqp won't build. have to add time, rebootstrap, then remove time_(i|n) 21:16
nine Incredible! A week of hardcore debugging. A day to formulate the right questions to jnthn. And the fix turns out to be deleting just 4 lines of code. 21:27
MasterDuke did you beat my not-very-serious 15m estimate? 21:28
nine Looks like :D 21:29
japhb Solution: remove the wrong bits.
21:29 nebuchadnezzar left 21:30 nebuchadnezzar joined
nwc10 Technically this is off topic on every channel I might (or might not) be on, but -- he machine is quite fast… the compile time and run time is about 30% faster than a recent MacBook Pro 16 (2.4 GHz 8-Core Intel Core i9 with 32 GB 2667 MHz DDR4). 21:30
this is "recent MacBook Pro" vs M1 mac mini
sort-of-relevance is "likely x86_64 is no longer the only CPU in town" 21:31
and, as I understand it, the M1 is the "low spec" chip. I'm wondering what comes next. 21:32
nine At least I get through a full rakudo build with MasterDuke's patch for logging undefined results of decont. It still errors in a couple of tests. But these may be due to an unrelated issue or the 4 lines simply aren't enough after all. Alas, it's very encouraging progress :) 21:33
nwc10: well the ceiling for that chip will be how much memory they can stack on top of it. I'm pretty sure the amazing performance is mostly a result of blazingly fast (and low latency) access to the stacked memory. 21:35
MasterDuke nine++ 21:39
nwc10 not thought of that (and ahd assumed that there were some other reasons it was fast(er) - we shall see. But do remember that Rasbperry Pi 8GB only came once a chip existed. That thing is 16GB
so is 16BG around the current limit of "chips you can stack?"
I think that the largest machine I currently have access to is 256GB. That's a bit different. 21:41
21:45 zakharyas left
MasterDuke i used to have access to machines with 768gb. i mostly stopped caring how much memory it took to solve a problem 21:46
21:46 vrurg left
nwc10 I think ex-work ex-main-DB server had 768gb. (But there was one of it). I don't know what the replacement had. I don't know if I ever logged into it 21:48
On the "old" architecture the 768gb machine was also the "god box"
the new architecture was more sane.
eg - you do not want you NFS server to also be the DNS server, because if it needs to fsck its disks it will be single user for a long time, and ... 21:49
but you can shorten that to
"you do not want NFS"
japhb At Google we found interestingly enough that the limiting factor was often not the actual memory of the machine, but how many containers you could pack into it while still monitoring and managing them all. People used to working on smaller servers would often try to be super memory-efficient with their containers, and you'd find like half the RAM of the physical machine was essentially idle because all the 21:52
containers used up all the CPU and there wasn't enough cacheable stuff to productively use the remaining RAM.
MasterDuke i've never been responsible for setting up an alternative. and i don't ever want to be. but i've never had a good experience with nfs 21:53
those machines were overkill for probably about 98% of their use. but i did push their limits a couple times 21:59
timotimo: is there anyway for the appimages to run files? or are they completely limited to -e? 22:05
22:06 vrurg joined
MasterDuke oh, giving them as an absolute path works. but unfortunately not if they then try to open files... 22:07
22:11 vrurg left 22:30 dogbert11 joined 22:31 dogbert12 joined, dogbert12 left 22:32 dogbert12 joined
MasterDuke Stage start      : 68450.000 (i suspect i've forgotten to scale a value somewhere...) 22:32
22:34 dogbert17 left 22:35 dogbert11 left