github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:13 dogbert11 joined 00:16 dogbert17 left 00:28 japhb joined 01:08 squashable6 left 01:11 squashable6 joined 01:32 MasterDuke left 01:37 dogbert11 left 02:26 leont left
nwc10 good *, #moarvm 06:36
07:03 ZzZombo joined 07:04 ZzZombo left 08:13 domidumont joined 09:58 zakharyas joined
jnthn o/ 10:00
nwc10 \o 10:02
10:30 El_Che joined
El_Che jnthn: fyi so far all the distro have zstd libs except the EL family (RHEL, Centos, Amazon Linux, Oracle Linux) 10:31
jnthn: I mean in the official repos. Centos has i through EPEL, but you don't want to depend on that 10:32
nwc10 El_Che: Sereal bundles zstd - I don't know if there's any insight in how they do it, as to where the portability traps are 10:34
ie metacpan.org/source/YVES/Sereal-De...8/MANIFEST
10:37 El_Che left, El_Che joined
El_Che nwc10: moarvm bundles already stuff. Maybe it can be used as a fallback? 10:38
jnthn Is it frowned upon to bundle things for distros when they *don't* package it? 10:40
I know Debian is very strict on these things.
El_Che they recently added one package of mine to the distro that has a freeware/abandoned (but licensed) source in a dir 10:41
let me check what they did with it
they kept it in the package 10:44
(even if that directory has a different license than the rest of the program) 10:45
jnthn Could be one way to provide the dep reliably: depend on a package where possible, bundle where not 10:46
By my instincts on these things aren't always in agreement with what those producing distros like :) 10:47
El_Che well, rhel 8 will be EOL'ed in 2029 (and even then extra paying customers can keep using it for years) 10:49
anyways, if someone wants to test drive this, it would be nice so I can fix if something is broken: github.com/nxadm/rakudo-pkg/blob/m...evbuild.md 11:30
in short, it builds rakudo/nqp/moarvm/zef on a bunch of systems, runs test in debug and hopefully keeps core files when segfaults happen 11:31
11:40 leont joined
nine It seems to me that the best way is to simply provide a package of zstd for distros that don't ship it and have moar depend on that for those distros. 11:52
El_Che (if it sucks, tell me, so I can change it to something useful) 11:53
nine I'm not aware of a distro that openly welcomes bundled libraries. There's just varying degrees of strictness (with Debian being close to the strict end of the spectrum) 11:55
11:58 zakharyas left
nwc10 was in a meeting. and then at lunch 12:17
what I was meaning was
1) I was assuming the same plan as other things we bundle - option to use the bundled version or the system vedrsion 12:18
2) Sereal already bundles zstd - maybe there are some tricks to do it (how they do the makefile) that we could steal if it isn't as easy as it shuld be
12:29 sivoais_ joined 12:31 sivoais left
jnthn When you discover there's a middle 80% between the first and second ones you expected... 15:31
nwc10 oh my 15:32
15:33 zakharyas joined 15:58 patrickb joined 16:48 dogbert11 joined, dogbert11 left 17:11 dogbert17 joined 17:57 codesections joined
jnthn OK, mostly handled that. Also, my test case that I expected to need further work before it would pass...passes. This isn't entirely good because it means I've overlooked something. Though probably in the test case. 18:11
Gotta wire up some extra GC marking too as its passing by luck. But...should give my poor arm a rest first. 18:14
18:16 domidumont left 18:39 zakharyas left 18:55 MasterDuke joined
nine Yes. Arms are...kinda important 18:56
MasterDuke huh, i feel i missed some important context 18:58
nine Some trouble with the hardware
MasterDuke i wasn't free to look into my segv today, but hopefully will have some time tomorrow night. nine, i assume you didn't find anything else yesterday besides that there's an NQPMatch instead of an MVMSpeshCandidate in that slot? 19:34
19:55 evalable6 left, linkable6 left 19:56 evalable6 joined 19:57 linkable6 joined
nine right 20:31
timotimo haven't kept up with stuff, but finally got my new work device and when trying to build an nqp, i get a "cannot invoke VMNull" inside of build-hll-sysconfig 20:45
odd.
ah, could have been because fedora installs only a partial perl 20:47
stage parse is 54 seconds 20:48
20:57 patrickb left 21:05 zakharyas joined
dogbert17 54 seconds is pretty good, what did you get on your old machine? 21:06
timotimo will need to check later when my old machine isn't busy :) 21:07
dogbert17 something tells me that your new machine is faster :) 21:14
21:28 zakharyas left 21:40 rypervenche joined
MasterDuke jnthn: it's amazing how many 80%s fit in 100%. it's like that series that sums to whatever you want it to, i think 1/1 - 1/2 + 1/3 - 1/4 + ... + 1/(n-1) - 1/n 21:50
timotimo: i'm pretty sure the situation is the same as wherever you left off. i'm 90% done with a random project and stuck in some gc problem... 21:52
nine MasterDuke: always feels like that, doesn't it? :) 21:54
MasterDuke welcome to the new project, same as the old project... 21:55
i do manage to learn a little bit more each time, but it doesn't feel like a fast process 21:57
jnthn MasterDuke: Hah, yes :) 21:58
tellable6 2021-02-12T21:10:05Z #raku-dev <japhb> jnthn: Did you design react to avoid starvation of whenevers under heavy load? See question from last night ^^
nine Well, because it isn't. This stuff is hard.
jnthn Thankfully I figured out a solution to this one :) 21:59
Mostly by realizing there was a way not to be clever, looking at all the bookkeeping the clever way would need, and realizing that the not clever way was likely going to be as fast anyway. 22:00
As a bonus, I can feel quite confident this solution is correct.
(Famous last words!)
nine MasterDuke: the NQPMatch object gets put into that spesh slot when inlining something
jnthn My test case was also off by one, meaning that it covers the thing I just implemented, but not the next thing I need to implement. 22:01
MasterDuke nine: oooh, you're right. the build (of that first file) succeeds if i add MVM_SPESH_INLINE_DISABLE=1 22:02
jnthn Huh, my Raku example for wrapped methods at multiple levels of inheritance also all works. 22:04
MasterDuke nine: i'm not sure if that's the source cause though. if i remember correctly from yesterday, the inline triggers enough calls to spesh_add_slot that there's a realloc
nine jnthn: I find it even more unnerving when something unexpectedly works rather than unexpectedly fails 22:05
MasterDuke: there is a realloc, but I traced it further
jnthn Yeah, I just made a more complex example and it worked too o.O 22:06
OK, I'm going to look at this tomorrow with a fresh brain.
MasterDuke oh, the slots are fine after the realloc?
nine MasterDuke: oh, I know something! 22:07
MasterDuke: look at merge_graph in src/spesh/inline.c
MasterDuke: when inlining, we need to update the inlinee's instructions referencing spesh_slots, because they get renumbered (as the spesh_slots array is appended to the inliner's). Did you update that code to cover the instructions that now use spesh slots? 22:08
i.e. invoke_*?
jnthn ooh, that's a good one 22:09
nine++
MasterDuke i didn't make any change like that in inline.c
jnthn iirc you don't need to change inline.c but oplist should state that it's an sslot register
nine I just saw that that's pretty generic code that uses the op information and operand type. Did you actually update the oplist? 22:10
oplist still says int16
jnthn D'oh.
MasterDuke ha. ugh
nine One of those thousands of details that can get you if you don't know about them :)
jnthn new-disp now handles these things fine: gist.github.com/jnthn/b0e6a33f431a...0869810584 22:11
Meaning my main remaining task from the perspective of Raku semantics is the many details around multi-dispatch 22:12
nine jnthn: I don't think my code uses more complicated things than that. Let's ship it!
MasterDuke wait, but it still is. it's just the index of the tc->cur_frame->effective_spesh_slots instead of an index into <frame->something>->spesh_candidates 22:13
jnthn It has to run vrurg's code too. :)
nine MasterDuke: yes, but you need to change it from int16 to sslot
MasterDuke oh, ah 22:14
nine and don't forget running update_ops.p6
MasterDuke chicken and egg problem here... 22:15
heh. works with MVM_SPESH_DISABLE=1
nine That's the situation where I'm glad that there's rakudo packages for openSUSE... 22:16
or that :)
MasterDuke i used to have the arch rakudo package installed, but i kept getting my zef mixed up
vrurg jnthn: it's soon be time for unfudging the tests? :)
jnthn vrurg: Depends how multi stuff goes, and then once I get things working, I need to do the work to switch Rakudo over to using the new dispatcher everywhere, and NQP the same, and then hunting any fallout 22:17
vrurg jnthn: no doubt. But anyway it looks more like definite terms now, not like "somewhen in the future"! 22:18
jnthn Since I have to re-work aspects of multi-dispatch anyway, I'm going to solve the thing where we have to run the signature binder twice on things with where-clauses or nameds or unapcks: once to bind them, and once again in the actual invoke 22:19
nine MasterDuke: src/jit/x64/emit.dasc:3378 from "mov ARG4, invoke->spesh_cand_or_sf_slot;" to "get_spesh_slot ARG4, invoke->spesh_cand_or_sf_slot;"
MasterDuke hah. and now nqp builds. nine++
jnthn I've also decided in RakuAST that I'm going to try and do away with the slow-path binder and code-generate every case, including the destructuring bind ones.
MasterDuke (with jit disabled)
vrurg is really happy about the news. jnthn++!
jnthn I'm quite sure I will go through moments of regretting that decision while doing it, but the result will be worth it :) 22:20
vrurg jnthn: I know this feeling. :)
MasterDuke nice. normal moarvm build, normal nqp build... 22:22
normal rakudo build... 22:24
and a passing make m-test m-spectest. nine++ again. good to know the code changes were correct, but wow, who knows how long it would have take me to think of that? 22:27
now just need to go back and clean up the commits a bit 22:29
oh, wait. haven't done that invalidating the caller business 22:31
huh. the example that originally started this whole thing is now slightly slower, and produces essentially the same number of deopts (688k) 22:50
m: my $r := "a" .. "za"; my @a = $r[^$r.elems]; say now - INIT now
evalable6 5.25980414
MasterDuke those 688k are for reify-at-least, SETTING::src/core.c/List.pm6:40
i see a couple "Removing a spesh candidate because it was deopted too many times" messages in the spesh log for that reify-at-least 22:52
hm. and if i up the threshold for removing an opt to 1000 deopts, apparently that never triggers? now there aren't any of those message in the spesh log 22:56
23:36 MasterDuke left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!