Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-05-11

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

All times shown according to UTC.

Time Nick Message
01:28 FROGGS joined #moarvm
01:36 lue joined #moarvm
02:11 colomon joined #moarvm
09:43 nwc10 mmmm, had to "fix" coffee machine to get second cup
09:44 nwc10 emptied waste, took grinder mechanism out, cleaned off escaped coffe, but it back together, everything happy first time)
09:44 nwc10 no idea why this worked
09:44 nwc10 have coffee.
09:44 nwc10 for now.
09:52 jnthn phew :)
09:52 nwc10 and time to plan a hiding place: http://www.bbc.co.uk/news/entertainment-arts-27358560
09:52 jnthn mine seems to clog itself increasingly often, needing a cleaning to stop it depositing coffee everywhere...
09:53 nwc10 the idae is coffee + water + heat => happy human + compost
09:53 nwc10 jnthn: problem with git was git - it was me failing to realise that the git 1.5.6 didn't have https support
09:53 nwc10 the error gets lost somewhere
09:54 nwc10 and we have some fun on sparc - the atomic ops seem to generate v9 assembler instructions
09:54 nwc10 gcc default is v9
09:54 nwc10 er
09:54 nwc10 v7
09:54 nwc10 so, sadly anyone with a CPU more than 19 years is out of luck
09:54 FROGGS :/
09:55 FROGGS I have an Amiga 2000 here with a 7.9MHz CPU I was hoping to use
09:55 nwc10 Can you fix the perl 5 port? The problemm was that they were relying on vfork...
09:56 FROGGS nwc10: are you serious? :o)
09:56 nwc10 not quite. I wouldn't expect anyone to do it with hardware that old
09:56 nwc10 but the serious bit is, given that Amiga is never going to die
09:57 nwc10 would be nice if they figured out how to fix it, and punted it back upstream
09:57 nwc10 it's an ASCII based platform, no cross compiling and not massively strange
09:57 FROGGS yeah, I don't even know if my system still boots
09:57 nwc10 so it's not a massive problem
09:57 nwc10 I wouln't suggest bothering. Rakudo is more interesting
09:57 FROGGS it was a very nice thing back then
09:58 nwc10 jnthn: bad news - spesh_trace + lexopts + nom goes boom *boringly* with ASAN
09:58 nwc10 Stage start      :   0.000
09:58 nwc10 Stage parse      : Internal error: invalid thread ID in GC work pass
09:58 nwc10 jnthn: I can't get the sparc to link properly even with -mcpu=v9 and -DAO_REQUIRE_CAS
09:59 nwc10 ./libmoar.so: undefined reference to `AO_fetch_compare_and_swap_full'
09:59 nwc10 that define is supposed to force emulation of everything else
09:59 nwc10 and it's not providing one, even in 3rdparty/libatomic_ops/src/libatomic_ops.a
10:00 jnthn Urgh
10:00 nwc10 I will try to hammer it further after a bath
10:00 nwc10 I'm tempted to try to do it two ways
10:00 jnthn nwc10: On the invalid thread ID thing - the way to find that most efficiently is with the mprotected fromspace thingy
10:00 nwc10 1) there seems to be a complete emulation layer
10:00 nwc10 (CPU independant)
10:00 nwc10 2) fix sparc better
10:00 jnthn But I'll use the info from retupmoca to see if I can hunt it down from that.
10:01 nwc10 as we're likely to need to offer the first to all Debians superfun platforms
10:01 nwc10 jnthn: the mprotected fromspace stuff is a bit stale
10:01 nwc10 and there was at least 1 fix I didn't send (which might just be relevant)
10:01 nwc10 something turns on allocate to gen 2 to stop stuff moving
10:02 nwc10 it calls somethign else which also does this
10:02 nwc10 the inner thing turns off gen 2
10:02 vendethiel joined #moarvm
10:02 nwc10 the rest of the stuff is not gen2
10:02 jnthn ah
10:02 nwc10 the outer thing turns of gen 2
10:02 nwc10 I forget where, but an assert should find it
10:02 nwc10 I didn't have an idea for a great fix
10:02 nwc10 possibly just a nesting count, which aborts if it overflows
10:02 jnthn Well, turn it into a counter rather than a boolean I guess
10:02 nwc10 Perl 5 has a big complex thing which can unwind stuff on scope exit
10:03 nwc10 but once you have the big complex thing, you can use if for stuff like this
10:04 nwc10 jnthn: the fromspace stuff is also hideously slow once you get to trying to do it for every allocation
10:04 nwc10 and it doesn't have enough memory to be perfect
10:04 nwc10 (as you found some that it missed)
10:04 nwc10 but it would be several days to get to the point of building the setting
10:05 jnthn nwc10: We can't get to that point normally and then throw it at the setting only?
10:05 nwc10 I was thinking that
10:05 nwc10 however, I think it would take quite a while to clean the local patches up
10:06 jnthn OK
10:06 jnthn I'll try and find it using...other means.
10:06 jnthn As a first resort.
10:20 timotimo the nintendo 3ds has 128mb ram, so it could just barely run an empty perl6-m (it's an arm9)
10:25 timotimo watching the directory where moarvm is outputting its spesh log using perl6-m is devastating. it gets so many change events that it takes ages to catch up with the actually current state
10:29 brrt joined #moarvm
10:29 brrt hey, quick question
10:29 brrt is the MIT license 'compatible' with the Artistic License?
10:31 brrt oh, i see, it is
10:31 brrt mit license is rather liberal
10:32 jnthn I think so, yes
10:33 tadzik I like it a lot. I tend to think of it as „do whatever you want, just don't pretend that you wrote it”
10:34 jnthn um, wtf
10:34 jnthn container_type_info doesn't even show up in my core.setting spesh log...
10:35 * jnthn downloads the one from retupmoca
10:37 jnthn oh, duh
10:37 jnthn was looking at wrong output
10:37 timotimo know that feeling >_>
10:38 * brrt is off for lunching
10:38 brrt left #moarvm
10:43 jnthn invoke_o r56(13), r50(29)
10:43 jnthn [Annotation: INS Deopt One (idx 68 -> pc 7880)]
10:43 jnthn sp_guardcontconc r56(13), liti16(4), liti16(5)
10:43 jnthn That's the usage of the spesh slot 5
10:51 jnthn timotimo: Did you also get the SEGV?
10:53 timotimo i sometimes did
10:53 jnthn OK. I found a couple of potential issues
10:54 jnthn One of which could lead to reading junk memory
10:54 timotimo also, when an exception is thrown in a thread and caught by the default handler, it seems like the vm sometimes exits very uncleanly
10:55 timotimo may be known.
10:56 jnthn Default handler in the VM? Hmm
10:58 jnthn timotimo: https://gist.github.com/jnthn/19e017bca18c42a10c04
11:00 jnthn Gonna push that one after local testing, though, 'cus even if it doesn't fix the SEGV it's needed.
11:02 timotimo would you be okay with me introducing a sp_nonnull opcode so that i can optimize isstr/ishash/isnum/islist/... into an sp_nonnull instead of creating multiple bytecodes with extra registers?
11:02 timotimo is there a policy?
11:02 timotimo we only have 256 slots, right?
11:03 timotimo no, wait, we write a 16bit integer for the opcode
11:03 timotimo so we do have enough :)
11:03 jnthn What would sp_nonnull do?
11:04 timotimo the opposite of isnull
11:04 nwc10 jnthn: left it running on x86_64 - crash is non-deterministic
11:04 jnthn You can't emit a not_i after it?
11:05 timotimo no, because then i have to allocate extra registers :)
11:05 nwc10 this time it got through the setting, and gave a similar error in thenext thing
11:05 timotimo remember we don't have a design for that yet? :)
11:06 dalek MoarVM/spesh_trace: bed1693 | jnthn++ | src/spesh/facts.c:
11:06 dalek MoarVM/spesh_trace: Be more careful over concreteness in facts.
11:06 dalek MoarVM/spesh_trace:
11:06 dalek MoarVM/spesh_trace: Of note, we could try to look "inside" a container type's type
11:06 dalek MoarVM/spesh_trace: object - meaning we looked past the end of it, leading to reading
11:06 dalek MoarVM/spesh_trace: random memory.
11:06 dalek MoarVM/spesh_trace: review: https://github.com/MoarVM/MoarVM/commit/bed169375f
11:06 jnthn timotimo: But...isnull puts its result in an int register?
11:06 timotimo aye
11:07 jnthn And you know you're the writer of that register
11:07 jnthn So if you immediately follow it with a negation...
11:07 timotimo i can just do it? what about versions of registers?
11:07 jnthn Ah...
11:07 timotimo don't i have to be careful about that?
11:07 jnthn You'll get away with it...at the moment.
11:07 jnthn I'm doing that trick with the invoke optimization at present
11:07 jnthn But yeah, it's...hmm
11:08 jnthn Well, we could have an isnonnull to go with isnull...
11:08 jnthn I don't see why it has to be a spesh op
11:08 timotimo say ... do you think we'll ever get a perl6-m that only uses ~50 megabytes or less fo rma when starting up empty? without partial loading of the setting?
11:08 jnthn We have eq and ne for all the other things...
11:08 brrt joined #moarvm
11:08 jnthn I'd like to hope so, but need to work out where the memory is going.
11:09 timotimo i wanted to make it a spesh because we don't have to emit it during normal bytecode building
11:09 timotimo yes, we do :\
11:09 jnthn I'm saying that it could be useful for emitting in normal bytecode building though
11:09 timotimo aye, it could
11:10 timotimo i don't feel like adding new bytecodes in two different places on two branches, so i'll wait for the spesh_log branch (more concretely: my spin-off-branch of it) to be merged
11:10 jnthn nwc10: bed1693 may fix the problems
11:10 jnthn timotimo: If you could also try bed1693 that'd be great
11:10 timotimo will do
11:13 timotimo reading junk memory could definitely explain the sporadicness
11:14 timotimo seems fine so far
11:15 nwc10 jnthn: was already testing. now at Stage optimize
11:16 timotimo seems like i can't get it to break any more. well done!
11:16 timotimo jnthn: i'm still convinced interning strings more agressively would give us a ram usage benefit
11:17 nwc10 does the JVM have existing good tools that would help track down general memory usage?
11:18 timotimo the regular heap analyzer will tell us "you've got one billion instances of SixModelObject using up all the rams!"
11:18 timotimo i think hoelzro prototyped something that'd inspect the SMO for what class it represents
11:18 nwc10 that's boringly unhelpful
11:18 nwc10 summon hoelzro
11:18 timotimo i cast "summon bigger fish"
11:19 jnthn nwc10, timotimo: yay that things seem better
11:20 * jnthn wonders if that means "yes, we can merge spesh_trace"
11:20 jnthn Certainly there's more bits I want to do but I don't think they need a branch...
11:21 nwc10 I'm in spectest
11:21 jnthn k
11:21 nwc10 are you in a position to review my dancing bears?
11:21 nwc10 at this point? or post noms
11:21 nwc10 or post noms, walk, and other important things
11:22 jnthn Yeah, that's next on my hit list after getting spesh_trace merged
11:22 jnthn Just wanted to find/fix this SEGV first.
11:22 nwc10 totally understandable
11:22 jnthn And it looks like we have :)
11:22 nwc10 my fanclub is patiently waiting at my feet
11:22 nwc10 she doesnt' care that it's raining
11:22 nwc10 spctest failed the usual S17
11:24 timotimo yeah, can't get it to asplode during compilation any more
11:24 timotimo so i suppose i'm +1 on merging :)
11:24 jnthn yays
11:26 timotimo will that also include my small const i64 branch? :3
11:27 jnthn Well, guess that wants re-testing on top of latest spesh to make sure it really was the bug I just fixed that was the source of the crashes seen...
11:28 nwc10 jnthn: there is something wierd going on on sparc. Pre-processed source suggests that it defines an inline function
11:28 timotimo i can get on that testing :)
11:28 jnthn o.O
11:29 dalek Heuristic branch merge: pushed 40 commits to MoarVM by jnthn
11:29 nwc10 so, OK, why the missing symbol reference? What is trying to take its address, or whatever
11:30 timotimo wow, whoops: register operand index 34128 out of range 0..10
11:31 jnthn you don't say...
11:31 timotimo i think my little merge broke stage0 loading :)
11:31 jnthn ah
11:31 jnthn yeah
11:31 jnthn be careful you put your new ops at the end
11:31 timotimo hm, but i added my opcodes *after* execname
11:31 timotimo ah
11:31 timotimo execname forgot the goto NEXT :)
11:32 timotimo wrong
11:32 timotimo i did.
11:32 timotimo the merge made it wibbly wobbly :)
11:32 timotimo that wasn't it :|
11:34 jnthn OK, merged all my various branches
11:34 nwc10 drink!
11:35 nwc10 (coffee machine still working)
11:35 nwc10 (fret not - there is a backup coffee machine here too)
11:35 timotimo oh, lexopts is now in master? :D
11:38 jnthn yup :)
11:38 jnthn your CPU can read unaligned values for all of int32 int64 num64
11:38 jnthn Well, it gets that right :)
11:40 timotimo i don't understand why the bytecode verifier is complaining about my code :(
11:41 jnthn nwc10: Is "nmake src\spesh\graph.i" meant to be dumping to stdout?
11:41 nwc10 no
11:42 nwc10 this might mean that the Perl 5 Win32 makefiles *are* buggy :-)
11:42 nwc10 the *nix ones use '> ' as the output flag to capture it to a file
11:42 nwc10 seems that Win32 needs the same trick
11:42 nwc10 I'm surprised that no-one wanted those targets before
11:42 jnthn nmake src\spesh\graph.asm
11:43 jnthn Is quite a fail too it seems :(
11:43 nwc10 I'm already using them to try to figure out sparc
11:43 nwc10 oh bother
11:43 jnthn It puts an object file into a file with .asm syntax
11:43 nwc10 *something* ought to work on win32
11:43 jnthn And then tries to link it...with nothing else.
11:43 nwc10 so wrong output flag?
11:43 nwc10 I read something on the Internet and assumed that it was true :-(
11:44 jnthn oh...
11:44 jnthn Yeah
11:44 jnthn /Fo<file> name object file
11:44 jnthn *always* means object file
11:44 nwc10 OK
11:45 nwc10 seems to mean "output" file on gcc
11:45 nwc10 as it made it possible to generate src/core/interp.s not interp.s at the top level
11:46 jnthn /Fa[file] name assembly listing file
11:46 jnthn and
11:46 jnthn /Fi[file] name preprocessed file
11:46 jnthn look useful
11:46 * jnthn tries
11:46 nwc10 /Fi looks more useful than redirect stdout
11:46 nwc10 also, does /E work instead of -E ?
11:47 jnthn Unfortunately just adopting those alone doesn't help...
11:48 nwc10 bother. You don't *need* those two commits for the third one to work. But they are very useful to verify that nothing changed in the generated code in the move from macros to inline functions
11:50 jnthn Ah
11:50 brrt http://brrt-to-the-future.blogspot.nl/2014/05/as-part-of-my-community-bonding-period.html blawg post about dynasm :-)
11:51 jnthn For preprocessed and output to a file we want /P, not -E
11:51 jnthn So, I fixed that one :)
11:51 FROGGS ahh, something to read, nice :o)
11:54 FROGGS brrt: "An example is included below"... should there be a code block in your blog?
11:55 brrt yes.... didn't work in blogger
11:55 brrt :-(
11:58 nwc10 jnthn: at some point "my" machine is supposed to get a friend, running something Win32, with a build environment
11:58 nwc10 planned to include VC6 :-)
12:09 jnthn *sigh*
12:09 jnthn So... YOu need "/c /FAs" to keep it from invoking the linker
12:09 jnthn That gets rid of the error erruption
12:09 jnthn BUT
12:09 jnthn We also pass /GL in the c falgs
12:09 jnthn Which means "link time code generation"
12:10 jnthn Which has the side-effect of making it decided to do absolutely nothing about generating an assembly file.
12:10 nwc10 OK :-(
12:11 nwc10 does /GL belong in the C flags? Should it be part of the codegen flags? (Sorry if I'm not quite using the correct terms)
12:11 nwc10 P
12:11 nwc10 Perl 5 messes things up. it conflates cpp flags and cc flags
12:11 nwc10 but conceptually there ireally should be clean distinction between pre-processor flags (.c to .i)
12:11 nwc10 then .i to .s
12:11 nwc10 then .s to .o
12:11 jnthn Well, this is optimization flags I guess
12:11 nwc10 and then whatever happens next to .o
12:12 nwc10 bother. optimisation flags do belong at the .i to .s stage
12:13 jnthn Yeah
12:13 jnthn I'm not sure how to fix it
12:14 jnthn Anyway, I now have a state where it works if you know to remove /GL in the makefile...
12:14 * jnthn can think of epic hacks, but... :)
12:19 * jnthn goes rebase -i'ing to get his improvements into the patches, anwyays...
12:21 brrt left #moarvm
12:29 dalek MoarVM: 47536df | nicholas++ | build/ (2 files):
12:29 dalek MoarVM: Add Makefile rules to generate pre-processed source.
12:29 dalek MoarVM:
12:29 dalek MoarVM: Someone awkwardly, @objflags@ can contain -DMVM_BUILD_SHARED, which affects the
12:29 dalek MoarVM: pre-processed source, so for correctness that needs to be in the CPP command
12:29 dalek joined #moarvm
12:38 timotimo someone? :)
12:38 nwc10 oops, typo that neither of us spotted
12:39 jnthn haha
12:39 jnthn Totally missed that
12:39 FROGGS is there missing word?
12:39 jnthn I think s/Someone/Somewhat/ :)
12:39 timotimo i think it ought to be "somewhat"
12:40 jnthn OK, onto dancing bear #2...
12:40 timotimo jnthn: do you have an idea for how to model things like "if we're in BB n, this fact about this register is true"? like when we branch into a block because something is null, for example?
12:41 jnthn timotimo: There's not really a good way to do that in the current model
12:41 timotimo OK
12:45 timotimo jnthn: i've redone a patch to introduce the small int literal ops, it still builds, now i'm going to try to figure out why the F adding the code to the compiler itself breaks
12:45 timotimo may i push the change that introduces the ops already? and add isnonnull, too?
12:46 jnthn It doesn't break the build of anything?
12:46 timotimo doesn't seem so.
12:46 timotimo it's not used anywhere :)
12:47 timotimo meh. no rakudo to run update-ops now :)
12:48 timotimo nwc10: i'll want to mention your portability work in the weekly tomorrow; you've done powerpc and arm7 and arm6? something else?
12:48 timotimo and these are limited to linux, aye?
12:49 nwc10 sparc thing seems to be structural confusion in libatomicops - if AO_HAVE_compare_and_swap exists, it refuses to do the emulation code for AO_HAVE_fetch_compare_and_swap
12:49 nwc10 timotimo: not done arm7. would be useful for someone to test on ARMv7, and on ARMv5
12:49 nwc10 ARMv7 should either build, or be a 3 line fix
12:49 timotimo right; i only have a raspberry pi myself, and a nintendo DS with a homebrew cartridge
12:49 timotimo that'll hardly have enough ram to run moar :)
12:50 nwc10 DS isn't interesting, as it seems to also be ARMv6
12:51 nwc10 oh wow, not, it's ARMv4
12:52 nwc10 Looks like it has less grunt than a 1998 RiscPC
12:52 nwc10 and that's impressive
12:52 timotimo it has two processors
12:52 timotimo one for sound "only"
12:52 nwc10 wikipedia says one is ARM9, which now I've checked further is ARMv4 architecture
12:52 nwc10 I'd forgotten this
12:52 timotimo CPUOne 67.028 MHz ARM946E-S[2] and one 33.514 MHz ARM7TDMI
12:53 nwc10 other, ARM7, is v3
12:53 timotimo ah!
12:53 timotimo i didn't realize there's a difference between with and without v
12:53 nwc10 oh, quite a bit :-)
12:53 nwc10 which I think is why ARM11 is the last CPU with a number
12:53 nwc10 after that it's only architectures that keep numbers
12:53 timotimo 4mb of ram means *nope*, though
12:53 nwc10 CPUs get brand names
12:54 nwc10 timotimo: I'm failing to get sparc linux to work out
12:54 timotimo the inline thingie you mentioned above?
12:54 nwc10 it's not inline, I was getting confused
12:54 timotimo ah, ok
12:54 timotimo but something is giving you trouble. noted :)
12:55 nwc10 between AO_fetch_compare_and_swap and AO_compare_and_swap
12:55 nwc10 or something like that
12:55 nwc10 anyway,
12:55 timotimo so maybe it's trouble in libatomic_ops?
12:55 nwc10 done ARMv6, would welcome testers with ARMv7 and ARMv5
12:55 timotimo or what it's called.
12:55 nwc10 it is trouble in it
12:55 nwc10 12:49 < nwc10> sparc thing seems to be structural confusion in libatomicops -  if AO_HAVE_compare_and_swap exists, it refuses to do the  emulation code for AO_HAVE_fetch_compare_and_swap
12:56 nwc10 OK, yes, to fully answer your question *properly*
12:56 nwc10 ARMv6 linux, PPC linux (but fails a nativecall test), failing to get sparc linux, have no other access
12:56 nwc10 in particular, it's likely that soeone has access to a MIPs linux setup with native toolchain
12:56 nwc10 er, better expressed
12:57 nwc10 ARM linux (only ARMv6 tested so far), PPC linux (only ppc64 tested so far, and fails a nativecall test), failing to get sparc linux, have no other access
12:57 nwc10 but, we are working on big endian now
12:57 timotimo jnthn: my commit to introduce isnonnull and the const_i64_* opcodes are not breaking rakudo build so far
12:57 timotimo so i'm free to push?
12:57 nwc10 and on things will more alignment constraint than x86
12:59 dalek MoarVM: ce2a286 | nicholas++ | src/ (4 files):
12:59 dalek MoarVM: Ensure that MVMCompUnit can correctly free data_start.
12:59 dalek MoarVM:
12:59 dalek MoarVM: This gets slightly complicated because the memory may have been allocated by
12:59 dalek MoarVM: malloc or by mmap, depending on the origin of the bytecode.
12:59 jnthn timotimo: Yes, think that should be OK
12:59 timotimo thanks
13:00 dalek joined #moarvm
13:00 dalek MoarVM: 433d41d | (Timo Paulssen)++ | / (6 files):
13:00 dalek MoarVM: ops to for 32/16 bit 64 int literals and isnonnull
13:00 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/433d41d689
13:02 jnthn nwc10++ # porting
13:03 timotimo ah, with the changes applied afresh, it doesn't break the build any more to have these ops emitted by the mast compiler
13:03 timotimo weird, but i'll accept it.
13:04 * jnthn finally goes to read the brrt++ blog post :)
13:05 dalek MoarVM: eecf142 | (Timo Paulssen)++ | src/mast/compiler.c:
13:05 dalek MoarVM: use smaller const_i64_* ops sometimes.
13:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/eecf142f9b
13:07 dalek MoarVM: c3c427f | (Timo Paulssen)++ | src/spesh/facts.c:
13:07 dalek MoarVM: introduce the const_i64_* ops to spesh.
13:07 dalek MoarVM:
13:07 dalek MoarVM: also, switch/case is a bit nicer to look at.
13:07 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c3c427f79c
13:09 jnthn +            /* Now we'll do a terrible thing */
13:09 jnthn really? :P
13:10 timotimo oh!
13:10 timotimo well, the code does look terrible, doesn't it?
13:10 jnthn It's not so bad :)
13:11 jnthn That switch/case is certainly an improvement.
13:13 jnthn I think it may want to do an ISTYPE on the arg though, before blindly assuming it's a MAST::IVal
13:13 jnthn (It always should be, of course...)
13:13 timotimo i'll have an opt for isstr/... soon, too
13:14 timotimo if the result would be 0 due to type mismatch, it turns into a const + known value, otherwise it turns out into an isnonnull
13:18 dalek MoarVM: a6205ef | (Timo Paulssen)++ | src/spesh/optimize.c:
13:18 dalek MoarVM: try to optimize islist/isnum/... (not helpful yet)
13:18 dalek MoarVM:
13:18 dalek MoarVM: the problem is that islist and friends also include a null
13:18 dalek MoarVM: check on their argument. At best, we could - if we only know
13:18 dalek MoarVM: the type - turn these ops into a negated "isnull" op, but that
13:18 dalek MoarVM: doesn't exist. So we have to wait for spesh's ability to
13:18 dalek MoarVM: allocate new registers and add new operations on those.
13:18 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a6205ef0f6
13:18 dalek MoarVM: 59053a4 | (Timo Paulssen)++ | src/spesh/optimize.c:
13:18 dalek MoarVM: Merge remote-tracking branch 'origin/optimize_isreprid'
13:18 dalek MoarVM:
13:18 dalek MoarVM: Conflicts:
13:18 dalek MoarVM: src/spesh/optimize.c
13:18 timotimo ^ no build breakage detected
13:18 timotimo afk
13:24 FROGGS nwc10++ # patches
13:34 jnthn bbiab
13:40 dalek MoarVM: f34772b | (Timo Paulssen)++ | tools/spesh_diff.p6:
13:40 dalek MoarVM: teach spesh_diff.p6 about the new output of spesh dump
13:40 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f34772b5c5
14:03 dalek MoarVM: 36366c0 | (Timo Paulssen)++ | tools/spesh_diff.p6:
14:03 dalek MoarVM: teach spesh_diff about Facts, put most common pattern first.
14:03 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/36366c07be
14:05 zakharyas joined #moarvm
14:11 timotimo given the massive amount of sp_log instructions emitted, it's hard to find actual things that have been optimized
14:14 jnthn timotimo: Well, they don't appear in the final output.
14:15 timotimo oh
14:15 timotimo i didn't know that
14:16 jnthn There's 3 bits of output now
14:16 jnthn before, after inserting logging, and later on in the file the completed specialization.
14:17 timotimo oh!
14:17 timotimo so that's what was weird about the output in between
14:17 timotimo so should i ignore stuff starting with "inserting logging for"?
14:18 timotimo ah, yes, i see "finished specialization of"
14:18 timotimo and i've been skipping that
14:18 jnthn Yes
14:18 jnthn Now we
14:19 jnthn * Hit the invocation count limit
14:19 jnthn * Insert logging instructions and produce code
14:19 jnthn * Wait for N runs (4 at present)
14:19 jnthn * Use the logged info as part of generating specialized bytecode
14:19 jnthn * Install that for future runs
14:20 timotimo aaah
14:20 timotimo trying a patch to spesh_diff now
14:22 timotimo something's wrong.
14:23 timotimo the tool now seems to be skipping everything
14:27 timotimo oooh snap
14:27 timotimo it's completely changed now
14:27 timotimo there's no longer a Before: and After:
14:27 jnthn Well, the before/after correspond to before, then after we added the logging
14:27 timotimo instead, there is Before:, After: and "only something" in the "finished" thing
14:27 timotimo aye, i need to hold on to the cuids and merge the stuff properly :\
14:28 jnthn Yeah, it's a bit more work to correlate
14:28 timotimo yes, and now having multiple spesh outputs for the same cuid is no longer easy to tell apart :\
14:28 timotimo well, except if they are spaced apart completely
14:29 JimmyZ Error while compiling op ifnull (source text: "nqp::ifnull($!nominal, 0)"): P6opaque: no such attribute '$!result_reg'
14:29 JimmyZ I got an error when building nqp ....
14:29 timotimo did you get back to master on moarvm and nqp?
14:29 JimmyZ yes
14:30 jnthn timotimo: uh...
14:30 jnthn Bytecode validation error at offset 0, instruction 0:
14:30 jnthn invalid extension opcode 40728 - should be less than 1024
14:30 FROGGS JimmyZ: did you made clean?
14:30 jnthn JimmyZ: That error means you don't have latest NQP
14:30 timotimo jnthn: did i cause that? huh?
14:30 jnthn Or didn't make clean or something
14:30 nwc10 invalid extension opcode 16864 - should be less than 1024
14:30 timotimo but locally i can build it just fine :\
14:30 JimmyZ argh
14:30 timotimo crappity crap, i guess
14:31 JimmyZ I missed updated bootstrap
14:34 jnthn timotimo: uh
14:34 jnthn timotimo: unsigned char override_second_argument;
14:34 jnthn That will have a junk value
14:35 timotimo oh! why did i forget that
14:35 timotimo feel free to commit that for me
14:35 jnthn for any op
14:35 jnthn other than iconst_64
14:35 timotimo aye
14:36 timotimo i wonder how i got away with that
14:37 timotimo only locally, of course
14:38 dalek MoarVM: bac3210 | jnthn++ | src/mast/compiler.c:
14:38 dalek MoarVM: Avoid using an uninitialized variable.
14:38 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bac321032e
14:41 jnthn That helps it here
14:42 timotimo phew
14:51 timotimo what is blocking us from getting a filename and line number for warnings such as "use of uninitialized value of type *" on moarvm?
14:52 nwc10 jnthn: that gets me past it too. ASAN doesn't spot those
14:53 brrt joined #moarvm
14:57 jnthn timotimo: Probably nothing in MoarVM itself...
14:57 jnthn timotimo: Suspect something needs tweaking in Rakudo.
14:57 jnthn nwc10: too bad..
14:58 FROGGS jnthn: can I split up a bigger Q:PIR {} into two smaller ones to inject another pir block conditionally?
14:59 FROGGS eww, wrong channel to ask that basically :o)
14:59 nwc10 jnthn: would need to run with valgrind to spot those, which is much slower
15:02 jnthn FROGGS: Probably
15:05 timotimo i may have something workable for spesh_diff now
15:07 timotimo jnthn: is there a way to remove guards if we're not using the facts we've obtained through them?
15:08 timotimo i.e. a guard on something that's dead perhaps?
15:08 timotimo hmm. sounds tricky
15:09 dalek MoarVM: 6966670 | (Timo Paulssen)++ | tools/spesh_diff.p6:
15:09 dalek MoarVM: the layout of spesh logs has changed dramatically.
15:09 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/69666704dc
15:09 timotimo +      set r0(2), r0(1)  -  for real? :)
15:09 timotimo this is even no-oppyer than other sets that have resulted from decont :D
15:11 timotimo https://gist.github.com/timo/2e1f2f559931bc70f7ea - how come there's two spesh ops writing to the same register + version there?
15:11 timotimo r2(4) in both cases
15:21 jnthn That's the invocant opt I mentioned before now
15:21 timotimo oh, ok
15:21 timotimo do we have something that counts how often guards fail?
15:21 jnthn Not yet
15:22 jnthn Don't have "did we even use this guard" tracking yet either.
15:22 timotimo right.
15:25 jnthn Spesh has many wish-list items
15:35 JimmyZ My friend asks where the MoarVM donate URL is ...
15:39 timotimo jnthn: some simple things i could pick off of your wish list?
15:47 jnthn timotimo: can and can_s still could use a look
15:47 jnthn timotimo: Also unbox_i/unbox_n/unbox_s On P6int/P6num/P6str may be an easy thing (part of repr spesh)
15:49 timotimo which repr opt should i use as inspiration for the unbox stuff?
15:49 jnthn There's not a good place to look for get-y stuff yet I think
15:49 jnthn I mean, look for spesh in src/6model/reprs/
15:50 jnthn But I think bindattr opt in P6opaque may be closest so far
15:52 timotimo would i generate a sp_fastunbox_i/s/n that takes an offset from the object base pointer to the contained integer/num/string object? or something like that?
15:52 jnthn No
15:52 jnthn There's much more general spesh ops for it
15:52 jnthn Already in the oplist
15:53 jnthn sp_get_i         .s w(int64) r(obj) int16 :pure
15:53 jnthn sp_get_n         .s w(num64) r(obj) int16 :pure
15:53 jnthn sp_get_s         .s w(str) r(obj) int16 :pure
15:53 timotimo oh, i see
15:53 jnthn The int16 is a byte offset from the start of the object.
15:53 timotimo fair enough; i can just direct that at the correct slot index thingie?
15:53 timotimo ah, byte offset
15:53 timotimo gotcha
15:53 jnthn Not sure if they're implemented in interp.c yet, but should be easy
15:53 jnthn And yeah, it's byte offset.
15:54 timotimo they are not yet implemented
15:54 jnthn They are designed so that when brrt++ JITs them, it's a gonna be really cheap :D
15:54 timotimo i'll try my best :)
15:54 timotimo and guards should become much cheaper when JIT is in; now they do a trip through the interpreter loop, for example
15:54 jnthn Right
15:55 jnthn I think they'll just want to look like
15:55 jnthn GET_REG(cur_op, o).i64 = *((MVMint64 *)((char *)GET_REG(cur_op, 2) + GET_UI16(cur_op, 4)));
15:56 jnthn bbiab
15:56 timotimo ah, thanks
15:56 timotimo i thought i'd have to do something with REAL_DATA
15:57 jnthn no, that's just for p6opaque
15:58 jnthn &
16:00 timotimo i think the 2 and 4 there want to be 4 and 6
16:00 timotimo hm.
16:00 timotimo nope
16:00 timotimo registers are only 2 bytes
16:38 jnthn right.
16:39 jnthn though GET_REG(cur_op, o).i64 shoulda been GET_REG(cur_op, 0).i64
16:46 timotimo yes
16:46 timotimo i fixed that
16:46 timotimo i get pointer mismatch problems
16:46 timotimo after trying it, i ate with friends and drove to the hackspace
16:47 jnthn lizmat: To give you an idea of the S17 bottleneck for me, I'm at 160s or so when the first S17 test starts, 315s or so when the last one ends.
16:47 lizmat :-(
16:47 jnthn uh, meant that in #perl6
16:48 jnthn Anyway, now you can understand a bit why I'm curious about trying to make tests shorter or parallelize better or something.
17:07 timotimo a missing & was to blame for my troubles
17:08 dalek MoarVM: a2afdb9 | (Timo Paulssen)++ | src/core/interp.c:
17:08 dalek MoarVM: implement sp_get_i/n/s
17:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a2afdb9880
17:09 btyler joined #moarvm
17:10 jnthn (char *)&GET_REG(cur_op, 2)
17:10 jnthn I think more robust would be
17:11 jnthn (char *)(GET_REG(cur_op, 2).o)
17:11 timotimo ah, sounds good
17:11 jnthn The other way might run us into trouble on 32-bit BE machines...
17:11 jnthn hm, maybe not
17:12 jnthn But still...something makes me think it'll be fragile
17:12 timotimo mhh
17:12 jnthn Otherwise look fine
17:12 timotimo how should i best write down the offset into the code? for p6int, p6num, p6str it's basically the size of the header, right?
17:12 timotimo so sizeof(MVMObject)?
17:13 jnthn offsetof
17:13 timotimo wow, that exists?
17:14 jnthn C built-in.
17:14 timotimo nice!
17:24 timotimo https://gist.github.com/timo/52be9e43e985845f7201 - is this the correct approach?
17:25 timotimo i don't see any sp_get_i being run
17:25 timotimo during nqp build
17:27 timotimo should probably also have to limit that to only 64bit integers
17:27 timotimo signed
17:28 jnthn yes
17:28 jnthn Bit surprised we don't hit it...
17:29 timotimo all i get for it is getreprname
17:29 tadzik you are 8 bit surprised?
17:29 tadzik (sorry)
17:29 timotimo which i *could* optimize into a const_s :)
17:35 nwc10 Program received signal SIGBUS, Bus error.
17:35 nwc10 (gdb) p &tgt_facts->value
17:35 nwc10 $1 = (union {...} *) 0x14056f2
17:35 nwc10 why are they all misaligned? :-(
17:35 timotimo jnthn: if i am to specialize reprname, where should i look for the literal index for the right string?
17:40 timotimo i suppose i'll build a few speshes for p6opaque
17:40 tadzik today's beer: March Smokes
17:40 tadzik or something
17:40 tadzik Rauchmarzen, actually
17:41 * nwc10 thinks that the problem is that MVM_spesh_alloc() is a very naughty piece of code.
17:46 timotimo isn't it just a bump-the-pointer thingie?
17:46 nwc10 it would seem to be. and I infer that some of the things that it is asked to allocate are 2 * $n bytes long
17:47 nwc10 so the pointers returned after that are not suitably aligned for some of the other things that it is asked to allocate
17:48 nwc10 Sadly the PPC build also explodes. Not sure why
17:48 jnthn nwc10: spesh alloc exists so we can trivially throw away all the nodes in one go at the end, easing memory management of the thng.
17:48 nwc10 2017                    MVMObject *obj  = REPR(type)->allocate(tc, STABLE(type));
17:48 nwc10 type is NULL
17:48 jnthn timotimo: reprname really isn't hot enough to be worth it
17:48 nwc10 jnthn: I think that it needs to take an "alignment" parameter, and on platforms where alighment matters, bump the pointer until alignment is reached
17:49 timotimo jnthn: it seems like the p6opaque spesh function checks that the type_reg has a sknown type and the type is non-null
17:49 jnthn nwc10: If it were to always make sure it was on an 8-byte boundary, would that do it?
17:49 timotimo but optimize_repr_op also checks that and only then will it even call spesh on the repr
17:49 nwc10 jnthn: yes, that would do it, but use more RAM
17:49 nwc10 that is the KISS solution
17:50 nwc10 I think you can also do that alignment conditionally on MVM_CAN_UNALIGNED_NUM64 and MVM_CAN_UNALIGNED_INT64
17:50 nwc10 (they are defined in the inverse sense to be easy here)
17:50 nwc10 whilst MVM_CAN_UNALIGNED_INT32 exists, we aren't actually using it yet. Which is sort of misinformation
17:52 timotimo wtf. why does reprname even get the spesh function called?!
17:53 jnthn uh, yeah...that is odd
17:54 timotimo haha
17:54 timotimo silly me
17:54 timotimo i typo'd in the search box for the ops
17:54 timotimo it actually *is* get_i
17:55 timotimo it gets called quite often for box_i, but not unbox_i it seems
18:00 timotimo unfortunately, box_i isn't as easy to speshify
18:01 timotimo maybe an op like fastcreate + an offset to copy the *thing* to?
18:12 jnthn timotimo: That's my idea for box_i, yeah
18:13 jnthn timotimo: It turns one op into two, but they're two that can JIT nicely
18:13 timotimo an idea why we're hitting box_i often but never unbox_i?
18:15 timotimo optimize.c does hit unbox_i a few times, mabye the type is never known?
18:15 jnthn Well, partly because we always know the type in box_i
18:15 timotimo yes, we do
18:21 timotimo i'll stash the box_i stuff away for now and maybe look for something else to do
18:21 timotimo like can_s
18:23 timotimo oh, objprimspec seems speshable, no?
18:24 timotimo hm, but probably not hot
18:59 timotimo oh dang, now i'm getting All positional args must appear first
18:59 timotimo my can is probably wrong then :)
19:04 nwc10 jnthn: is the memory allocated by MVM_spesh_alloc transient? ie does it get thrown away (en masse) fairly soon after it's allocated?
19:05 jnthn nwc10: Typically yes
19:05 jnthn nwc10: Code has to get hot enough to spesh
19:05 jnthn nwc10: Once it does we allocate the graph and insert logging instructions
19:05 dalek MoarVM: facf41a | (Timo Paulssen)++ | src/6model/6model. (2 files):
19:05 dalek MoarVM: can_method_cache_only function for spesh purposes
19:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/facf41aa19
19:05 dalek MoarVM: 8bce6b2 | (Timo Paulssen)++ | src/spesh/facts. (2 files):
19:05 dalek MoarVM: harvest strings in facts discovery process
19:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8bce6b2a36
19:06 jnthn nwc10: Then a few runs later, we examine the recordings, make optimized bytecode, and throw the graph away (freeing the spesh_alloc'd memory)
19:06 timotimo https://gist.github.com/timo/716656be19b892dda8ab - jnthn, can you tell what's wrong with this?
19:11 jnthn you did it wrong!
19:11 * jnthn looks :)
19:13 jnthn ins->operands[0].lit_i64    = can_result;
19:13 jnthn 1?
19:13 timotimo but that's supposed to be the result?
19:13 jnthn 0 is the result reg
19:13 jnthn 1 is the constant to put in there
19:13 timotimo oh!
19:13 timotimo durrrr :)
19:13 timotimo i should be setting that on the facts instead
19:13 lizmat .oO( an off by one error )
19:13 timotimo thanks
19:13 jnthn np
19:15 timotimo yes, that does work much better :)
19:15 timotimo i think we can probably emit can instead of can_s in a bunch of cases
19:15 timotimo we probably have many const_s + can_s
19:15 timotimo which could be can instead
19:21 timotimo now doing a spesh log with the setting >:)
19:25 jnthn 1.5 million lines coming your way! :P
19:25 timotimo :)
19:25 timotimo 4149871 ../rakudo/test.txt
19:26 timotimo i should probably not run that through a perl6 script to pick it apart %)
19:26 timotimo r-m needs to get faster >_>
19:26 nwc10 this is a "faster" bootstrapping problem? :-)
19:26 timotimo heh.
19:26 timotimo nah, looking at that is optional
19:27 timotimo the script got a whole bunch faster when i put the when clause for the most common type of line first instead of last
19:35 * jnthn puts aside vacation plotting for a bit to see if he can do the rest of this SC quadratic elimination work...
19:36 nwc10 vacation plotting is some sort of Computer Science thing? Or where you surprise your friends by randomly visiting?
19:36 nwc10 and killing the quadratic would be awesome
19:37 jnthn Neither. Plotting to take myself to some faraway place with ice or lava or other awesome :)
19:39 timotimo my time estimate is 10 minutes for those lines
19:41 timotimo hm. the eta seems to be decreasing too slowly
20:00 timotimo Failed to open pipe: 12
20:00 timotimo nnnnooooooooo :(
20:01 timotimo and the estimate was off by about 2x
20:03 timotimo well, at least i talready wrote out the files :)
20:04 timotimo oh, it didn't
20:04 timotimo what a surprise >_<
20:04 timotimo this script ought to learn to be more robust.
20:06 timotimo want to have spurtasync for moarvm please :)
20:14 timotimo (no rush)
20:21 nwc10 jnthn: http://paste.scsys.co.uk/371471 -- running with this on the Pi and so far so good (NQP passes all tests)
20:22 jnthn nice :)
20:24 nwc10 jnthn: http://paste.scsys.co.uk/371476 -- 32074aa0566e breaks ppc64 -- First pass at turning some logs into fact+guard.
20:25 nwc10 big backtrace, starting This representation (VMArray) does not support attribute storage
20:26 dalek MoarVM: 1a224d3 | (Timo Paulssen)++ | src/spesh/optimize.c:
20:26 dalek MoarVM: spesh can and can_s ops into const_i64
20:26 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1a224d30a0
20:26 dalek MoarVM: 516207f | (Timo Paulssen)++ | tools/spesh_diff.p6:
20:26 dalek MoarVM: estimate run time of spesh_diff
20:26 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/516207fcf0
20:26 dalek MoarVM: 8efcab4 | (Timo Paulssen)++ | tools/spesh_diff.p6:
20:26 dalek MoarVM: write out results ASAP.
20:26 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8efcab426a
20:27 nwc10 jnthn: I'm having trouble working out why
20:27 jnthn nwc10: Also, that commit was done in a branch that broke stuff along the way
20:27 timotimo jnthn: are our parsing bytecode stuffs benefitting at all from spesh so far?
20:27 nwc10 jnthn: OK.
20:27 nwc10 that does make it hard to bisect
20:27 jnthn nwc10: That is, not all commits worked well here either.
20:28 jnthn Yeah...such is bisect and branches.
20:31 nwc10 OK, so at bed169375f087dfb11939110fa18921536b1a2a7 -- Be more careful over concreteness in facts.
20:31 nwc10 which I think was master at one point
20:31 nwc10 PPC64 is bust
20:31 nwc10 P6opaque: no such attribute '$!ast'
20:32 nwc10 spesh writes bytecode, which is then passed to the validator?
20:32 jnthn No
20:32 jnthn spesh bytecode is assumed valid
20:32 jnthn But it doesn't endian-transform as it writes.
20:32 jnthn So the bytecode itself should be native endian.
20:32 nwc10 OK, something else weird then
20:33 jnthn Darn
20:33 nwc10 you could say that
20:33 timotimo Failed to open pipe: 12
20:33 timotimo in sub QX at src/gen/m-CORE.setting:779
20:33 timotimo wow, that is helpful.
20:34 jnthn Also darn here. Got opt in, but it generates a busted setting :/
20:42 timotimo -      can_s r8(1), r6(1), r7(1)
20:42 timotimo -      unless_i r8(1), BB(3)
20:42 timotimo -    Successors: 3, 2
20:42 timotimo +      const_i64 r8(1), liti64(1)
20:42 timotimo +    Successors: 2
20:42 timotimo yays :)
20:43 timotimo it doesn't seem like i've decremented the usages of the constant when i turn the if into an unconditional jump
20:43 jnthn Was gonna say, why ain't it just gone...
20:44 jnthn Also, did it not remove the thing setting r7(1) to a const string?
20:45 jnthn OK, it seems it's a minor part of my opt that is bad.
20:45 jnthn The overall thing seems to help.
20:46 jnthn Gets rid of much of the quadratic.
20:46 jnthn Stage mast goes from ~20s to ~13s here
20:46 lizmat wow!
20:48 jnthn Clean build of NQP came out OK
20:48 jnthn Rakudo in progress
20:48 jnthn Then a spectest
20:48 jnthn In theory I can get us a bit more too
20:48 jnthn But that'll take more debuggering the bits of my patch that cause some kind of explosion...
20:49 jnthn Anyway, 10s off NQP build and 8s or so (parse/optimize are a little faster too) this weekend, it seems :)
20:57 dalek MoarVM: bc1677d | jnthn++ | src/ (9 files):
20:57 dalek MoarVM: Change the way we store SCs in object headers.
20:57 dalek MoarVM:
20:57 dalek MoarVM: We used to store a pointer directly to the SC. Now we store a pair
20:57 dalek MoarVM: of 32-bit integers: an index into a new array where we can look up
20:57 dalek MoarVM: the SC, and the index the object lives at in the SC, if known. This
20:57 dalek MoarVM: second index is not being set up everywhere consistently yet; this
20:57 dalek MoarVM: patch does what's needed to switch over to the new header layout
20:57 dalek MoarVM: and be able to build NQP/Rakudo.
20:58 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bc1677d60b
20:58 dalek MoarVM: 375f5d7 | jnthn++ | src/6model/sc.c:
20:58 dalek MoarVM: Use SC index from object header when available.
20:58 dalek MoarVM:
20:58 dalek MoarVM: Falls back to the linear search for cases that don't (yet) have the
20:58 dalek MoarVM: index stashed. However, it is in the common cases, which makes the
20:58 dalek MoarVM: CORE.setting compilation complete in 90% of the time it used to.
20:58 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/375f5d7ff6
21:00 timotimo aaaw only 10% improvement? :(
21:00 timotimo does that improvement only happen in stage mast?
21:00 timotimo or is it spread all over?
21:00 jnthn 10% improvement to the entire setting compilation
21:00 jnthn Stage mast is just one part of it
21:01 jnthn There it's working in 65% of the time it used to
21:02 timotimo that's definitely very good!
21:02 timotimo well, the biggest win is that the quadratic factor is now ... linear?
21:02 jnthn Right
21:02 timotimo so as we implement more stuff, the win will become bigger
21:03 jnthn Now I need to pick through my patches that didn't make the cut and work out which of the small tweaks to avoid linear search in a few more places bust stuff
21:03 timotimo :)
21:04 timotimo here's a const_s that's not disappearing properly :(
21:08 timotimo haha, i'm silly
21:13 dalek MoarVM: 1ec728b | (Timo Paulssen)++ | src/spesh/optimize.c:
21:13 dalek MoarVM: no need to keep the flag alive when removing iffy
21:13 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1ec728bb06
21:13 dalek MoarVM: 5689569 | (Timo Paulssen)++ | src/spesh/optimize.c:
21:13 dalek MoarVM: check opcode before losing it in optimize_can_op
21:13 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5689569c3c
21:14 dalek MoarVM: 4785424 | jnthn++ | src/6model/serialization.c:
21:14 dalek MoarVM: Mark objects/stables with index in deserialize.
21:14 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4785424137
21:18 timotimo scrolling through the spesh stuff i see a few funny constructions with sets cascading and stuff
21:18 timotimo but that's probably not a very big win to work with that
21:22 jnthn Yeah, in the C profile, serialize is way down now
21:23 timotimo awesome :)
21:27 timotimo removing even a single BB early on in a frame that has many blocks causes the diff to become huge and noisy :(
21:30 raiph joined #moarvm
21:30 * jnthn suspects that, with some care, we can optimize many "for" loops in NQP to avoid invocations.
21:31 jnthn Which'd probably also cut down on a lot of the takeclosure operations
21:31 timotimo oooh
21:31 jnthn GC in CORE.setting compilation is 20%, which is a bit higher than the typical profile I see.
21:31 timotimo at what level will that optimization reside?
21:32 jnthn NQP's optimizer
21:32 jnthn We already do most of the analysis needed for it, I *think*.
21:32 timotimo that would probably be pretty awesome
21:32 jnthn It's a bit messy to implement, but probably not too bad.
21:33 jnthn Also will make the iterator object open to escape analysis, when we eventually have it...
21:33 timotimo it'll probably put quite a bit of distance between rakudo and nqp in the benchmarks again ;)
21:34 jnthn Aye, though Rakudo got a bit better this weekend also... :)
21:34 jnthn 15%-20% off the array store benchmark, for example
21:35 timotimo concrete and null are orthogonal, aye?
21:35 timotimo were you able to figure out why the spectests suffered so heavily? just a case of not doing the same thing often enough for the spesh to pay off?
21:39 timotimo i think i'll start a benchmark run
21:41 timotimo jnthn: anything in particular i could try to look at for making our parsing stuff faster through spesh?
21:47 jnthn Well, getattribute in p6opaque, but it's really subtle and fiddly because of autoviv stuff
21:48 timotimo mhh
21:48 jnthn Yes, a benchmark run would be good.
21:48 timotimo already in the timing phase :)
21:53 timotimo ah, i probably ought to bench nqp, too
21:56 jnthn :)
21:56 jnthn Gotta teach tomorrow, so probably shouldn't stay up too late :)
21:56 jnthn 'night
21:56 timotimo aaw
21:57 timotimo so long and thanks for all the spesh :)
21:59 lizmat gnight jnthn
22:10 timotimo doing the benchmarks for nqp-m now
22:10 timotimo oh. actually, i'm still using --optimize=1 for the benchmark'd moars
22:32 timotimo Internal error: inconsistent bind result
22:32 timotimo without spesh it doesn't occur
22:32 timotimo this is in the forest fire benchmark
22:33 timotimo also the forest fire results don't seem right
22:33 timotimo it's wrong in perl6-p, too, though
23:01 hoelzro alright, I've finally answered the summons
23:01 hoelzro unfortunately, I never made a lot of headway on that SMO thing =/

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