01:32 FROGGS_ joined
sergot morning o/ 06:12
06:47 FROGGS joined 07:06 zakharyas joined
jnthn o/ 08:57
09:04 moritz joined
timotimo morning 09:17
moritz moarning 09:19
09:27 lizmat joined
jnthn moaning 09:28
09:29 nebuchad` joined 10:08 FROGGS joined
timotimo did brrt say he'd have a 4-day-weekend? 10:20
jnthn Not that I remember. Well, he was about here on Friday at least. :) 10:22
11:28 brrt joined
brrt \o 11:28
jnthn o/ brrt 11:30
brrt wow, timotimo++ 's been busy
do you happen to know if pop_o and pop_s etc... are invokish? 11:31
jnthn No, they're not 11:32
REPR ops can never invoke
brrt ok, awesome
jnthn That's a 6model design rule for a long time :)
(Which serves us nicely :)) 11:33
brrt yes, it does, certainly here 11:34
brrt is trying to renember which ops were in fact invokish
smrt_*ify at least
jnthn if_o, unless_o, smrt_*, istrue, isfalse, decont, assign, assignunchecked 11:36
brrt only these?
jnthn Well, those stand out to me glacning oplist 11:37
*but*
A bunch of ops can also throw exceptions.
timotimo brrt: i've got beginnings of a getattr_s patch, but i don't have a way to express "pass the nth literal string from the current compunit's literal table"
it'd be nice if i could just dereference the address of that string at jit time, because i *think* that table cannot move
brrt hmm
jnthn And exceptions will need some pondering. 11:38
brrt /if/ it cannot move, you can just pass the pointer in a literal
otherwise, i might need / want to add options to callarg
brrt nods wrt to exceptions
timotimo how do i properly pass that pointer?
when i said i'd just use the litearl int64 argument type, diakopter warned that some architectures have different sized pointers 11:39
brrt i think the callarg structure is a union of { ptr, num64, int64 }
timotimo so it'd be good if the jit had a way to differentiate numbers from addresses on that stage
brrt true
it hasn't a pointer value in there, if you like you can just add a void * in the struct 11:40
the emitter will handle eventual differences
hmm wait, i may have a better idea
jnthn shop/lunch; bbiab 11:42
timotimo preparing for departure first 11:43
brrt: do you want my patch so you can massage it into a workable state?
in my newest assessment, ifnonnull turned up as the second most bail-causing op, following getattr_s 11:44
we'll probably see an "explosion of diversity" once those two are done :)
which may be a good thing ("we attempt to compile a whole bunch more diverse frames!") or a bad thing ("oh no, look at all these low-worth ops we'll have to take care of!")
oh, btw, it'd be fantastic for logging purposes if the "call a C function" nodes could be annotated with the original opcode and if that could be printed in the log 11:45
so that we can get proper "emitted opcodes" statistics from the log
brrt agrees 11:46
timotimo and rather than using a perl6 script, i suggest the use of grep "emit" | sort | uniq -c | sort -n
brrt oh, you can send a patch, yes
brrt had considered that, too :-)
timotimo gist.github.com/timo/84d595f301354393bdc0 11:47
it'd probably also be nice to merge master into moar-jit again, as we've recently got some decont -> sp_p6oget_o transformations in spesh done 11:49
i've been running a non-pushed merge of master into moar-jit locally and it still builds rakudo fine at least
AFK now :)
brrt ok, will do :-) thanks a lot 11:50
bbiab 12:03
12:09 zakharyas joined 12:28 jnap joined 13:32 carlin joined
timotimo brrt, i'd also be interested in a before/after master-merge comparison of decont bails 13:37
or rather: decont count in general
(for setting compilation or something like that)
13:42 brrt joined
brrt that's a prety good idea, yes 13:44
dalek arVM/moar-jit: 83a6629 | (Bart Wiegmans)++ | src/jit/ (4 files):
Add pointer values as literals in call args
 14:14
arVM/moar-jit: 4d50b38 | (Bart Wiegmans)++ | src/ (7 files):
Add support for getattr_s

Based on timotimo++'s patch. Also added direct support for calling args with the a string based on the string index.
timotimo yay 14:20
14:30 colomon joined 14:40 woolfy left 14:41 woolfy joined
brrt :-) 15:06
timotimo for the weekly it would be fantastic to have an updated bail log for the core setting :\ 15:33
i suppose i'll have an outlet on the train and can compile and run stuff there no-problem
new most-bailing op: flattenropes 15:40
followed by ifnonnull, which i'm hoping brrt can implement very soon :) 15:41
dalek arVM/strref: f6b3ea8 | jnthn++ | src/strings/ops.c:
Fix variable names in asserts.
 15:49
arVM/strref: c4cfd75 | jnthn++ | src/strings/ops.c:
Toss debug code.
 15:50
timotimo how did that even build? :) 15:57
should i point out that the string refactor branch still breaks at least one benchmark?
or are you about to fix that? 15:58
nwc10 on jnthn.net/perl6/bench/2014-07-13.html some of those HEAD benchmarks seem to be within a factor of 8 or even 4 of Perl 5
timotimo nwc10: wasn't that only the microbenchmarks, though? 15:59
nwc10 possi bly
jnthn There's some where we even beat Perl 5... 16:00
nwc10 I'm not aware, I'm on a poor connection (and I've closed the page) and $more excuses
yes, I forgot to say. Some are already ahead
need some concurrency benchmarks :-)
We have a very dirty floor, thanks to 2 dogs, and so some concurenncy benchmarks would be very useful :-) 16:01
[maybe too subtle]
16:01 klaas-janstol joined
timotimo nwc10: you want to wipe the floor with perl5? :) 16:04
nwc10 aye.
timotimo sufficiently unsubtle :)
nwc10 more, I want the floor wiped. And I'd prefer an automated solution. 16:05
[Coke] nwc10++ for coming to the dark side.
nwc10 I'm playing both sides. :-)
timotimo :D 16:06
japhb_ I can't wait to see the benchmarks after strref merges. And my perl6-bench fixes from last night should cut out a lot of the noise in the data, too. 16:07
timotimo japhb_: er .. you're seeing the benchmarks after the strref merges there :) 16:08
japhb_ nwc10: I welcome a moving target for perl5 performance, as long as it's moving in the "faster" direction. :-) 16:09
timotimo: His stuff was from the branch, not after the merge. I've got a bunch of versions timed, so I want to be able to add the merged results into my histories and see how it looks. 16:10
jnthn Still need to decide whether to merge strref before or after 2014.07 release... 16:11
japhb_ Certainly after perl6-bench fixes, the history shows a much more reasonable improvement curve.
timotimo ah, of course.
jnthn I don't want a bunch of module regressions blocking a *
timotimo japhb_: is there a good explanation for why the lines on the left are exactly the same steepness?
japhb_ jnthn: if it can pass the spectests and the benchmarks, I'd love to be able to merge it. The improvements for end users will be huge.
Yeah, agreed about module regressions. :-( 16:12
jnthn japhb_: Well, release is on Thu
So it's not a long wait
japhb_ timotimo: explain?
jnthn: I meant I'd rather not have the users stuck waiting for mid-late August. 16:13
(Those of us actually working on it are probably all running a current build) 16:14
timotimo: Before my fixes last night, it was relatively common to have a couple of compilers whose run times on the left side of the graph were in the noise, and being pinned to the minimum run time (after subtracting startup/compile time). Thus when calculating rates, they ended up colinear. That's part of what I was trying to fix. 16:16
It should be much rarer now to see that. More likely you'll see plot lines missing the left end, or having fewer data points on the left end.
Damn plugged ears. Sudafed is NOT DOING ITS JOB. :-/ 16:18
timotimo ah, pinned to the minimum run time, that'd explain why they look the same
japhb_ timotimo: The initial version of the code was trying to avoid divide-by-zero. The current version is attempting to avoid lies. 16:19
timotimo that's an improvement
i still kind of wish our html output had a way to make all graphs have the same scale
japhb_ It can probably still be tuned a bit, but I wanted to see how other people's benchmarks looked before tuning further.
16:19 nebuchadnezzar joined
timotimo but i suppose our history comparison view is going to be much less problematic 16:20
japhb_ Some of the tests have VASTLY different scales.
Yes, history should help that a lot.
timotimo that's true :\
japhb_ Bus stop coming soon, bbiab.
timotimo in about 15 minutes i'll reach the next train station, too
so ... what do i do until then? :)
i think flattenropes looks like a quite simple thing to do 16:21
dalek arVM/moar-jit: ce5cf76 | (Timo Paulssen)++ | src/jit/graph.c:
implement flattenropes in the JIT.

pretty much every bail that was flattenropes is now a bail caused by graphs_s ...		 16:29
timotimo jnthn: if the implementation of s_graphs is GET_REG(...).s->body.graphs, i should be able to turn it into a p6oget_s with offsetof( MVMString, body.graphs ), right? 16:31
jnthn timotimo: hmm 16:34
But that's changed in strref...
But yeah, that appraoch would work
It's called num_graphs now :)
japhb_ BTW jnthn, I'd like to see what the current version of perl6-bench run on Windows produces for plots ... I'm curious whether the tuning I did for my system (fast linux workstation) does the right thing on a Windows laptop as well. 16:37
Also, if any of your Windows fixes for perl6-bench are immediately commitable, please do -- I'd like to keep the "hand-managed" part minimized, for any other Windows users who might be interested. 16:38
16:45 brrt joined
kjs2 Hello all. Quick question - just cloned moarvm, trying to compile, but getting this error: src/moar.h:20:10: fatal error: 'uv.h' file not found 16:50
#include <uv.h>
perl Configure.pl completed successfully, Mac OSX platform. Just wondering if itā€™s just me. 16:51
ā€¦ but compilation of the latest release (2014.06) worked well. 16:54
japhb_ kjs2: Have you run Configure? 16:56
kjs2 japhb_: Yes, success
brrt that's... odd
japhb_ (I'm guessing you don't have the git submodules checked out)
brrt Configure.pl ought to do that
kjs2 thatā€™s what confused me. As said, when just ā€œdownloadā€ing the latest release, it works well
brrt maybe run it again?
kjs2 i took the latest version from github. Maybe I should jsut stick with releases :-) 16:57
brrt i'm checking if the latest checkout of master Just Works as it ought to 16:58
ok, i'm waiting a pretty long time for 'Updating submodules' 16:59
timotimo kjs2: did you get it from the "releases" tab?
brrt but, i'm getting them after all
kjs2 timotimo: I downloaded the .zip file on github 17:00
timotimo yes
that's wrong
kjs2 that one failed (complaining about no uv.h)
timotimo i think we don't know how to turn that feature off
kjs2 but I realized it was easier for me to download it from moarvm.org
timotimo those are proper
kjs2 and that one works.
timotimo my seat is b0rken ;(
ah, just misconfigured 17:01
running Configure.pl again fixed it
17:41 brrt joined 17:43 brrt left, brrt joined 18:21 FROGGS joined 18:25 teodozjan joined
nwc10 jnthn: *only* spectest difference from MoarVM master appears to be t/spec/S16-filehandles/io.t 18:29
ok 81 - the bytes decode into the right Str
vs on branch
not ok 81 - the bytes decode into the right Str 18:30
# got: 'f??'
# expected: 'fƶƶ'
timotimo oops
nwc10 yes. needs more cowbell, er metal dots
18:32 carlin joined
timotimo p6oget_i isn't the right op at all to handle MVMString struct access, because it's for p6o's and not for MVMStrings %) 18:34
silly me
but using sp_get_i gives me trouble 18:35
but i did remove the offsetof MVMObjectStooge, data
[Coke] integration/99problems-51-to-60.t aborted 13 test(s)
timotimo remove the subtraction
nwc10 jnthn++ # pretty bloody good
timotimo i can only reach the Internet from my phone now 18:36
dalek arVM/moar-jit: a798a17 | (Bart Wiegmans)++ | src/jit/emit_x64.dasc:
Remove debug instruction
timotimo otherwise I would upload a patch
brrt! \o/ 18:37
brrt :-) that was a really simple patch
[Coke] started failing Mon Jul 7 18:33:12 2014
timotimo it's amazing how good networkmanager has gotten. 18:38
gist.github.com/timo/9369c4f53eecd40d60b4 - ideas? 18:39
brrt almost wanted to turn timotimo's appraisal of current networkmanager into cynical terms 18:40
timotimo how so?
i plugged in my UMTS stick, "edit connections" "new connection" "mobile broadband" "germany" "vodafone" "default" done 18:41
i plug in my phone, select "usb tethering" and five secodns later it's already connected and working
brrt i agrees
the cynical terms were about how bad it used to be
timotimo except now i'm inside a tunnel
and the connection has no right of working
why am i connected? o_O 18:42
maybe this tunnel has an antenna put into its roof or something
brrt that happens these days
what i'm very happy about is the large-font support on gnome these days 18:43
timotimo - you're trying to optimise graphs_s for spesh so it'll be jitted?
you can do that, but it seems better imho to add an 'accessor node' to the jit
that is to say, i don't expect a speed benefit by emitting a sp_p6oget_i or anything like that for an op like graphs_s, codes_s, etc 18:44
better to have the JIT say 'here's how to make a node that copies N bytes from the object pointed at in this or that register' etc 18:45
also note that sp_p6oget_ ops assume p6opaque structs, which have a perhaps little-known feature (namely, field indirection); the 'data' vector (which would normally be adjacant to the header) can be 'replaced' and be redirected 18:46
timotimo left the tunnel and the reception goes to hell 18:48
wtf %)
well, i did notice the thing about p6o_ ops
and the indirection
because it segfaulted in get_real_data :)
with "big font" you mean "HiDPI", right?
brrt no, i mean the little 'accessibility' button 18:49
timotimo it's fine to create a jit node for accessors
18:49 carlin joined
brrt had expected as much 18:49
just that some accessors are conditional (of the type foo ? foo : bar, or something like that) 18:50
timotimo i want multipath TCP now
brrt i'll get to that
time to fix networkmanager then :-p
timotimo i have to switch between vodafone and eplus every few minutes
i didn't implement a node for the jit because i have no idea how to work dasm
are you going to build ifnonnull soon? :3 18:51
brrt ehm... i /think/ jnthn said ifnonnull was invokish 18:52
and i'm working on the frame register refactor, which is kind of a prelude to the invokish ops
and, i'll be blogging about how to use dasm really soon :-) 18:53
timotimo ifnonnull is not invokish 18:54
it checks if the object pointer is a null pointer and if not if it's == VMNull
need to detrain in a few, then somehow get to the hackspace and get a jacket ...
ttyl :) 18:55
brrt oh, if that's so, i can do it swiftly 18:57
jnthn nwc10: Thanks. I can reproduce that one here. 19:00
nwc10 t/spec/S22-package-format/local.t fails on master in the same way.
jnthn timotimo: I think sp_get_i doesn't want th eheader subtracting, fwiw. 19:01
brrt: It's if_o and unless_o and istrue and isfalse that are the boolean-invokeys. 19:03
nwc10: Yeah, lizmat++ is actively hacking in that area, so guess it's some churn from that.
brrt: BTW, it occurs to me that we might want to mark ops as :invokey and :throwy in oplist and programatically deal with the issue 19:12
brrt concurs
throwy can jump arround frames too? 19:13
jnthn I've added various such things in the past; just git log update_ops.p6
brrt i see
jnthn Depends what you mean by "jump around frames" 19:14
In many ways it's worse than invokey
'cus it can jump within a frame also
FROGGS .oO( I've added various such things in the qast... )
dalek arVM/moar-jit: fe1315b | (Bart Wiegmans)++ | src/jit/emit_ (3 files):
Moved frame variable to callee-save register

The frame variable is accessed often, so it is a good candidate for a callee-save register (as this saves loads whenever it is used). Moreover, in invokish operators this will allow us to compare the cur_frame with the jit_frame so as to check if they really invoked.		 19:27
brrt hmm i see
basically, that's what handlers are for, aren't they? 19:28
offsets into the bytecode stream
jnthn yeah
I expect spesh will be able to turn *some* local handlers in a frame into gotos...
But don't know that we want to rely on that. 19:29
One good news is that handlers always are new basic block starts... )
brrt that is good news 19:30
basic block starts are always labels in the JIT 19:31
(not sure how it could be otherwise, by definition of the idea 'basic block')
which means that if you know the handler the JIT knows the label and you /can/ translate it into goto's
of a sort
(and if you can lookup the handler at runtime, better yet!)
dalek arVM/moar-jit: bc4bb42 | jnthn++ | src/spesh/facts. (2 files):
Cope with cross-deopt-point usage analysis.

If a register gets used after a deopt point, give its usage an extra bump. This means we won't kill a write to it when doing dead code 0e15cb6 | (Bart Wiegmans)++ | src/ (6 files): Added frame ArgProcContext as C call interp var
This should fix checkarity, which it seems never worked because op_to_func return the function pointer to the regular non-jit version.		 19:35
brrt (please dalek, it's a merge)
19:36 dalek joined
timotimo jnthn: i already removed the header subtraction from sp_get_i 19:44
jnthn timotimo: Did that fix it? 19:46
timotimo no 19:47
Unable to parse expression in method_def; couldn't find final ')' at line 16, near ") {\n "
ah, brrt merged master, good. 19:53
brrt rakudo built fast :-o
i mean, what's a good time for stage mast to build these days? 19:54
jnthn Lowest I've seen is around the 13s mark
brrt well, i've just hit 13.377 19:55
(a number which i'm not kidding about in the least)
timotimo cute :)
brrt i suppose the spesh helped
timotimo it would be nice if it did 19:56
btw, only graphs_s and codes_s are amendable to being turned into an access node
lizmat jnthn, nwc10: wrt to S22 errors: they only happen when run under make, not when just executing with "perl6"
brrt afaik, there are more :-), it's just that most of these tend to be access from the compunit or threadcontext or similar 19:57
lizmat it appears that trying to execute perll6-m in a shell (which is what the S22 when running under make does)
gives the error: Unhandled exception: failed to load library 'dynext/libperl6_ops_moar.dylib' 19:58
at <unknown>:1 (/Users/liz/Github/rakudo.moar/perl6.moarvm::303)
timotimo so it's not that useful to build a very generalised solution
brrt not yet, i agree 19:59
jnthn elems on a VMArray and VMHash also can happen that way
Though I think they already spesh to sp_get_i
timotimo ah, but only if they are nqp::list_i, right?
i don't think we have nqp::hash_i at all 20:00
brrt the advantage of 'access nodes' - eventually - is that you can do common-subexpression-elimination for them, and compile code that has fewer loads
timotimo i'm looking forward to eliminating repeated boxing/unboxing with escape analysis
like $foo++ will turn into an inc instruction even if $foo is a container'd thingie 20:01
well, that doesn't sound like a good idea, as boxed ints are immutable
but if we just new'd that int, we can fuddle around with that ... actually we can delay the new-ing until after the calculations
forget what i said
brrt hmm... smallish issue 20:14
can we call GC_SYNC_POINT /before/ branching away? 20:15
would that make a lot of difference?
jnthn Can you get a little more specific? 20:16
Like, is there soemthing in interp.c you're looking at?
timotimo we don't have to call gc_sync_point
unless we have an infinite loop that allocates
jnthn wonders if brrt is talking about this:
OP(goto):
cur_op = bytecode_start + GET_UI32(cur_op, 0);
GC_SYNC_POINT(tc);
goto NEXT;
brrt for example, yes
jnthn In which case no, it's not significant that we set cur_op before we call GC_SYNC_POINT 20:17
brrt why
:-)
jnthn You could swap the two around.
e.g. it could also be
OP(goto):
GC_SYNC_POINT(tc);
cur_op = bytecode_start + GET_UI32(cur_op, 0);
goto NEXT; 20:18
And work just as well.
The GC doesn't actually use the program counter
timotimo gc_sync_point is "this is probably a good spot to see if other threads have decided to gc"
iirc
brrt oh, i read 'it's not /in/significant', which is why i'd expect a dramatic conclusion
jnthn oh :)
brrt ok, then i'll move it to the front
jnthn Yeah, that'd kinda make it weird :)
brrt because otherwise i'll have to JIT a weird dispatch thing arround it 20:19
jnthn Anyway, timotimo was right about the point of it: making sure non-allocating tight loops don't go wild.
And prevent other threads GCing.
If you wanted to further optimize it, you could only emit it on backbranches.
timotimo right, we rely on another thread being marked as "blocked" or reaching a gc sync point soon enough 20:20
but we can't pretend a piece of jitted code "blocks" a thread except if it is absolutely certain that it won't allocate
jnthn (Since no backbranch = no loop)
timotimo and then it must not leave the jitted code without checking for simultaneous gc runs
jnthn puts aside $dayjob-stuff for the day 20:21
...and wanted to take a stroll but...rain. :(
brrt what are umbrella's for :-) 20:22
brrt ponders the backbranch stuff... i'm not sure i can guarantee that bb's are numbered in a linear-consecutive fashion, or in other words, i can't prove bb's from a loop yet
hmm
what would be the sizeof of A0_t in x64
jnthn 64 bits 20:24
brrt indeed :-) that's good news for me 20:25
jnthn Where do you find the AO_t, ooc?
timotimo is that related to atomicness with regards to certain operations?
brrt gc_status
jnthn yeah
Ah...
brrt tc->gc_status is A0_t
jnthn Right
brrt which means i must cmp it but know the size
jnthn GC_SYNC_POINT does not, thankfully, look at it atomically :) 20:26
timotimo aye, it's okay to accidentally miss a beat 20:27
brrt thankfully, indeed 20:32
hmm... that's weird 20:35
if i add ifnonnull as an op, i get lots of 'use of unitiialized value of type Nil in numeric context' errors
timotimo in that case your ifnonnull is the wrong way around :) 20:38
brrt that could well be
timotimo :) 20:41
arVM/moar-jit: d23c9a0 | (Bart Wiegmans)++ | src/jit/ (4 files):
Add support for ifnonnull

This also adds the GC_SYNC_POINT to branches
brrt timotimo++ for telling me what to look for
jnthn ah, the rain stopped :)
bbi10-15 20:47
brrt see you tomorrow! 20:48
20:48 brrt left 20:49 woolfy1 joined
timotimo makes a new bail statistic thingie 20:57
yeah, a whole bunch of graphs_s failures still 21:01
then comes atkey_o and then param_rp_o
but atkey_o should be implementable as a simple function now 21:03
will we never ever support may-invoke-opcodes in the jit? 21:06
well, would you look at that 21:08
decont is back on the top spot
followed by graphs_s by about 15 bails
jnthn timotimo: Oh, we'll certainly support may-invoke; brrt++ and I have been discussing that :) 21:12
timotimo cool
otherwise we'll never be able to tackle decont :)
actually ... how come we don't have guarded almost all deconts with a "the type of container has always been the same"? 21:13
since the only container we cannot turn into a p6oget_o is the code-based one and i don't think it's used that often ... ? 21:16
jnthn Dunno. There must be places we're not sure; in may cases, perhaps we can be more sure :) 21:17
May be worth checking if box_i and friends introduce "known not a container" things in facts.c for example 21:18
Otherwise I'd just look at spesh log and see if remaining deconts come in some kind of pattern.
m: say "fƶƶ".encode("ISO-8859-1").perl 21:22
camelia rakudo-moar b25b86: OUTPUTĀ«Blob[uint8].new(102, 246, 246)ā¤Ā»
timotimo create_facts is responsible for box_i and friends, it checks the type for known_value (is that right? wouldn't known_type be enough?) and if it's got a null container_spec and then sets FACT_DECONTED 21:24
jnthn Well, the type almost always is suppleid as a wval 21:25
But yeah, technically known_type is enough. Not sure if it'll nail many more cases, but quite possibly
timotimo OK, i'll add a printf in that branch 21:27
dalek arVM/strref: bab734b | jnthn++ | src/strings/latin1.c:
Fix copy-pasto when updating latin-1 encoding.
jnthn There's the one nwc10++ reported
timotimo in the first piece of the function we check the type for known_type, in the second piece we check for known_value 21:28
21:28 japhb joined
timotimo interesting. 21:28
that triggers really often 21:29
jnthn Whcih "that"? :)
timotimo both branches are hit, actually
jnthn Are there cases where type is and value ain't? 21:30
timotimo let me see.
er. yes. 21:31
type is known, value is not known
surprisingly a bunch of times
jnthn darn, it's used for create too
That's a big missed opportunity
Yeah, type is enough. 21:32
I think it mighta been copy-pasto from object_facts
timotimo i'll change that, in that case.
could be, yeah
jnthn Where exactly value is known.
timotimo gimme a sec.
jnthn thx
timotimo building now and seeing if the bail log is better 21:34
jnthn oh, good news
You know parse-json failed horribly?
Turns out it was nothing to do with strref
timotimo oh! 21:35
yays :)
still got a whole bunch of deconts in there. huh. 21:36
jnthn Was that my perl6-bench was old enough to have eval
timotimo :D
excellent 21:37
jnthn I'm pondering whether to merge now and bump revisions to get feedback from the ecosystem
If we see anything I can always easily back it out.
That's what version control is for, after all.
timotimo aye, i'd like that :) 21:39
a lot, actually
interesting, a bunch of create_fact without a known type. but probably also without a known value in that case. let me check 21:41
ah 21:43
yeah, no case of "unknown type, but known value"
which would have been quite surprising
so that's likely just stuff like "get the type object from an array" or something :)
21:43 japhb joined
jnthn hah... 21:45
Profiled -e "my $s = ' ' x 1000 ~ 'x' x 1000 ~ ' ' x 1000; $s.trim for 1 .. 1000"
94% of the time is spent in MVM_string_gi_move_to :) 21:46
21:46 japhb_ joined
timotimo that's the iterator move function? 21:47
jnthn yeah
timotimo that tries to step over graphemes?
21:47 japhb joined
jnthn /* Sets the position of the iterator. (Can be optimized in many ways in the 21:47
* repetitions and strands branches.) */
timotimo "in the future"?
jnthn you don't say :D
timotimo ah, hehehe.
well, does that still count as a fair benchmark? :)
jnthn oh, the benchmark is great
timotimo if we simply skip over the ' ' x 1000?
oh, that's not what that does 21:48
jnthn It tells me this thing I wondered if I could get away with optimizing now actually really really needs optimizing.
timotimo OK :) 21:49
we could optimize "find_cclass" for repetition rope cases. if it didn't find one in any of the repeated thingies, it'll never find it in any of them
so it could skip to the next ropey bit :) 21:50
in that case our trim benchmark would not even depend on $scale
it'd just be done in constant time :D
oh, you're perhaps expecting me to push my code 21:55
i could totally do that
jnthn m: my $s = ' ' x 1000 ~ 'x' x 1000 ~ ' ' x 1000; say $s.trim.chars 21:57
camelia rakudo-moar b25b86: OUTPUTĀ«1000ā¤Ā»
dalek arVM/moar-jit: 7595b3c | (Timo Paulssen)++ | src/jit/graph.c:
jit can has atkey_o
 21:58
jnthn Rather faster code got 1001. I think I got it wrong. :)
Guess that's what I get for coding without a beer to hand... 21:59
dalek arVM: 802e3a4 | (Timo Paulssen)++ | src/spesh/facts.c:
create_facts in spesh doesn't have a known value, just a known type.
timotimo ^these are acceptable commits, i hope 22:00
jnthn pours a De Molen
diakopter moles a De Pouren 22:08
jnthn timotimo: First one looks OK at first blush 22:09
timotimo blushes
[Coke] m: say Blob[uint8].new(102, 246, 246) 22:10
camelia rakudo-moar b25b86: OUTPUTĀ«Buf:0x<66 f6 f6>ā¤Ā»
timotimo i don't know the significance of that
[Coke] of the pharse "at first blush"?
timotimo no, of the code you pasted :) 22:11
jnthn Second looks fine
[Coke] result of jnthn's .perl a few page ^^
jnthn Yeah; that was busted under strref, but fixed now.
[Coke] m: say Blob[uint8].new(102, 246, 246).decode() 22:12
camelia rakudo-moar b25b86: OUTPUTĀ«Malformed UTF-8 at line 1 col 2ā¤ in method decode at src/gen/m-CORE.setting:5302ā¤ in block at /tmp/hHkgurlWma:1ā¤ā¤Ā»
jnthn Correct; that is indeed invalid UTF-8 :)
[Coke] m: say Blob[uint8].new(102, 246, 246).decode("ISO-8859-1") 22:13
camelia rakudo-moar b25b86: OUTPUTĀ«fƶƶā¤Ā»
timotimo m: say "hello".decode("rot13") 22:14
camelia rakudo-moar b25b86: OUTPUTĀ«No such method 'decode' for invocant of type 'Str'ā¤ in block at /tmp/MhNMCnzK0V:1ā¤ā¤Ā»
timotimo er
m: say "hello".encode("ascii").decode("rot13").encode("ascii")
camelia rakudo-moar b25b86: OUTPUTĀ«Unknown string encoding: 'rot13'ā¤ in method decode at src/gen/m-CORE.setting:5302ā¤ in block at /tmp/DVnpwyL4pK:1ā¤ā¤Ā»
timotimo that's obviously something we will need in the future
[Coke] be nice if we could register new encodings at the language level.
(maybe)
jnthn It's not as easy as it looks, due to decoders especially having to be careful about things dangling over block boundaries when doing I/O. 22:15
timotimo oh ... i remember
jnthn But yeah, in the long run we want that. 22:16
(registering new encodings)
[Coke] seems like we could abstract out the dangling-coverage-bits
with a CMOP.
timotimo yeah, if we don't want performance :)
[Coke] :)
once jnthn fixes strings, we'll have plenty to waste! 22:17
timotimo er ...
maybe
[Coke] :)
timotimo we don't really expect performance improvements on parsing, right?
jnthn Before: 7.73s. Now: 0.51s. 22:18
(both including startup time)
I...guess that's better :)
timotimo the 1000 x benchmark, eh?
jnthn yeah
timotimo nice! :)
[Coke] m: say 0.51 / 7.73 22:21
camelia rakudo-moar b25b86: OUTPUTĀ«0.065977ā¤Ā»
22:23 jnap1 joined
jnthn Got it down to 0.47 now :) 22:41
(Difference more apparent on bigger benchmarks...)
Gonna let perl6-bench tell me how I've done, though... 22:42
22:45 japhb joined
japhb_ jnthn: \o/ 22:51
SO HAPPY TO SEE THAT RESULT
Now we need to give you more benchmarks to bang on. :-)
timotimo i wonder what we have to do to make forest fire behave in a similar fashion :) 22:53
jnthn Well, japhb++ already gave me 2 benchmarks showing things forest fire does are slow 22:54
japhb_ timotimo, That's why I started splitting out forest-fire benchmarks for jnthn.
jnthn, There's more than that. Hold on, lemme find it.
timotimo yes, that was an excellent help
er 22:55
i mean i expect it to be
japhb_ timotimo, irclog.perlgeek.de/perl6/2014-07-06#i_8980367 22:56
I think there's like half a dozen or so now.
But there are indeed more things to extract.
ENOTENOUGHTUITS 22:57
timotimo very good 22:58
it would be nice to come up with completely new benchmarks, too ...
i forgot what the state of the richards benchmark was 22:59
jnthn Aye, more are welcome on regexes, for example
Unless japhb++ already sneaked a load of those in while I wasn't looking :)
dalek arVM/strref: 56ddb81 | jnthn++ | src/strings/iter.h:
Make MVM_string_gi_move_to a bunch more efficient.

Jump directly to the right strand, and then to the correct repetition.		 23:03
arVM/strref: 992a482 | jnthn++ | src/strings/ops.c:
Optimize find_cclass and find_not_cclass.

Now, they just swiftly iterate graphemes with a single iterator in the strand case, rather than making an iterator per char read.
japhb_ jnthn, Sorry, regex benchmarks are on the list, but not added yet. Are they on your critical path? I might be able to do some this week if so. 23:04
dalek arVM: 9384917 | jnthn++ | src/io/procops.c:
Just use empty string constant, not make an empty.
MoarVM: 6eaf6aa | jnthn++ | / (29 files):
MoarVM: Significantly overhaul the strings code.
23:04 dalek joined
jnthn japhb_: Not critical path yet, I'm just intrested to know how bad the situation is. 23:04
japhb_ jnthn++ # Dalek crushing commit loads :-)
timotimo yaaaaay 23:05
japhb_ jnthn, roger that.
timotimo should find_cclass and find_not_cclass learn about repetitions, too? :3
japhb_ Maybe that will give me something easy to do while this cold has my brain at <50%
jnthn cold-- 23:06
jnthn recommends cooking up some nice Indian noms
I had one that woudln't go away until this weekend, when I made some nice spice-packed balti :) 23:07
timotimo whenever i get a sore throat, i like putting slices of ginger in boiling water for a while and drink the result (sans ginger slices, but that's a matter of preference)
the result is also enjoyable when cold 23:08
jnthn Curry had 6-7cm of ginger :)
And yeah, ginger is awesome.
japhb Mmmm, Indian food does indeed sound wonderful. 23:14
jnthn Hmm, I hope the latest perl6-bench copes with the fact some of my existing timings don't have all the benchmarks... 23:17
timotimo what i wonder is how to handle re-running a single benchmark and not throwing away all previous values and stuff like that 23:18
japhb_ jnthn, That should be handled just fine, except that you won't get summary scores for any timing runs that are incomplete. But you may not care about that right now .... 23:19
timotimo oh?
summary scores? that's the new thing for history stuff?
japhb_ Yes.
timotimo gotta run
japhb_ When you do `./bench compare|history [checkouts ...]` then the first checkout listed will be considered the standard, with performance = 100. All others will be compared to it by doing the geometric mean of relative performance on all tested benchmarks, and calculating one linear-scale score. 23:22
So with perl5 v5.20.0 as the reference (thus score = 100), one set of benchmarks I ran resulted in nqp-moar ~35, and rakudo-moar ~4-5 23:23
But if any tests did not succeed for a given compiler checkout, then the geometric mean is considered invalid, and no score will be computed for that compiler version. 23:24
So while working on the history function, I specifically run only the tests that run on all compiler backends, so I can see the scores. :-) 23:25
jnthn Hmm
The graphs look a little odd
perl5 is missing a bunch of points to the left.
But none of the others are.
oh no, happens once somewhere else too 23:27
japhb_ jnthn, yeah, I described that in my most recent commits.
I am now intentionally throwing timing data away that is below the startup/compile noise threshold, because the computed rates are essentially garbage 23:28
(which is what caused seesaw plots on the left of some graphs, or ridiculously high rates on the left, when on the right performance settled down to a consistent but much lower value) 23:29
jnthn ah
japhb_ I believe the trends should remain clear, but please post any that have become confusing.
I'm still tuning the threshold.
(Note: timing data thrown away only during analysis. Data in timings files remains untouched, unless you intentionally rebuild the input files with post-analysis data using `./bench --format=json analyze`) 23:31
jnthn japhb_: jnthn.net/perl6/bench/2014-07-15.html is my latest one 23:33
Time for some rest; 'night 23:34
And get well soon!
japhb_ Thanks, jnthn. Sleep well. 23:44
Hmmm, some of the timings in jnthn's plots still show signs of bogosity. Left side of rakudo-moar/HEAD in postwhile_nil, for example 23:49
japhb_ considers increasing the threshold a bit more 23:50

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!