Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-08-01

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

All times shown according to UTC.

Time Nick Message
00:02 raiph joined #moarvm
00:12 dalek MoarVM: 4538f61 | jnthn++ | src/ (3 files):
00:12 dalek MoarVM: Cache dynlex lookups.
00:12 dalek MoarVM:
00:12 dalek MoarVM: As suggested by TimToady++, we stash them within frames, so we get
00:12 dalek MoarVM: lifetime management for free (including if continuations happen). We
00:12 dalek MoarVM: poke it a few frames down the stack at various intervals, to try and
00:12 dalek MoarVM: maximize the benefit. Can likely tune this a bit more yet.
00:12 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4538f61a66
00:14 timotimo nice :)
00:15 jnthn Need to lose another 1.48s before I can say I can build Rakudo in 70s. :)
00:16 timotimo how much is that worth?
00:16 timotimo er.
00:17 timotimo how much did your last commit improve build times?
00:17 avuserow joined #moarvm
00:19 jnthn Was about another second off the Rakudo build.
00:19 jnthn So, at least a %
00:19 timotimo sweet!
00:20 timotimo you said you timed it at about 1.8% recently; so maybe you halved the time spent in dynvar lookups? :)
00:21 jnthn Yeah; I'll need to do a C level profile again at some point.
00:22 jnthn Wowza. Attempting to optimize junctions creates 103966 closures when compiling CORE.setting...
00:22 timotimo attempting?
00:22 jnthn Well, we may succeed
00:22 timotimo how did i do that :(
00:22 timotimo too many non-inlined blocks?
00:24 jnthn non-inlinable
00:25 jnthn 3 nested subs
00:25 jnthn The optimizer (and I'm guilty too) has some very large methods in it.
00:25 timotimo ah, those nested subs could be un-nested and just take more arguments
00:25 timotimo that would help, right?
00:25 jnthn Which aren't too maintainer friendly, but aren't exactly spesh-friendly or optimizer friendly either
00:25 jnthn Well, trying an easier refactor that's probably as effective.
00:26 timotimo OK
00:27 jnthn Basically, pull the transform into a separate method from the analysis.
00:29 jnthn Yes, that helps a lot.
00:29 jnthn Though it's not the biggest source of issues, just the most stand-out one
00:33 timotimo how do you measure what part of the process generates how many closures?
00:35 jnthn Patch to takeclosure in frame.c that just prints out the outer frame name.
00:37 timotimo ah, OK
00:37 timotimo and a | sort | uniq -c | sort -n
00:50 colomon joined #moarvm
01:48 FROGGS_ joined #moarvm
01:56 cognominal joined #moarvm
02:01 FROGGS_ joined #moarvm
03:00 jimmyz joined #moarvm
03:00 jimmyz Stage parse      :  36.933, 1.4s lower since yesterday :)
03:01 tadzik joined #moarvm
03:01 ventica joined #moarvm
03:01 cognominal joined #moarvm
03:02 avuserow joined #moarvm
03:31 xiaomiao I wonder what the standard deviation of those benchmarks is ;)
03:31 xiaomiao 37sec +-1 sec, that's about 3% ... that could be "noise"
03:52 ilbot3 joined #moarvm
03:52 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:56 ventica joined #moarvm
05:18 avuserow joined #moarvm
05:35 bcode joined #moarvm
05:57 avuserow joined #moarvm
06:18 sergot o/
07:19 ventica joined #moarvm
07:24 cognome joined #moarvm
07:30 cognome_ joined #moarvm
07:50 ventica joined #moarvm
08:01 ventica joined #moarvm
08:13 zakharyas joined #moarvm
08:18 Ven joined #moarvm
08:39 masak \o
08:39 nwc10 o/
08:47 FROGGS[mobile] joined #moarvm
08:53 brrt joined #moarvm
09:06 brrt joined #moarvm
09:06 brrt left #moarvm
09:21 jnthn o/
09:31 nwc10 OK, so one key part of testing is "don't fill the disk"
09:32 masak heh.
09:33 colomon joined #moarvm
09:52 jose__ joined #moarvm
10:31 nwc10 m: say 6.7812e+01/6.8598e+01
10:31 camelia rakudo-moar 89c8e4: OUTPUT«0.988541939998251␤»
10:31 nwc10 jnthn: that's the setting build speedup, once the disk is only 90% used
10:36 jnthn nwc10: Speedup since when, exactly? :)
10:36 nwc10 er, last time I measure it. Which was probably yesterday morning.
10:37 nwc10 grammar/fingers gah
10:38 nwc10 I'm going to measure parrot performance again, to see if it gained more
11:05 carlin joined #moarvm
12:20 dalek MoarVM: b6a9cad | jnthn++ | src/core/frame.c:
12:20 dalek MoarVM: Fix an uninitialized variable bug.
12:20 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b6a9cad663
12:22 klaas-janstol joined #moarvm
12:42 oetiker joined #moarvm
12:53 dalek MoarVM: e92aa36 | jnthn++ | src/6model/ (13 files):
12:53 dalek MoarVM: De-virtualize most reader functions.
12:53 dalek MoarVM:
12:53 dalek MoarVM: No point to call the same thing every time through a function pointer.
12:53 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e92aa364b5
12:53 dalek MoarVM: 9a3a96d | jnthn++ | src/6model/serialization.c:
12:53 dalek MoarVM: Bump minimum serialization format version.
12:53 dalek MoarVM:
12:53 dalek MoarVM: This in turn enables us to assume we have varints in the thing we
12:53 dalek MoarVM: are reading, which we have for quite a while now.
12:53 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9a3a96d592
12:53 dalek MoarVM: 6da5b90 | jnthn++ | src/6model/ (9 files):
12:53 dalek MoarVM: De-virtualize read_var_int.
12:53 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6da5b908ca
13:03 dalek MoarVM: f55e682 | jnthn++ | src/6model/ (14 files):
13:03 dalek MoarVM: De-virtualize serialization write functions.
13:03 dalek MoarVM:
13:03 dalek MoarVM: Again, the abstraction was unused and unrequired.
13:03 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f55e682594
13:55 nwc10 m: say 6.597e+01/6.7812e+01
13:55 camelia rakudo-moar 4d347f: OUTPUT«0.972836666076801␤»
13:55 nwc10 er, so that's 2.5% speedup since this morning
14:06 FROGGS[mobile] O.o
14:15 zakharyas joined #moarvm
14:36 [Coke] does the .msi have rakudo-moar in it?
14:37 [Coke] so, I have someone who is a cpan module author, who has written XS stuff, has hacked on perl core in the past... and he's too intimidated to use perl 6.
14:37 timotimo to *use* it?
14:37 timotimo interesting, should be a good "test subject" :)
14:38 [Coke] even to get a copy setup to play with.
14:38 timotimo he's on windows, yeah?
14:38 timotimo froggs had a rakudo star moarvm msi release candidate at one point
14:38 [Coke] well, step one, we need a better story on perl6.org.
14:38 timotimo nobody tested it, so it disappeared again
14:39 btyler perl6 is extremely intimidating at first, because the vast majority of the code you encounter 'casually' is straight from the core rakudo crowd
14:40 btyler and that code tends to be rather dense, in the interest of maximally demonstrating power in minimal space
14:40 [Coke] I think we could borrow some ideas from the mojolico.us site.
14:40 btyler most perl 5 code you might encounter randomly is more or less baby perl
14:41 [Coke] btyler: he's not even at code. too many options before that.
14:41 btyler ah, sorry, projected from my own experience too much :)
14:44 timotimo that does happen, yeah :(
14:44 timotimo i thought about giving perl6.org an "express lane"
14:47 * [Coke] creates a playground to test with...
14:47 timotimo what is this "playground"? :)
14:47 [Coke] a fork.
14:48 timotimo ah, of course
14:56 * [Coke] trips over the prereqs. whoops.
15:00 hoelzro [Coke]++
15:05 [Coke] ... I thought I was in #perl6 this whole time.
15:05 timotimo ah
15:05 [Coke] whoops
15:18 ventica joined #moarvm
15:29 dalek Heuristic branch merge: pushed 16 commits to MoarVM/moar-jit by jnthn
15:29 jnthn brrt: Updated moar-jit to master, are confirming it works. :)
15:35 timotimo "are confirming"?
15:35 jnthn *after
15:35 timotimo ah, excellent!
15:35 timotimo and even jit-moar-ops is in there
15:36 timotimo things are looking mighty fine :)
15:37 jnthn Except that things are slower with the JIT enabled...
15:38 timotimo yeah
15:38 timotimo probably just spending too much time aborting frames, still?
15:39 jnthn Not sure yet
15:39 jnthn Seeing if I can discover anything.
15:39 timotimo have you counted how often the jit-invocation opcode got hit?
15:46 dalek MoarVM/moar-jit: 3f22397 | jnthn++ | Configure.pl:
15:46 dalek MoarVM/moar-jit: Make dynasm rule work on nmake.
15:46 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/3f223974dd
15:46 dalek MoarVM/moar-jit: bafbc3b | jnthn++ | src/jit/emit_win32_x64.c:
15:46 dalek MoarVM/moar-jit: Win32 JIT output was behind.
15:46 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/bafbc3bcbc
16:00 jnthn Oddly, my profiler claims that we spend 6% of the time in JITted code, but the time spent in the interpreter only goes down by 1%
16:02 timotimo oh, huh?
16:03 timotimo but the jitted code ought to be at least a bit faster, right?
16:03 timotimo hm, except
16:03 timotimo if gcc strongly optimizes the interpreter loop, maybe it handles moving stuff from register to register directly instead of going through our locals storage?
16:04 timotimo i don't quite see how that would be doable without "unrolling" the interpreter loop, though
16:04 ventica joined #moarvm
16:07 lizmat btyler / [Coke] : TheDamian gave a nice example of how he ported a perl 5 utility of his to perl 6
16:07 lizmat at OSCON, wonder where that code lives nowadays
16:25 japhb lizmat: Is there a video of that?
16:25 timotimo i want to know, too
16:25 lizmat yes, check out OSCON videos  :-)
16:25 japhb 2014?
16:29 timotimo jnthn: does the jit dump the generated bytecode to files, perhaps?
16:30 timotimo Got negative offset for dynamic label 6  -  i wonder where that comes from?
16:31 jnthn Not by default, afaict
16:32 timotimo even with a jit log i get 32.407 for stage parse
16:32 timotimo that's not too bad, is it?
16:33 jnthn If you set MVM_JIT_DISABLE=1 here, it comes out slower than with JIT, though.
16:33 jnthn uh, faster than with JIT
16:34 timotimo hold on.
16:35 timotimo only about 0.3 seconds
16:36 timotimo hm. maybe 0.5
16:39 cognome joined #moarvm
16:39 timotimo 788 frames compiled
16:39 japhb I'm not sure we can expect the JIT to be loads faster than spesh until we move from "the easy way that works" to "optimizing all the cycles".  A JIT is an expensive thing, and you have to win it back with seriously tuned output.
16:39 timotimo 882 bails
16:39 japhb Especially while the execution flow has to bounce in and out of JIT land
16:39 timotimo sp_findmeth is still the king
16:40 timotimo with 271
16:40 timotimo (probably because of much improved bytecode? maybe we have less frames all-in-all now?)
16:40 japhb Getting it working with just neutral performance v. spesh is already a good thing, because it would mean the generated code is enough faster to make up for the cost of generating it.
16:41 timotimo yes
16:42 japhb oh, timotimo: did you look at the flame chart info I sent you in #perl6 earlier?
16:42 timotimo yes, pretty!
16:42 japhb Man, I want that for my Perl 6 code ....
16:43 timotimo well, with the "perf" line from that one blog post you can already get that for the c-level stuff
16:45 cognominal joined #moarvm
16:45 cognome joined #moarvm
16:46 jnthn Thing is that it's hard to explain it as "JIT takes time", when my profiler is telling me 0.1% of the time is spent doing that.
16:47 timotimo hm. how does that measure time spent in c functions called from the jit?
16:47 timotimo oh, that number is for "jitting frames"
16:48 jnthn yES
16:48 jnthn *yes
16:48 jnthn I'm just wondering if it's because CORE.setting's deopt count is epic.
16:48 timotimo how come we have "loadlib" ops in "name", "type", "box_target", "positional_delegate" and "associative_delegate"?
16:49 jnthn And falling back out of the JIT when deopting is more expensive than a switch-code-in--interpreter deopt.
16:49 timotimo and has_accessor?
16:49 jnthn timotimo: um...not sure I follow?
16:49 timotimo in the jit bail log i see a bunch of failures with the loadlib opcode
16:49 timotimo i ... don't think i understand what it does
16:50 timotimo ah, that op would expect to hit the cache a bunch of times
16:51 timotimo i hope the lock contention isn't too bad on that when we get to multithreaded apps. but i don't even know under what circumstances loadlib opcodes are generated
16:51 jnthn loadlib is hot?
16:51 timotimo don't think it is
16:51 jnthn That'd be...odd
16:51 timotimo just 9 bails
16:52 timotimo ah, loadlib is probably just used to get a handle to a library and then findsym would be used to get at whatever symbols it'd expose
16:52 timotimo that sounds like something that could spesh well.
16:54 jnthn What are you seeing loadlib in?
16:54 timotimo jit bail log
16:54 jnthn For?
16:55 timotimo the core setting
16:55 timotimo don't let me distract you, it's probably nothing
16:58 timotimo oh, that could be the methods of the Perl6::Compiler
17:03 jnthn timotimo: Did you do some work on reducing guards at some point?
17:04 jnthn origin/split_get_use_facts <- was that pending review?
17:08 FROGGS joined #moarvm
17:08 FROGGS o/
17:08 jnthn o/ FROGGS
17:14 TimToady \o
17:15 carlin
17:32 colomon joined #moarvm
17:45 dalek MoarVM: 9d377a3 | (Timo Paulssen)++ | src/ (3 files):
17:45 dalek MoarVM: split get_facts and use_facts from get_and_use_facts.
17:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9d377a3d6b
17:45 dalek MoarVM: be8cfdf | (Timo Paulssen)++ | src/spesh/optimize.h:
17:45 dalek MoarVM: fix teh build
17:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/be8cfdf8f0
17:45 dalek MoarVM: b57061e | jnthn++ | src/spesh/osr.c:
17:45 dalek MoarVM: Ensure OSR-triggered optimize is used next invoke.
17:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b57061e168
17:45 dalek MoarVM: 8df127a | jnthn++ | src/ (3 files):
17:45 dalek MoarVM: Merge remote-tracking branch 'origin/split_get_use_facts'
17:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8df127ae61
17:45 dalek MoarVM: 49f19ca | jnthn++ | src/spesh/log.h:
17:45 dalek MoarVM: Tweak spesh log run count.
17:46 jnthn timotimo: merged the branch, thanks :)
18:53 timotimo oh, that
18:53 timotimo nice :)
19:01 nwc10 Result: PASS
19:14 jnthn Nice. Time to break more stuff :P
19:15 nwc10 other people could just write more tests
19:15 timotimo jnthn: about the loadlib thing i said earlier: there's a bunch of frames that look exactly like this: https://gist.github.com/timo/9e49a3806f02857a484f
19:16 jnthn What on earth...
19:17 [Coke] do we have a pic of some kind somewhere to show the flow of a program through rakudo when it's on Moar? (esp. with the new spesh/jit stuff?)
19:17 timotimo my thoughts exactly.
19:18 jnthn No. If you're lucky I might draw one for my YAPC::EU talk though :)
19:20 [Coke] jnthn: perfect, that'd be fine!
19:20 [Coke] DAMMIT, it's in Sofia!?
19:21 [Coke] I have free beer waiting for me in Sofia!
19:21 [Coke] ... I cannot remember the name of the guy who owes me the beer. *sadface*. it's been too long.
19:22 timotimo jnthn: what's keeping us from closing the loop on the "put argument names into callsites" optimization?
19:23 jnthn timotimo: No much; it's just fiddly and annoying to do and will have a fairly low ROI
19:24 timotimo OK then
19:25 * timotimo pushes it further to the back  :P
19:27 timotimo jnthn: would you be interested to sketch out ideas for how to turn spesh into a profiling thingie in the future?
19:29 ventica joined #moarvm
19:29 carlin [Coke]: ahh, so that's why rakudo 2014.07 is codenamed Sofia
19:32 FROGGS joined #moarvm
19:35 nwc10 m: say 6.636e+01/6.597e+01
19:35 camelia rakudo-moar 085ab9: OUTPUT«1.00591177808095␤»
19:36 nwc10 slight negative speedup since lunchtime.
19:36 jnthn Hmm
19:36 jnthn Wonder what's to thank for that...
19:36 nwc10 but, given I've had repeatable speed diferences depending on the order that object files are linked
19:36 nwc10 there is some level of insanity in performance metrics
19:45 dalek MoarVM: 985cd8b | jnthn++ | src/core/bytecode.c:
19:45 dalek MoarVM: Bump minimum bytecode version to 2.
19:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/985cd8bad7
19:45 dalek MoarVM: 0043778 | jnthn++ | src/ (3 files):
19:45 dalek MoarVM: Split out part of frame deserialization.
19:45 dalek MoarVM:
19:45 dalek MoarVM: The split out part will be able to happen lazily, the first time we
19:45 dalek MoarVM: need it. (At present that won't be much of a win as we touch many of
19:45 dalek MoarVM: the frames at startup to install static lexical information; the plan
19:45 dalek MoarVM: is to move this information into the bytecode file also).
19:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/00437788c3
20:02 timotimo nwc10: maybe we should start putting -flto into our gcc commandlines?
20:03 jnthn timotimo: How much difference does it make?
20:03 nwc10 I have no good idea about that
20:03 timotimo haven't measured yet
20:05 timotimo jnthn: that commit above combined with the plan you mention in it ... would that make a difference for memory usage?
20:05 timotimo like, not using 99% of the frames in core setting would free up a bit of memory?
20:07 jnthn timotimo: That's the hope, yes
20:07 jnthn timotimo: And maybe a bit of a startup saving too
20:07 timotimo i'd like that a whole lot
20:53 dalek MoarVM: 0098c0c | jnthn++ | src/ (5 files):
20:53 dalek MoarVM: Preparations for lazy frame deserialization.
20:53 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0098c0cfba
20:53 dalek MoarVM: cdda218 | jnthn++ | src/core/bytecode.c:
20:53 dalek MoarVM: Switch on lazy frame deserialization.
20:53 dalek MoarVM:
20:53 dalek MoarVM: Or at least, the parts we can easily get away with putting off until
20:53 dalek MoarVM: later. While it needs further work to take further advantage, NQP
20:53 dalek MoarVM: shows a 2.2% and Rakudo shows a 1.4% memory reduction for the empty
20:53 dalek MoarVM: loop program.
20:53 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cdda2182de
20:54 timotimo 1.4% would be about 2 megabytes?
20:55 jnthn Yeah, just short of
21:07 zakharyas joined #moarvm
21:23 btyler joined #moarvm
21:34 dalek MoarVM: c65b2a6 | jnthn++ | docs/bytecode.markdown:
21:34 dalek MoarVM: Spec static lexical values table in bytecode.
21:34 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c65b2a6b63
22:03 dalek MoarVM: 9ba5d15 | jnthn++ | src/mast/compiler.c:
22:03 dalek MoarVM: No longer need to support Parrot cross-compiler.
22:03 dalek MoarVM:
22:03 dalek MoarVM: It's almost certainly broken beyond repair to cross-compile from
22:03 dalek MoarVM: Parrot to Moar anyway, so no need to keep these last bits around.
22:03 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9ba5d1598f
22:03 dalek MoarVM: ac33547 | jnthn++ | lib/MAST/Nodes.nqp:
22:03 dalek MoarVM: Update MAST::Frame to hold static lex values.
22:03 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ac335479d6
23:25 dalek MoarVM: c0984eb | jnthn++ | src/ (4 files):
23:25 dalek MoarVM: Write static lex values; read but don't apply them
23:25 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c0984eb7b5
23:25 dalek MoarVM: e64c5eb | jnthn++ | src/core/bytecode.c:
23:25 dalek MoarVM: Read in static lexicals.
23:25 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e64c5ebabb
23:27 dalek MoarVM: f25affb | jnthn++ | src/mast/nodes_moar.h:
23:27 dalek MoarVM: MAST nodes can be identified by exact type.
23:27 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f25affbb43
23:30 timotimo oh, that ought to help a lot
23:31 timotimo we do istype on mast nodes all the time
23:31 timotimo oh, that's only for inside the mastcompiler
23:31 timotimo but it should still help
23:31 jnthn It's a small improvement...the cache-only istype is quite cheap anyway
23:32 timotimo #define EMPTY_STRING(vm)            (MVM_string_ascii_decode_nt(tc, tc->instance->VMString, ""))
23:32 timotimo we have a per-tc (or per vm?) empty string nowadays
23:32 jnthn per vm
23:32 jnthn where on earth do we use that macro..
23:32 jnthn oh, once per compilation
23:32 jnthn no big saving
23:32 timotimo ./src/mast/compiler.c:        hll_str_idx = get_string_heap_index(vm, ws, EMPTY_STRING(vm));
23:32 jnthn but yeah, feel free to tweak it
23:33 timotimo oke
23:37 dalek MoarVM: ff15814 | (Timo Paulssen)++ | src/mast/nodes_moar.h:
23:37 dalek MoarVM: we can use the vm's empty string constant here.
23:37 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ff158147ce
23:39 timotimo should i perhaps teach the ascii encoding about strlen(0) strings re-routing them to the global empty string constant if it exists?
23:41 jnthn I think they are widely interned...
23:41 jnthn And utf8 would be a better one to teach it
23:42 timotimo mhm
23:43 jnthn Fun fact: somewhere in Grammar.pm is a frame with 612 labels
23:43 timotimo oh, cute
23:43 timotimo is that after inlining?
23:43 jnthn No!
23:43 timotimo oh wow!
23:44 jnthn Well, aside from NQP's block flattening of course.
23:44 timotimo seems pretty jumpy
23:44 jnthn Yeah
23:44 jnthn Well, I'm pondering some MAST::Label changes.
23:44 jnthn Today, we always make a string name for a MAST::Label, passing it to its constructor
23:45 timotimo could be integers, too, right?
23:45 jnthn However, we never - afaik - in the compiler make two MAST::Labels with the same identifier
23:45 jnthn Well, they could be integers, yes.
23:45 jnthn The alternative is that they just work by object identity
23:45 jnthn Which I believe would work with the current codebase.
23:45 jnthn Saving 8 bytes per MAST::Label
23:45 timotimo hey, with jit enabled and latest master i get 30.5 seconds stage parse on my laptop :3
23:46 timotimo oh, even better
23:46 jnthn But I was then thinking "hm, I have no hash key"
23:46 jnthn And wondering what happens if I make a linear scan of the labels.
23:46 jnthn It'll be a C array so not *too* bad.
23:46 timotimo even if you have a frame with 612 labels?
23:47 jnthn A hash may be O(1) but the constant overhead isn't automatically cheap.
23:47 jnthn Well, that's an extreme/rare case.
23:47 timotimo that's right
23:47 jnthn Most frames are tiny.
23:47 jnthn We might lose out on the odd extreme one.
23:47 timotimo so at least the linear search is going to be limited to each frame individually
23:47 jnthn Right.
23:47 timotimo that does sound sensible; do you have a histogram of frame sizes or something?
23:47 jnthn No
23:47 jnthn I just looked for maximum ones
23:47 jnthn But I'm quite used to reading spesh logs :)
23:48 jnthn And labels <=> basic blocks are clsoe
23:48 jnthn *close
23:48 timotimo ah, yes
23:48 timotimo i've not seen any with 4 digit BBs in core setting :)
23:48 jnthn I wonder how many labels we create in compilation...
23:52 jnthn m: say 21160 * 8
23:52 camelia rakudo-moar fb0521: OUTPUT«169280␤»
23:52 jnthn That's how much we'd save on MAST::Label directly
23:52 jnthn But we save all the strings too
23:54 jnthn m: say 21160 * (6 * 8 #`(string size) + 10 #`(conservative label length estimate) * 4 #`(per grapheme))
23:54 camelia rakudo-moar fb0521: OUTPUT«1862080␤»
23:55 jnthn Not so much I guess.
23:55 jnthn Though there's at least 1 intermediate string too, which is the numification of the number stuck onto it.
23:56 jnthn Well, may give it a go tomorrow to see how it helps

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