Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-08-07

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:07 jnap joined #moarvm
01:25 lue joined #moarvm
01:36 FROGGS_ joined #moarvm
01:49 cognome joined #moarvm
03:14 ventica joined #moarvm
04:12 lue joined #moarvm
04:30 retupmoc1 joined #moarvm
04:30 hatsefla1s joined #moarvm
04:35 zakharyas joined #moarvm
04:36 betterworld joined #moarvm
04:42 ingy joined #moarvm
04:42 egrep joined #moarvm
04:44 nwc10 jnthn: aafb3aaba4a81fce81ce976af52825158bb33a7a PASS
04:48 ingy joined #moarvm
04:53 ventica joined #moarvm
04:55 ventica2 joined #moarvm
05:16 egrep left #moarvm
05:21 brrt joined #moarvm
05:42 brrt jnthn++ for his My First Jit Patch
07:04 _sri joined #moarvm
07:09 Ven joined #moarvm
07:20 sergot hi o/
07:21 brrt hi sergot
07:37 woolfy left #moarvm
07:52 brrt label management is complex in general, it seems
07:57 brrt but i think i can generalise it and it'll be BETTER
08:01 timotimo brrt: sounds good :)
08:02 brrt i should elaborate by the way
08:02 brrt (by the way, i can't stress enough how much jnthn++ saved me yesterday)
08:02 brrt basically, we now assign labels to basic blocks, and we assign magic special labels to osr entry opts
08:03 brrt but from the point of view of the assembler, all these labels are of the same type (i.e., dynamic labels)
08:03 brrt i can have pretty much as many of these as i like
08:03 brrt my current setup has the osr labels appended to the 'regular' bb labels
08:04 brrt 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:05 brrt 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:08 brrt 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:13 brrt we can also remove the special osr label code
08:13 brrt because it will not be special anymore
08:14 timotimo :)
08:39 FROGGS[mobile] joined #moarvm
08:40 klaas-janstol joined #moarvm
08:57 jnthn morning, #moarvm o/
08:57 timotimo heyo :)
08:57 nwc10 jnthn++ # saviour of the universe
08:57 timotimo i still kinda wish our REPL wasn't based on such a ... hack
08:58 brrt joined #moarvm
08:59 brrt moarning jnthn :-)
09:00 nwc10 https://www.youtube.com/watch?v=LfmrHTdXgK4
09:00 nwc10 (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)
09:01 jnthn :P
09:01 nwc10 they all look so young
09:01 timotimo that is still an excellent song
09:02 timotimo what do you mean, "flash jnthn approaching?"
09:03 nwc10 I think of individual Queen songs, Killer Queen is still my favourite
09:22 brrt joined #moarvm
10:23 FROGGS[mobile] joined #moarvm
10:40 nwc10 before I forget, setting takes about 15% less time with spesh than without.
10:42 jnthn Yeah, that sounds similar to the numbers I've observed
10:42 jnthn Makes quite a difference.
10:43 timotimo yes, spesh is good.
10:44 jnthn Still plenty of room to make it better, though :)
10:44 timotimo of course
10:44 timotimo .o( set elimination )
10:45 jnthn .oO( I just tossed set, and it felt so good... )
10:52 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:59 brrt :-) yay for spesh
10:59 * brrt bbi3h
10:59 timotimo between then and now there were a whole lot of other changes, though. like the introduction of moarvm
11:12 FROGGS[mobile] joined #moarvm
11:48 FROGGS[mobile] joined #moarvm
12:26 klaas-janstol joined #moarvm
12:30 timotimo jnthn: https://gist.github.com/timo/148021dfebabafccfa6a - got an idea why this happens?
12:31 timotimo (someone else pointed this out recently, but i've only checked it out now)
12:33 timotimo (i don't think it'll make a huge performance difference, but ... why are we doing this %) )
12:37 jnthn Is that a full strace?
12:38 jnthn 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 jnthn *previous
12:40 timotimo it's only a small part of the whole strace
12:40 jnthn was gonna say
12:41 timotimo is this MVM_dll_load?
12:41 timotimo can you just MVM_HASH_GET with an MVMString like that?
12:43 jnap joined #moarvm
12:44 timotimo actually
12:44 timotimo it could very well be MVM_file_in_libpath
12:46 timotimo i bet it is.
12:46 timotimo this one doesn't do any caching.
12:47 timotimo 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:48 timotimo which would probably be a bad idea.
12:48 timotimo maybe we should bind each dll into the hash twice. once with the full path, once with just the filename
12:52 timotimo 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?
12:52 jnthn If it's immutable then caching on short name is safe.
12:53 timotimo it seems like we only ever set the libpath from commandline arguments
12:53 jnthn Right
12:53 jnthn So it's safe to cache on short name.
12:54 timotimo so should it only cache on short name or on both?
12:54 timotimo oh
12:54 timotimo d'oh
12:54 timotimo it *is* caching on short name
12:54 timotimo but it is trying to find the file in the libpath before even checking the cache
12:54 * timotimo fixes
12:56 timotimo much better.
12:57 dalek MoarVM: 831e654 | (Timo Paulssen)++ | src/core/dll.c:
12:57 dalek MoarVM: check dll cache before searching through libpath
12:57 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/831e654d15
12:57 jnthn Any measurable startup time improvement?
12:58 timotimo don't think so
12:58 timotimo file_in_libpath was already rather tight
12:58 timotimo and stat likely has its own cache built in
12:59 timotimo internet says it's cached
13:00 jnthn aye
13:00 moritz ... on sane platforms :-)
13:00 jnthn Well, makes strace of our startup look better...
13:01 timotimo ;)
13:01 timotimo it'll improve the startup time if strace is attached
13:01 timotimo I/O to stdout/stderr is expensive, you know? :D
13:01 timotimo also, loading a library adds a permanent gc root, but freeing it does not ...
13:01 moritz well, syscalls also have a certain overhead
13:04 jnthn timotimo: I also notice mmap(NULL, 233472, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd4b9bf2000
13:05 jnthn Is that a bytecode loading?
13:05 timotimo dunno, it happens over and over and over in perl6-m -e 'say 1'
13:06 timotimo about 240 times
13:06 jnthn Always with read/write?
13:07 jnthn We do MVM_platform_map_file(fd, &handle, (size_t)size, 0)
13:07 jnthn the 0 there is meant to indicate "not writable"
13:07 timotimo 27 are PROT_READ only
13:08 timotimo 10 are PROT_EXEC
13:08 timotimo 2 of those with NULL as first argument
13:08 timotimo the others with pointers
13:08 jnthn Ah, ok
13:08 timotimo (it's a jit-moarvm)
13:08 jnthn 27 is about right for libraries loaded I uess
13:08 jnthn Yes, and rest will be JIT allocating executable memory
13:08 jnthn OK, seems fine
13:09 timotimo except MVM_JIT_DISABLE=1 doesn't change that
13:29 timotimo 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 timotimo with a different interactive() method
13:30 timotimo https://github.com/timo/iperl6kernel/blob/master/bin/iperl6kernel.nqp#L22 - this won't fly at all ... given the pir:: ops in there %)
13:31 tadzik :D
13:32 jnthn timotimo: One can subclass... :)
13:32 timotimo could i subclass it in perl6 code nowadays?
13:32 jnthn um
13:32 jnthn Ask FROGGS ;)
13:32 timotimo also, yeah, i meant subclass not "build from scratch" ;)
13:40 timotimo 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␤»
13:40 timotimo m: use NQPHLL;
13:40 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␤»
13:40 timotimo m: use HLL;
13:40 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␤»
13:40 timotimo m: use HLL:from<NQP>;
13:40 camelia rakudo-moar 35d714: OUTPUT«===SORRY!===␤While looking for 'HLL.moarvm': no such file or directory␤»
13:40 timotimo m: use NQPHLL:from<NQP>;
13:40 camelia rakudo-moar 35d714: ( no output )
13:41 timotimo m: use NQPHLL:from<NQP>; class Foobar is HLL::Compiler;
13:41 camelia rakudo-moar 35d714: ( no output )
13:41 timotimo hmm
13:41 timotimo but i want Perl6::Compiler
13:41 * timotimo hunts
13:41 timotimo oh
13:42 jnthn m: use Perl6::Compiler:from<NQP>; say 'ok'
13:42 camelia rakudo-moar 35d714: OUTPUT«ok␤»
13:42 jnthn m: use Perl6::Compiler:from<NQP>; class FooBar is Perl6::Compiler; say 'ok'
13:42 camelia rakudo-moar 35d714: OUTPUT«ok␤»
13:43 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         …»
13:43 timotimo this is good stuff.
13:44 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'␤»
13:44 timotimo being able to toss the nqp portion of IPerl6Kernel would be a good thing.
13:44 jnthn Aww
13:44 jnthn Guess it needs a bit more setup than that.
13:45 timotimo i may have to do the same thing as ...
13:46 timotimo https://github.com/rakudo/rakudo/blob/nom/src/Perl6/Compiler.nqp#L14
13:46 timotimo anyway, AFK for a bit.
13:46 timotimo (brrt is bound to return soon :D )
13:46 jnthn .oO( be right brrt )
14:36 zakharyas joined #moarvm
14:51 brrt joined #moarvm
14:56 brrt \o
14:56 jnthn o/
14:58 brrt how 's it :-)
14:58 brrt i would like to bounce the following idea off against you
14:59 brrt a): during jit-graph building, i'll be building a single array of labels, for basic blocks, osr points, inline start / ends, handlers, etc
15:00 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
15:01 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
15:01 brrt which are inclusive?
15:01 jnthn But yes, it's sane overall
15:01 brrt good point of course
15:01 jnthn Well, start of exception handler for example
15:01 brrt uhuh
15:01 jnthn It means "this instruction is where it starts"
15:02 jnthn Same for inline
15:02 jnthn But end of inline, for example, is on the last inlined instruction
15:02 jnthn But clearly the body of that instruction (the code we generate for it) falls within the region.
15:03 * 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"
15:03 jnthn Anyway, provided you handle that, what you suggest seems sane.
15:05 brrt ok, good :-) i was afraid i was overgeneralising or something like that
15:05 brrt but in fact some things seem to be simpler with it
15:09 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:11 brrt well, it showed the way quite effectively :-)
15:12 brrt and, i've an awesome topic to blog about
15:27 klaas-janstol joined #moarvm
15:31 * jnthn decides he's done enough $dayjob for today :)
15:37 * moritz too
15:37 jnthn Hm, I'm hungry too.
15:37 jnthn Guess I should eat before hacking... :)
15:40 brrt that is rarely a bad idea
15:40 brrt although too large meals make hacking difficult as well
15:40 klaas-janstol joined #moarvm
15:43 * jnthn tends to not eat too many carbs when making food for himself, which helps :)
15:44 brrt i suppose so
15:44 brrt :-)
15:45 brrt eating &
16:13 [Coke] MVM_JIT_DONT_JIT_ME_BRO
17:32 jnthn heh, I can call the option that if you like :P
17:35 TimToady But if we use that option, we'll never make the top-50 jit list!
17:38 TimToady hmm, I guess it's supposed to be top 40...
17:41 dalek MoarVM: 2dd65b9 | jnthn++ | src/core/ext.h:
17:41 dalek MoarVM: Some extra JIT-related flags for extops.
17:41 dalek MoarVM:
17:41 dalek MoarVM: Put in master so we can add them to Rakudo's extops without having to
17:41 dalek MoarVM: make a branch there.
17:41 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2dd65b9c6c
17:47 colomon joined #moarvm
17:50 TimToady The crowd started to chant: "Merge! Merge! Merge! Merge!"
17:53 timotimo Grand Theft Garbage Collector: 25 missions to steal from kindergartens, 1 to steal from an old folk's home
17:54 jnthn :P
17:54 jnthn I think after brrt++'s current work on extent lists for handlers etc. we'll be at a good place to merge.
18:08 dalek MoarVM/jit-extops: 831e654 | (Timo Paulssen)++ | src/core/dll.c:
18:08 dalek MoarVM/jit-extops: check dll cache before searching through libpath
18:08 dalek MoarVM/jit-extops: review: https://github.com/MoarVM/MoarVM/commit/831e654d15
18:08 dalek MoarVM/jit-extops: 2dd65b9 | jnthn++ | src/core/ext.h:
18:08 dalek MoarVM/jit-extops: Some extra JIT-related flags for extops.
18:08 dalek MoarVM/jit-extops:
18:08 dalek MoarVM/jit-extops: Put in master so we can add them to Rakudo's extops without having to
18:08 dalek MoarVM/jit-extops: make a branch there.
18:08 dalek MoarVM/jit-extops: review: https://github.com/MoarVM/MoarVM/commit/2dd65b9c6c
18:08 dalek MoarVM/jit-extops: 9fb0d5d | jnthn++ | src/core/ (2 files):
18:08 dalek MoarVM/jit-extops: Merge branch 'master' into jit-extops
18:08 dalek MoarVM/jit-extops: review: https://github.com/MoarVM/MoarVM/commit/9fb0d5dd8e
18:10 nwc10 timotimo: reminds me of "Grand Theft Tricycle", which was a game a friends son seemed to be playing.
18:11 nwc10 [if he saw anything with wheels, he tried to take it to play with it]
18:12 timotimo %)
18:12 jnthn grmbl...segvs weren't much to do with jitting extops we coudln't
18:12 timotimo that sentence was challenging
18:13 jnthn So's this debugging :P
18:14 klaas-janstol joined #moarvm
18:27 klaas-janstol joined #moarvm
18:28 cognome joined #moarvm
18:44 jnthn oh, duh duh duh
18:44 jnthn Seems it's a case of us now JITting frames we couldn't before and hitting another bug
18:44 jnthn And I can get I know what.
18:44 jnthn append_ins: <gethow>
18:45 jnthn Need to update that for lazy deserialization :)
18:47 timotimo aaaah :)
18:47 timotimo probably
18:48 jnthn Ooh, and I think I can fix it without having to pretend to know how to write x86 assembly... :P
18:52 timotimo sweet!
18:53 nwc10 cd -
18:54 nwc10 jnthn: origin/jit-extops has SEGVs in the spectest, but I guess you know that already
18:54 nwc10 seems to be just SEGVs, not ASAN barfage
18:54 jnthn nwc10: Yes, that's exactly what I was talking about above
18:54 jnthn yeah, null pointer derefs
18:54 nwc10 OK. ASAN build gets as far as the spectest, so all the earlier stuff is clean
18:54 jnthn OK, good, then you're seeing what I am
18:55 jnthn e
19:09 brrt joined #moarvm
19:12 brrt \o
19:12 brrt gethow is called before, i'm pretty sure? but perhaps not in a lazily-loaded-context
19:12 brrt also
19:12 brrt this thing is getting out of my hands :-)
19:13 brrt (and i like that, by the way)
19:13 dalek MoarVM/jit-extops: 045252c | jnthn++ | src/ (4 files):
19:13 dalek MoarVM/jit-extops: Account for no_jit and invokish extop flags in JIT
19:13 dalek MoarVM/jit-extops: review: https://github.com/MoarVM/MoarVM/commit/045252ceed
19:13 dalek MoarVM/jit-extops: bccf73c | jnthn++ | src/ (3 files):
19:13 dalek MoarVM/jit-extops: Bring gethow JIT compilation in line with interp.
19:13 dalek MoarVM/jit-extops:
19:13 dalek MoarVM/jit-extops: Now it needs a function call, as we may lazily deserialize the
19:13 dalek MoarVM/jit-extops: meta-object.
19:13 dalek MoarVM/jit-extops: review: https://github.com/MoarVM/MoarVM/commit/bccf73c36d
19:14 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
19:14 jnthn brrt: Then the extops unblocked something that did a p6bool and a gethow
19:15 timotimo horton heard a how?
19:16 brrt p6bool?
19:16 brrt oh, p6bool is an extop?
19:17 jnthn aye
19:18 brrt do we often pass STABLE's of objects?
19:18 jnthn No
19:18 brrt because i can make a jit call arg mode for that :-)
19:18 nwc10 NQP tests pass. Now Rakudo
19:18 brrt ok
19:20 * [Coke] reads "heyo brrt" in the voice of ernie from sesame street.
19:32 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:33 nwc10 t/spec/S32-io/IO-Socket-Async.rakudo.moar is strange. It's planning 6 tests but only running 5
19:33 nwc10 t/spec/S26-documentation/10-doc-cli.rakudo.moar is passing at the commandline
19:34 nwc10 anyway, win
19:34 nwc10 apart from the usual sin
19:44 timotimo sweet
20:01 jnthn OK, I'll merge it into moar-jit
20:02 dalek MoarVM/moar-jit: 16bde9a | jnthn++ | src/jit/graph.c:
20:02 dalek MoarVM/moar-jit: An initial sketch of JITting extops calls.
20:02 dalek MoarVM/moar-jit:
20:02 dalek MoarVM/moar-jit: Doesn't yet fully work, most probably because it JITs some that are
20:02 dalek MoarVM/moar-jit: invokey without handling that, or that mess with interpreter state
20:03 jnthn lolextermianted
20:03 dalek joined #moarvm
20:05 brrt poor dalek
20:05 brrt (:-o it seems jnthn is racing ahead of me in terms of JIT commits this week)
20:09 brrt jnthn: the deopt all idx is always on the invoke op, right? wouldn't make much sense on arg_* ops
20:09 jnthn Correct
20:17 brrt ok, very well
20:24 brrt wait, something just broke in my idea
20:24 brrt ... darn it
20:25 jnthn oh? :(
20:26 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:27 jnthn A label may be involved in multiple extend lists, yes
20:28 jnthn For example, multiple handlers can be on one label too
20:28 jnthn er, or start on one instruction
20:28 brrt so putting the idx on the label isn't going to work
20:28 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
20:29 brrt that was still true
20:29 brrt except that those data structures would be simple arrays
20:29 brrt now they won't be :-)
20:29 jnthn You know how many inlines there are, though, and how many handlers
20:30 jnap joined #moarvm
20:30 jnthn So you could just pre-allocate those
20:30 jnthn And fill them in with label name by handler index found in the annotation.
20:30 jnthn Or inline index for inlines.
20:31 jnthn Then after the code is generated, resolve those labels as you build the real extent lists.
20:31 * brrt nods
20:31 brrt that's... no problem. that's just the correct solution
20:31 brrt :-)
20:56 brrt hmm.. i do figure i can make a jit deopt point object
21:05 jnthn .oO( But what will it object to? )
21:08 * 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
21:09 cognome on a fresh rakudo with moarvm
21:09 cognome on macos
21:11 jnthn :/
21:11 jnthn Weird; we've been getting clean ASAN reports of late, I thought...
21:12 cognome ASAN?
21:12 jnthn Address sanatizer
21:12 jnthn A tool for detecting errors like this
21:13 lee_ no problems building on OS X here
21:14 brrt no backtrace then, likely?
21:14 brrt if you have os x you should checkout the moar-jit branch, it has support for setting up ASAN using a configure.pl flag
21:14 brrt which - i think - hasn't been backported to main yet
21:15 brrt (the configure.pl flag is incidently --asan :-))
21:15 brrt it will give you a backtrace, but also a much slower build
21:15 cognome ok, I try that
21:15 brrt probably best not to enable jit, since main doesn't have that either
21:15 cognome perl Configure.pl --asan --gen-nqp --gen-moar --backends=moar ?
21:16 brrt hmm.. no that's from rakudo
21:16 brrt you'll need to configure moar with the --asan flag, not rakudo
21:16 cognome and how do you do that?
21:16 brrt ehm... easiest way i think is checking out moar by hand
21:16 brrt or
21:17 brrt going to the directory where moar was checked out, and reconfigure with the --asan flag
21:17 brrt but, as i said, you'll have to checkout moar-jit for that to work
21:17 timotimo nah
21:17 timotimo --moar-opts=--asan
21:17 timotimo and --gen-moar=moar-jit
21:17 timotimo see, all the magic is there
21:18 brrt oh
21:18 cognome I don't remember that from the doc
21:18 brrt what timotimo++ said :-)
21:18 brrt i have never built rakudo that way
21:18 timotimo that's because i didn't put it in the docs yet =\
21:19 cognome yea timotimo++ brrt++ jnthn++
21:19 brrt :-)
21:21 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?
21:21 brrt jnthn: are there any restrictions on the locations of osr deopt idxs?
21:22 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:23 brrt no, not yet
21:23 brrt because you haven't enabled jit yet :-)
21:24 brrt i'm going to make a totally unscientific comparison of making moar with and without jit enabled
21:25 brrt ehm, building rakudo, that is
21:25 cognome hum, I restarted compiling rakudo from scratch using "standard optons" and it worked.
21:26 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.
21:26 brrt hmmm
21:26 brrt and 28.136s with jit
21:27 brrt so no win.. at all :-)
21:27 jnthn brrt: No, though if you want to argue for one, we can make it happen.
21:27 brrt no, no need to argue :-)
21:28 brrt just wanted to know if the current check is optimal
21:28 brrt what would an array of labeled objects be called?
21:28 brrt labeleds?
21:28 jnthn That'll do :)
21:28 brrt :-)
21:29 * brrt is not so happy about building rakudo being slower with than without JIT)
21:30 brrt i know, artificial comparision, but still
21:31 jnthn Well, the i-cache in a CPU is only so big
21:31 jnthn When we're interpreting we can probably keep the interpreter and other hot things largely inside of it
21:32 jnthn 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?
21:32 jnthn But there's lots we bail on, meaning we need the interpreter a lot too
21:32 timotimo isn't that how we add operators to the grammar for example?
21:33 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 jnthn That's why I insist we register everything in the grammar.
21:33 jnthn (Like th empty set term the other day)
21:33 timotimo well, there are things we can't do at the beginning of the setting that we can do closer to the end
21:33 timotimo oh
21:33 timotimo that's a good point
21:34 timotimo 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. :)
21:35 brrt fair enough... i'm interested in seeing how it does after benchmarks + handlers
21:35 brrt eh after extops + handlers
21:36 timotimo mhh
22:16 brrt jnhtn: in what contexts are deopt_inline annotations actually used?
22:20 jnthn They could be deopt_one or deopt_all
22:24 brrt hmm... this may be my half-sleeping self, but i don't understand that answer i'm afraind
22:24 brrt afraid
22:25 jnthn When we inline code, we concatenate the deopt tables
22:26 jnthn It doesn't at present make any effort to differentiate inlined deopt all vs deopt one
22:26 jnthn Because so far it's not mattered
22:26 jnthn There's one deopt table for all/one
22:27 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.
22:27 jnthn Whereas the deopt_all must stay on the invoke no matter what.
22:27 brrt ok, i get that
22:27 brrt :-)
22:27 brrt but deopt_inline?
22:28 jnthn When we inline, we take the spesh'd bytecode of the inlinee and re-build a spesh graph out of it.
22:28 jnthn And when we hit a deopt, we note it with deopt_inline
22:28 jnthn We kinda lost the information about what kind of deopt it was after code-gen.
22:29 jnthn And we don't need to do anything more than update the correct offset in the table.
22:29 jnthn So a deopt inline was either a deopt_one or a deopt_all in the inlinee at the time it was code-gen'd.
22:30 jnthn Until now, this information loss hadn't shown itself. :)
22:30 jnthn 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.
22:31 * brrt nods
22:31 brrt anyway, on guards, i act as if they're deopt_one
22:32 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 jnthn Yes, on guards they will be.
22:32 brrt it neglects it, but it doesn't matter fo the jit
22:32 brrt for
22:32 jnthn Ah, OK
22:32 jnthn We may want to fix it anyway.
22:32 jnthn As otherwise you can't rely on a BB boundary after that kind of invoke
22:33 brrt no, and current code does in fact rely on that, but my WIP code is more flexible about that
22:33 brrt 'that' being relying on a bb boundary
22:34 jnthn ok
22:34 brrt (this is going to be one huge commit i'm afraid)
22:41 timotimo whatever, i'm just looking forward to seeing the awesome stuff at the end :3
22:42 brrt :-)
22:42 brrt i'm going to sleep
22:43 brrt i can push WIP to a special branch if you wish
22:43 jnthn 'night, brrt++
22:43 brrt but it won't compile
22:43 jnthn I'm going to sleep soon too
22:43 jnthn And have a meeting in the morning
22:43 brrt 'night jnthn++ and timotimo++ as well
22:43 TimToady o/ one and all
22:43 jnthn So no need for it :)
22:43 brrt :-)
22:43 brrt left #moarvm
22:43 timotimo oke

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary