01:07 jnap joined 01:25 lue joined 01:36 FROGGS_ joined 01:49 cognome joined 03:14 ventica joined 04:12 lue joined 04:30 retupmoc1 joined, hatsefla1s joined 04:35 zakharyas joined 04:36 betterworld joined 04:42 ingy joined, egrep joined
nwc10 jnthn: aafb3aaba4a81fce81ce976af52825158bb33a7a PASS 04:44
04:48 ingy joined 04:53 ventica joined 04:55 ventica2 joined 05:16 egrep left 05:21 brrt joined
brrt jnthn++ for his My First Jit Patch 05:42
07:04 _sri joined 07:09 Ven joined
sergot hi o/ 07:20
brrt hi sergot 07:21
07:37 woolfy left
brrt label management is complex in general, it seems 07:52
but i think i can generalise it and it'll be BETTER 07:57
timotimo brrt: sounds good :) 08:01
brrt i should elaborate by the way 08:02
(by the way, i can't stress enough how much jnthn++ saved me yesterday)
basically, we now assign labels to basic blocks, and we assign magic special labels to osr entry opts
but from the point of view of the assembler, all these labels are of the same type (i.e., dynamic labels) 08:03
i can have pretty much as many of these as i like
my current setup has the osr labels appended to the 'regular' bb labels
because while there is a mechanism to ensure that the same basic block will receive the same label at all times, no such mechanism exists for individual ops - and that is what is needed for OSR labels (and frame handler labels) to work in general 08:04
on the other hand, the only thing that mechanism uses is pointer identity for the basic blocks, so adding ops to that changes nothing 08:05
in fact, with the deopt_all_idx field added to the MVMJitLabel structure, these structures now have all we might need for any of OSR/handler/inline 08:08
we can also remove the special osr label code 08:13
because it will not be special anymore
timotimo :) 08:14
08:39 FROGGS[mobile] joined 08:40 klaas-janstol joined
jnthn morning, #moarvm o/ 08:57
timotimo heyo :)
nwc10 jnthn++ # saviour of the universe
timotimo i still kinda wish our REPL wasn't based on such a ... hack
08:58 brrt joined
brrt moarning jnthn :-) 08:59
nwc10 www.youtube.com/watch?v=LfmrHTdXgK4 09:00
(not a rickroll. However, we don't have a bot to verify that. Which makes me wonder about having a bot that usually tells the truth, but sometimes hides a rickroll)
jnthn :P 09:01
nwc10 they all look so young
timotimo that is still an excellent song
what do you mean, "flash jnthn approaching?" 09:02
nwc10 I think of individual Queen songs, Killer Queen is still my favourite 09:03
09:22 brrt joined 10:23 FROGGS[mobile] joined
nwc10 before I forget, setting takes about 15% less time with spesh than without. 10:40
jnthn Yeah, that sounds similar to the numbers I've observed 10:42
Makes quite a difference.
timotimo yes, spesh is good. 10:43
jnthn Still plenty of room to make it better, though :) 10:44
timotimo of course
.o( set elimination )
jnthn
.oO( I just tossed set, and it felt so good... )
 10:45
timotimo just now i remembered how long i used to wait for the setting compilation to test if my newest Optimizer.nqp change worked properly 10:52
brrt :-) yay for spesh 10:59
brrt bbi3h
timotimo between then and now there were a whole lot of other changes, though. like the introduction of moarvm
11:12 FROGGS[mobile] joined 11:48 FROGGS[mobile] joined 12:26 klaas-janstol joined
timotimo jnthn: gist.github.com/timo/148021dfebabafccfa6a - got an idea why this happens? 12:30
(someone else pointed this out recently, but i've only checked it out now) 12:31
(i don't think it'll make a huge performance difference, but ... why are we doing this %) ) 12:33
jnthn Is that a full strace? 12:37
It looks like it's loading a lib over and over again rather than hitting a cached previous loading... At least, I thought we cached the pervious loading... 12:38
*previous
timotimo it's only a small part of the whole strace 12:40
jnthn was gonna say
timotimo is this MVM_dll_load? 12:41
can you just MVM_HASH_GET with an MVMString like that?
12:43 jnap joined
timotimo actually 12:44
it could very well be MVM_file_in_libpath
i bet it is. 12:46
this one doesn't do any caching.
so either we add a cache to MVM_file_in_libpath or we make the cache of dll_load depend on the not-full path 12:47
which would probably be a bad idea. 12:48
maybe we should bind each dll into the hash twice. once with the full path, once with just the filename
interesting. MVM_dll_free would require the user to pass the full path to the dll to free it 12:52
jnthn Can libpath be changed today after startup?
If it's immutable then caching on short name is safe.
timotimo it seems like we only ever set the libpath from commandline arguments 12:53
jnthn Right
So it's safe to cache on short name.
timotimo so should it only cache on short name or on both? 12:54
oh
d'oh
it *is* caching on short name
but it is trying to find the file in the libpath before even checking the cache
timotimo fixes
much better. 12:56
dalek arVM: 831e654 | (Timo Paulssen)++ | src/core/dll.c:
check dll cache before searching through libpath
 12:57
jnthn Any measurable startup time improvement?
timotimo don't think so 12:58
file_in_libpath was already rather tight
and stat likely has its own cache built in
internet says it's cached 12:59
jnthn aye 13:00
moritz ... on sane platforms :-)
jnthn Well, makes strace of our startup look better...
timotimo ;) 13:01
it'll improve the startup time if strace is attached
I/O to stdout/stderr is expensive, you know? :D
also, loading a library adds a permanent gc root, but freeing it does not ...
moritz well, syscalls also have a certain overhead
jnthn timotimo: I also notice mmap(NULL, 233472, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd4b9bf2000 13:04
Is that a bytecode loading? 13:05
timotimo dunno, it happens over and over and over in perl6-m -e 'say 1'
about 240 times 13:06
jnthn Always with read/write?
We do MVM_platform_map_file(fd, &handle, (size_t)size, 0) 13:07
the 0 there is meant to indicate "not writable"
timotimo 27 are PROT_READ only
10 are PROT_EXEC 13:08
2 of those with NULL as first argument
the others with pointers
jnthn Ah, ok
timotimo (it's a jit-moarvm)
jnthn 27 is about right for libraries loaded I uess
Yes, and rest will be JIT allocating executable memory
OK, seems fine
timotimo except MVM_JIT_DISABLE=1 doesn't change that 13:09
i'd like to resume work on the IPerl6 kernel thingie again ... that'll require me to build a new HLL::Compiler i think 13:29
with a different interactive() method
github.com/timo/iperl6kernel/blob/...el.nqp#L22 - this won't fly at all ... given the pir:: ops in there %) 13:30
tadzik :D 13:31
jnthn timotimo: One can subclass... :) 13:32
timotimo could i subclass it in perl6 code nowadays?
jnthn um
Ask FROGGS ;)
timotimo also, yeah, i meant subclass not "build from scratch" ;)
m: use NQP::HLL; 13:40
camelia rakudo-moar 35d714: OUTPUTĀ«===SORRY!===ā¤Could not find NQP::HLL in any of: /home/p6eval/rakudo-inst-2/languages/perl6/lib, /home/p6eval/rakudo-inst-2/languages/perl6ā¤Ā»
timotimo m: use NQPHLL;
camelia rakudo-moar 35d714: OUTPUTĀ«===SORRY!===ā¤Could not find NQPHLL in any of: /home/p6eval/rakudo-inst-2/languages/perl6/lib, /home/p6eval/rakudo-inst-2/languages/perl6ā¤Ā»
timotimo m: use HLL;
camelia rakudo-moar 35d714: OUTPUTĀ«===SORRY!===ā¤Could not find HLL in any of: /home/p6eval/rakudo-inst-2/languages/perl6/lib, /home/p6eval/rakudo-inst-2/languages/perl6ā¤Ā»
timotimo m: use HLL:from<NQP>;
camelia rakudo-moar 35d714: OUTPUTĀ«===SORRY!===ā¤While looking for 'HLL.moarvm': no such file or directoryā¤Ā»
timotimo m: use NQPHLL:from<NQP>;
camelia ( no output )
timotimo m: use NQPHLL:from<NQP>; class Foobar is HLL::Compiler; 13:41
camelia ( no output )
timotimo hmm
but i want Perl6::Compiler
timotimo hunts
oh
jnthn m: use Perl6::Compiler:from<NQP>; say 'ok' 13:42
camelia rakudo-moar 35d714: OUTPUTĀ«okā¤Ā»
jnthn m: use Perl6::Compiler:from<NQP>; class FooBar is Perl6::Compiler; say 'ok'
camelia rakudo-moar 35d714: OUTPUTĀ«okā¤Ā»
timotimo m: use Perl6::Compiler:from<NQP>; class MyCompiler is Perl6::Compiler; MyCompiler.new().usage() 13:43
camelia rakudo-moar 35d714: OUTPUTĀ« [switches] [--] [programfile] [arguments]ā¤ ā¤ With no arguments, enters a REPL. With a "[programfile]" or theā¤ "-e" option, compiles the given program and by default alsoā¤ executes the compiled code.ā¤ ā¤ -c ā€¦Ā»
timotimo this is good stuff.
jnthn m: use Perl6::Compiler:from<NQP>; class MyCompiler is Perl6::Compiler; MyCompiler.new().eval("say 'i accidentally the whole cake'") 13:44
camelia rakudo-moar 35d714: OUTPUTĀ«===SORRY!===ā¤Cannot find method 'parse'ā¤Ā»
timotimo being able to toss the nqp portion of IPerl6Kernel would be a good thing.
jnthn Aww
Guess it needs a bit more setup than that.
timotimo i may have to do the same thing as ... 13:45
github.com/rakudo/rakudo/blob/nom/...er.nqp#L14 13:46
anyway, AFK for a bit.
(brrt is bound to return soon :D )
jnthn
.oO( be right brrt )
14:36 zakharyas joined 14:51 brrt joined
brrt \o 14:56
jnthn o/
brrt how 's it :-) 14:58
i would like to bounce the following idea off against you
a): during jit-graph building, i'll be building a single array of labels, for basic blocks, osr points, inline start / ends, handlers, etc 14:59
jnthn inline start/ends are always aligned with basic block boundaries, fwiw. 15:00
brrt b): also during jit-graph buidling, i'll be building an array containing the indices of the basic block labels, another array for the osr points, another array for inline starts / ends, another for the deopt indices
jnthn You do need to be very careful over the fact that some annotations are inclusive bounds and others are exclusive. 15:01
brrt hmmm
which are inclusive?
jnthn But yes, it's sane overall
brrt good point of course
jnthn Well, start of exception handler for example
brrt uhuh
jnthn It means "this instruction is where it starts"
Same for inline 15:02
But end of inline, for example, is on the last inlined instruction
But clearly the body of that instruction (the code we generate for it) falls within the region.
brrt nods 15:03
jnthn Thus why my patch yesterday for deopt all makes a note saying "it's the next thingy that gives the boundary"
Anyway, provided you handle that, what you suggest seems sane.
brrt ok, good :-) i was afraid i was overgeneralising or something like that 15:05
but in fact some things seem to be simpler with it
jnthn Yeah, my patches in the JIT code yesterday were not aimed at being general, just getting me enough so I could write the patch in deopt.c and get that working. 15:09
brrt well, it showed the way quite effectively :-) 15:11
and, i've an awesome topic to blog about 15:12
15:27 klaas-janstol joined
jnthn decides he's done enough $dayjob for today :) 15:31
moritz too 15:37
jnthn Hm, I'm hungry too.
Guess I should eat before hacking... :)
brrt that is rarely a bad idea 15:40
although too large meals make hacking difficult as well
15:40 klaas-janstol joined
jnthn tends to not eat too many carbs when making food for himself, which helps :) 15:43
brrt i suppose so 15:44
:-)
eating & 15:45
[Coke] MVM_JIT_DONT_JIT_ME_BRO 16:13
jnthn heh, I can call the option that if you like :P 17:32
TimToady But if we use that option, we'll never make the top-50 jit list! 17:35
hmm, I guess it's supposed to be top 40... 17:38
dalek arVM: 2dd65b9 | jnthn++ | src/core/ext.h:
Some extra JIT-related flags for extops.

Put in master so we can add them to Rakudo's extops without having to make a branch there.		 17:41
17:47 colomon joined
TimToady The crowd started to chant: "Merge! Merge! Merge! Merge!" 17:50
timotimo Grand Theft Garbage Collector: 25 missions to steal from kindergartens, 1 to steal from an old folk's home 17:53
jnthn :P 17:54
I think after brrt++'s current work on extent lists for handlers etc. we'll be at a good place to merge.
dalek arVM/jit-extops: 831e654 | (Timo Paulssen)++ | src/core/dll.c:
check dll cache before searching through libpath
 18:08
arVM/jit-extops: 2dd65b9 | jnthn++ | src/core/ext.h:
Some extra JIT-related flags for extops.

Put in master so we can add them to Rakudo's extops without having to make a branch there.
arVM/jit-extops: 9fb0d5d | jnthn++ | src/core/ (2 files):
Merge branch 'master' into jit-extops
nwc10 timotimo: reminds me of "Grand Theft Tricycle", which was a game a friends son seemed to be playing. 18:10
[if he saw anything with wheels, he tried to take it to play with it] 18:11
timotimo %) 18:12
jnthn grmbl...segvs weren't much to do with jitting extops we coudln't
timotimo that sentence was challenging
jnthn So's this debugging :P 18:13
18:14 klaas-janstol joined 18:27 klaas-janstol joined 18:28 cognome joined
jnthn oh, duh duh duh 18:44
Seems it's a case of us now JITting frames we couldn't before and hitting another bug
And I can get I know what.
append_ins: <gethow>
Need to update that for lazy deserialization :) 18:45
timotimo aaaah :) 18:47
probably
jnthn Ooh, and I think I can fix it without having to pretend to know how to write x86 assembly... :P 18:48
timotimo sweet! 18:52
nwc10 cd - 18:53
jnthn: origin/jit-extops has SEGVs in the spectest, but I guess you know that already 18:54
seems to be just SEGVs, not ASAN barfage
jnthn nwc10: Yes, that's exactly what I was talking about above
yeah, null pointer derefs
nwc10 OK. ASAN build gets as far as the spectest, so all the earlier stuff is clean
jnthn OK, good, then you're seeing what I am
e 18:55
19:09 brrt joined
brrt \o 19:12
gethow is called before, i'm pretty sure? but perhaps not in a lazily-loaded-context
also
this thing is getting out of my hands :-)
(and i like that, by the way) 19:13
dalek arVM/jit-extops: 045252c | jnthn++ | src/ (4 files):
Account for no_jit and invokish extop flags in JIT
arVM/jit-extops: bccf73c | jnthn++ | src/ (3 files):
Bring gethow JIT compilation in line with interp.

Now it needs a function call, as we may lazily deserialize the meta-object.
timotimo heyo brrt 19:14
jnthn brrt: Yeah, none of the times we needed to do the lazy deserialize musta occurred in JITted code before
brrt: Then the extops unblocked something that did a p6bool and a gethow
timotimo horton heard a how? 19:15
brrt p6bool? 19:16
oh, p6bool is an extop?
jnthn aye 19:17
brrt do we often pass STABLE's of objects? 19:18
jnthn No
brrt because i can make a jit call arg mode for that :-)
nwc10 NQP tests pass. Now Rakudo
brrt ok
[Coke] reads "heyo brrt" in the voice of ernie from sesame street. 19:20
nwc10 jnthn: all pass apart from t/spec/S26-documentation/10-doc-cli.rakudo.moar t/spec/S32-io/IO-Socket-Async.rakudo.moar t/spec/S32-str/encode.rakudo.moar 19:32
t/spec/S32-io/IO-Socket-Async.rakudo.moar is strange. It's planning 6 tests but only running 5 19:33
t/spec/S26-documentation/10-doc-cli.rakudo.moar is passing at the commandline
anyway, win 19:34
apart from the usual sin
timotimo sweet 19:44
jnthn OK, I'll merge it into moar-jit 20:01
dalek MoarVM/moar-jit: 16bde9a | jnthn++ | src/jit/graph.c: 20:02
MoarVM/moar-jit: An initial sketch of JITting extops calls.
MoarVM/moar-jit:
MoarVM/moar-jit: Doesn't yet fully work, most probably because it JITs some that are
MoarVM/moar-jit: invokey without handling that, or that mess with interpreter state
jnthn lolextermianted 20:03
20:03 dalek joined
brrt poor dalek 20:05
(:-o it seems jnthn is racing ahead of me in terms of JIT commits this week)
jnthn: the deopt all idx is always on the invoke op, right? wouldn't make much sense on arg_* ops 20:09
jnthn Correct
brrt ok, very well 20:17
wait, something just broke in my idea 20:24
... darn it
jnthn oh? :( 20:25
brrt i can't just combine the deopt idx into the label, because: what happens if the label assigned to the deopt_all_idx is the same as the label assigned to the inline frame end 20:26
jnthn A label may be involved in multiple extend lists, yes 20:27
For example, multiple handlers can be on one label too 20:28
er, or start on one instruction
brrt so putting the idx on the label isn't going to work
jnthn Oh, I'd somehow got the impression you were going to take the deopt idx out of the label and instead keep some data structures on the jgb
brrt that was still true 20:29
except that those data structures would be simple arrays
now they won't be :-)
jnthn You know how many inlines there are, though, and how many handlers
20:30 jnap joined
jnthn So you could just pre-allocate those 20:30
And fill them in with label name by handler index found in the annotation.
Or inline index for inlines.
Then after the code is generated, resolve those labels as you build the real extent lists. 20:31
brrt nods
that's... no problem. that's just the correct solution
:-)
hmm.. i do figure i can make a jit deopt point object 20:56
jnthn
.oO( But what will it object to? )
 21:05
brrt considers a bad deconstructivism joke, but can't figure one out 21:08
cognome Stage parse : moar(96372,0x7fff70ccc310) malloc: *** error for object 0x7fd11014c1f0: pointer being freed was not allocated
on a fresh rakudo with moarvm 21:09
on macos
jnthn :/ 21:11
Weird; we've been getting clean ASAN reports of late, I thought...
cognome ASAN? 21:12
jnthn Address sanatizer
A tool for detecting errors like this
lee_ no problems building on OS X here 21:13
brrt no backtrace then, likely? 21:14
if you have os x you should checkout the moar-jit branch, it has support for setting up ASAN using a configure.pl flag
which - i think - hasn't been backported to main yet
(the configure.pl flag is incidently --asan :-)) 21:15
it will give you a backtrace, but also a much slower build
cognome ok, I try that
brrt probably best not to enable jit, since main doesn't have that either
cognome perl Configure.pl --asan --gen-nqp --gen-moar --backends=moar ?
brrt hmm.. no that's from rakudo 21:16
you'll need to configure moar with the --asan flag, not rakudo
cognome and how do you do that?
brrt ehm... easiest way i think is checking out moar by hand
or
going to the directory where moar was checked out, and reconfigure with the --asan flag 21:17
but, as i said, you'll have to checkout moar-jit for that to work
timotimo nah
--moar-opts=--asan
and --gen-moar=moar-jit
see, all the magic is there
brrt oh 21:18
cognome I don't remember that from the doc
brrt what timotimo++ said :-)
i have never built rakudo that way
timotimo that's because i didn't put it in the docs yet =\
cognome yea timotimo++ brrt++ jnthn++ 21:19
brrt :-)
labels are quite a piece of work, so much is clear 21:21
timotimo jnthn: what would the roadmap look like to teach NativeCall about Blob?
brrt jnthn: are there any restrictions on the locations of osr deopt idxs?
cognome is there any win using the jit branch. I seem to understand that optimizations triggers very early to help finding bug. Is there any win despite that? 21:22
brrt no, not yet 21:23
because you haven't enabled jit yet :-)
i'm going to make a totally unscientific comparison of making moar with and without jit enabled 21:24
ehm, building rakudo, that is 21:25
cognome hum, I restarted compiling rakudo from scratch using "standard optons" and it worked.
brrt 60s for a rakudo-without--jit, of which 27.972s in stage parse 21:26
cognome not sure if it is a false alert or an heisenbug.
brrt hmmm
and 28.136s with jit
so no win.. at all :-) 21:27
jnthn brrt: No, though if you want to argue for one, we can make it happen.
brrt no, no need to argue :-)
just wanted to know if the current check is optimal 21:28
what would an array of labeled objects be called?
labeleds?
jnthn That'll do :)
brrt :-)
brrt is not so happy about building rakudo being slower with than without JIT) 21:29
i know, artificial comparision, but still 21:30
jnthn Well, the i-cache in a CPU is only so big 21:31
When we're interpreting we can probably keep the interpreter and other hot things largely inside of it
When we JIT, the JITted code creates competition for the icache 21:32
timotimo jnthn: don't we mix in stuff *constantly* during stage parse?
jnthn But there's lots we bail on, meaning we need the interpreter a lot too
timotimo isn't that how we add operators to the grammar for example?
jnthn timotimo: We better not be mutating the grammar during the parse...otherwise we have to pay the cost of loading that mutation in CORE.setting every single time. 21:33
That's why I insist we register everything in the grammar.
(Like th empty set term the other day)
timotimo well, there are things we can't do at the beginning of the setting that we can do closer to the end
oh
that's a good point
okay, so only custom operators would ever do that, and we don't have those in the setting 21:34
jnthn Yes, CORE.setting is not very custom. It's CORE. :)
brrt fair enough... i'm interested in seeing how it does after benchmarks + handlers 21:35
eh after extops + handlers
timotimo mhh 21:36
brrt jnhtn: in what contexts are deopt_inline annotations actually used? 22:16
jnthn They could be deopt_one or deopt_all 22:20
brrt hmm... this may be my half-sleeping self, but i don't understand that answer i'm afraind 22:24
afraid
jnthn When we inline code, we concatenate the deopt tables 22:25
It doesn't at present make any effort to differentiate inlined deopt all vs deopt one 22:26
Because so far it's not mattered
There's one deopt table for all/one
brrt uhuh 22:27
jnthn The only reason we differentiate all and one is because sp_log might lead to a guard, which wants the deopt_one annotations moved to the guard.
Whereas the deopt_all must stay on the invoke no matter what.
brrt ok, i get that
:-)
but deopt_inline?
jnthn When we inline, we take the spesh'd bytecode of the inlinee and re-build a spesh graph out of it. 22:28
And when we hit a deopt, we note it with deopt_inline
We kinda lost the information about what kind of deopt it was after code-gen.
And we don't need to do anything more than update the correct offset in the table. 22:29
So a deopt inline was either a deopt_one or a deopt_all in the inlinee at the time it was code-gen'd.
Until now, this information loss hadn't shown itself. :) 22:30
I think for your purposes, I'd assume they're a deopt_all; since they can only occur on invoke sequences anyway, your chance of false positives is low, and they are also harmless.
brrt nods 22:31
anyway, on guards, i act as if they're deopt_one
jnthn (Aside: it may be that graph.c in spesh neglects to put a basic block boundary after an sp_fastinvoke. I can't remember. It may get it right.) 22:32
Yes, on guards they will be.
brrt it neglects it, but it doesn't matter fo the jit
for
jnthn Ah, OK
We may want to fix it anyway.
As otherwise you can't rely on a BB boundary after that kind of invoke
brrt no, and current code does in fact rely on that, but my WIP code is more flexible about that 22:33
'that' being relying on a bb boundary
jnthn ok 22:34
brrt (this is going to be one huge commit i'm afraid)
timotimo whatever, i'm just looking forward to seeing the awesome stuff at the end :3 22:41
brrt :-) 22:42
i'm going to sleep
i can push WIP to a special branch if you wish 22:43
jnthn 'night, brrt++
brrt but it won't compile
jnthn I'm going to sleep soon too
And have a meeting in the morning
brrt 'night jnthn++ and timotimo++ as well
TimToady o/ one and all
jnthn So no need for it :)
brrt :-)
22:43 brrt left
timotimo oke 22:43

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!