00:40 avuserow_ joined
jnthn brrt++ # blog post 01:17
01:22 FROGGS_ joined 01:48 ilbot3 joined 01:57 lue joined 02:20 jnap joined 03:08 avuserow_ joined
dalek arVM/const_storage_spec: 60ad5d9 | jimmy++ | src/ (46 files):
make get_storage_spec returns const MVMStorageSpec *
 03:34
05:32 colomon joined 07:03 zakharyas joined
sergot o/ 07:47
moritz serg\ot 07:52
07:54 klaas-janstol joined 08:11 woolfy left 08:13 Ven joined 08:14 brrt joined 08:15 woolfy joined, woolfy left
sergot mo/ritz 08:20
brrt \o sergot 08:21
FROGGS_ morning _ 'VB FTW 08:23
08:24 woolfy joined
brrt VB? 08:26
08:43 klaas-janstol joined
FROGGS visual basic 08:44
brrt oh 08:47
why is VB ftw?
nwc10 brrt++ # good blog post
brrt oh thanks :-)
08:47 jimmyz joined
brrt i've corrected the interator error :-) 08:48
jimmyz jnthn/brrt: would you mind if I push const_storage_spec branch to master?
brrt does it work and pass spectests?
nwc10 it worked for me. However, I was using gcc.
FROGGS brrt: that was ironic :o)
brrt i don't. but how did you handle the fact that the repr_data storage spec is'nt quite const
ooh
nwc10 what does MSVC think of it? 08:49
jimmyz works here
FROGGS I mean, everything that "unspaces" with _ and escapes quotes with more quotes is plain stupid
jimmyz I didn't get a chance to test it with msvc 08:50
nwc10 I've not looked at the code, so I can't say "yes, it makes sense", but if you're changing const, I think it would be a good idea to be sure that something more picky than gcc is happy with it 08:51
jimmyz aye
brrt will check msvc 08:53
or, i won't, because virtualbox is angry at me 08:54
jimmyz for another info, it reduces libmoar.so size about 100 bytes :P
brrt o.O 08:55
why would that be
reboot, bbiab 08:57
08:59 brrt joined
brrt VirtualBox, y u uninstalled 09:00
09:03 woolfy left 09:07 brrt joined
brrt i'mma be reporting bugs to fedora it seems 09:07
jimmyz: can't vet for your commit yet 09:09
jimmyz brrt: no hurry 09:10
brrt oh bloody, rebooting killed my work in the evaluation form :-(
that's pretty dumb of me 09:11
clang is slohooow
although we should probably fix all its warnings 09:12
idiotically slow, i might add 09:13
but it seems it compiles OK 09:16
anyway, bbi3h
09:30 woolfy joined, woolfy left 09:37 woolfy joined 09:38 woolfy left
timotimo "be back in 3h, when my moarvm compilation has finished" 09:47
10:07 Ven joined 10:37 Ven joined 11:41 brrt joined 11:44 itz_ joined
brrt not that long timo :-) 12:19
oh in response to your question 12:20
what happens really often in code is that we take an iterator of a hash or array
and then check if it's value is true
and then shift a value from it
but these operations are never invokish
and could in fact easily be inlined without any form of dispatch
at least, if you know whether you are dealing with a hash iterator or an array iterator 12:21
which you probably do because spesh
nwc10 I was about to type your last line for you
timotimo that does sound kinda interesting 12:22
brrt anyway, iterator true is never invokish, so just speshing that into it's own op will save some
timotimo fwiw, the boolification spec may be "ELEMENTS"
in which case, there's a piece of code in spesh that almost does what you want already
oh
we only do that on KNOWN_VALUE at the moment, which is far from helpful 12:23
which kind of check-for-truth are we using in the iterator case?
if_o/unless_o?
brrt unless_o most of the time
basically for @foo -> $bar { } makes an iterator out of @foo, jumps after our block unless the iterator is true, shifts from the iterator, enters the block, and jumps back at the end 12:25
timotimo OK, i can whip something up now that we have a way to allocate temporary registers 12:26
(which is what blocked the previous attempt at this feature)
src/spesh/optimize.c:202 does it for known values, for just known type, it'll turn into unbox_i, unbox_n, isnull_s, ... 12:27
not 100% sure if we have a proper op yet for the iterator case, may just have to build an sp_istrue_iter or something
today may end up a busy day for me for other things, though, so maybe it'll happen tomorrow
brrt yeah, i'd say that we have 16 bits of space for ops 12:28
which is? 1024 * 64 ops? plenty space to add special ops for special situations 12:29
nwc10 "Special Circumstances" 12:31
12:42 FROGGS[mobile] joined
timotimo "OpenBSD Ports Change" tweeted that moarvm b0rks with "error: unsupported platform" for dyncall_callvm.c 12:44
jnthn Um...did we actually upgrade it? 12:47
jnthn didn't recall doing that for a while
timotimo no clue 12:49
maybe someone put the port in there for the first time or something
13:06 JimmyZ joined
JimmyZ const_storage_spec branch builds with MSVC 13:10
so I will push it to master :)
13:11 jnap joined 13:12 ggoebel11111112 joined
dalek arVM: 60ad5d9 | jimmy++ | src/ (46 files):
make get_storage_spec returns const MVMStorageSpec *
 13:13
brrt much approve 13:14
jnthn Such const
JimmyZ :/
moritz 46 files changed, 103 insertions(+), 103 deletions(-) 13:16
wow
erm
such wow
nwc10 (correct) const is good, because it tells both the compiler and humans things
it's better to get it right early, because it's hard to retrofit 13:17
JimmyZ yeah, at least it's good for GCC
moritz ftr I'm not against consting anything, I was just surprised how many lines it touched 13:21
nwc10 I still haven't looked at it, but I'm not surprised
moritz (but that's just because I don't know the code base at all)
jnthn I guess const is somewhat viral.
nwc10 ayre
aye
I *have* now skimmed it, and it doesn't surprise me 13:22
[Coke] brrt++ # one of the more successful GSOC programs (most stuff already integrated into master!) 13:27
brrt \o/ yay 13:28
yes, that is very nice
nwc10 that's somewhat an understatement
[Coke] nwc10: was hedging my bet.
nwc10 :-)
wise
jnthn Is there anything that isn't integrated into master by now? :)
And yes, brrt++
I'll be filing my eval later today :)
nwc10 jnthn: I don't know. There are a lot of branches still
brrt not in the way of branches, i think 13:29
jnthn nwc10: Yes, I meant of brrt++'s work :)
nwc10 oh, his work - he still has to drink the beer that we're going to buy him.
jnthn :)
brrt and for the time being, i'd like to keep moar-jit arround so we have a place to stuff the the breaking jit stuff 13:30
jnthn +1
FROGGS +1
:o)
[Coke] is he even old enough for bier?
JimmyZ brrt++ # indeed
FROGGS *g*
brrt oh, can you all help me out a bit? what would be the most colourful thing to tell on my eval form about the past few months? 13:31
there are plenty of things of course that happened
nwc10 [Coke]: oh, most curious. For the purposes of YAPC::Europe, everyone is: en.wikipedia.org/wiki/Legal_drinking_age#Europe 13:32
brrt lol 13:33
well that wouldn't be a problem for me anyway :-)
[Coke] nwc10: bulgaria++
jnthn brrt: Well, I most remember staying up until 3am fixing deopt all + JIT :P
brrt oh yes, that was a story
[Coke] Question for the .eu crowd here; would you travel to Belarus? 13:34
brrt ... i doubt it
jnthn [Coke]: Yes, if I had a good reason to.
brrt why ask? 13:35
jnthn [Coke]: And next time I won't try taking a building of "that hilarious ugly building", only to find I have a policeman telling me that it's the presidential palace and I should delete my photos of it. :)
brrt whut :-o
[Coke] (my father's family is from belarus) 13:36
jnthn Police guy spoke no English. My Russian is awful. His attempt to write my name and address in Cyrillic was hilarious. I'm not sure they'd have found me with that info if they tried. :) 13:37
nwc10 your Russian was good enough to deal with the Ukrainian taxi drivers 13:38
jnthn Taxi drivers have a simpler interaction model than police. :) 13:39
Anyway, I don't really consider Belarus a dangerous place to go. It does need some paperwork/prior arrangements that are a small nuisance. Brest is a LOT nicer than Minsk. 13:40
brrt i consider belarus a slightly politically unfriendly place to go 13:41
although that's probably not that relevant for foreigners 13:42
[Coke] yah, I'd mainly go to consider hitting up town halls for birth records, I think.
... it occurs to me it'd be much cheaper to pay for jnthn to go!
jnthn Hm, that'd mean dealing with administrationy folks = *certainly* could use a native (or fluent) speaker. 13:44
brrt regrets not learning russian when it was offered 13:45
anyway, cyrillic isn't all that complex if you know the greek alphabet 13:46
jnthn I didn't, but still didn't find it too complete :) 13:47
uh, complex
[Coke] I tried bulgarian briefly; seemed doable, but I stopped working with the offshore bulgarian team before I could do more than say "hello, please a beer give me." 13:49
13:50 woolfy joined
brrt the yapc::eu wiki tells me sofia is 7000 years old... that's pretty amazing i think 13:50
13:50 woolfy left
brrt oh, timotimo: i'd meant to say that the MVMJitCode structure has both the pointer to and the size of the code, as well as the pointer to the static frame (so you have its' name) 14:02
14:05 woolfy joined, woolfy left 14:15 woolfy joined, woolfy left
brrt submitted 14:24
pfew
that was a bit of work
[Coke] brrt++ 14:42
14:54 cono joined
TimToady that was the hard part :) 15:32
brrt evaluations aren't easy, that's for sure 15:41
15:47 FROGGS joined
japhb self-evaluations particularly so 15:48
16:28 klaas-janstol joined 16:56 ggoebel11111113 joined 17:26 Ven joined, brrt left 17:44 tgt joined 17:47 Ven joined
timotimo i'll spend a bit of time on the iterator boolification optimization in spesh now 18:17
18:19 klaas-janstol joined
timotimo should i put sp_ ops at the very end when i add new ones or should i just put them where i think they fit? 18:32
as the order of sp ops doesn't matter for serialized bytecode
jnthn Yeah, the oder doesn't matter 18:33
uh, order
I'm sure the Oder is a very important river indeed.
timotimo :) 18:35
welcome to the new world Order
18:47 Ven joined
timotimo huh. 19:33
sadly, the spesh_diff script is in somewhat bad repair :\
jnthn: is there a reason why MVM_spesh_manipulate_insert_ins(tc, bb, ins->prev, new_ins); could end up not putting the new_ins in? 19:43
jnthn In my experience, normally 'cus I did something silly on the calling side :) 19:44
(Passed the wrong basic block, or tried to insert the wrong thing, or into the wrong thing, or onto a deleted thing, or... :)) 19:45
timotimo don't think i did anything like that
however, i may have put a "isconcrete" in and that turned into a guardconc, but not a const_i64_16 19:46
gist.github.com/timo/1f1ba5dd12f1748e56b2 - but i don't even know if this is what blows up
would ins->prev work even if the instruction is at the very beginning of a basic block? 19:48
jnthn Yeah, it knows what to do with NULL 19:49
timotimo i can clearly see the temp register being used in the if_i/unless_i that is the result of my optimization
but i never see the op i insert before that that is supposed to put an actual value in
oh.
dead code elimination
forgot to up the usages of the temp register ... again.
jnthn :) 19:50
Yes, the dead code elim is quite efficient :) 19:51
timotimo yup.
it seems like boolify_iter doesn't get used a single time in nqp's build process 19:52
jnthn Did you do some facts on iter?
timotimo probably not 19:53
i'll have to check if it gets a MVMList repr'd object, a MVMHash repr'd object or a MVMContext repr'd object and then handle each individually ... hmm. 19:55
it'll probably be fine to replicate the type selection logic from MVM_iter in spesh ...
jnthn Yes, I think that's the kinda thing to do 19:57
timotimo this'll better be worth it :P 19:59
cool, seems to work 20:07
i'll strip the debug messages and commit + push if it survives spectests 20:08
20:09 woolfy joined
timotimo oh damn 20:11
spectests are quite unhappy
unbox_i makes things unhappy 20:14
hmm.
of course. 20:33
it's supposed to return a falsy result if the value is a type object 20:34
and unbox_i will blow up instead
jnthn: what's the best suggestion you can come up with to get around this problem?
except for "don't turn iffy ops into unbox_*" 20:35
trying to bool_I on a type object will violently explode ... 20:37
timotimo puts a KNOWN_CONCRETE check in there to guard the optimization 20:38
jnthn Yes, chekcing it's concrete is the way to go
You need to know an opt is valid before doing it :)
timotimo oh!
actually
... how does the SSA form react if i put another goto in there? 20:39
because i can just turn an if_o into an isconcrete + if_i + unbox_i + if_i for example
er ... not quite
it'd have to be an unless_i and then it'd have to jump to the BB's successor :\ 20:40
can i be sure that iter will return something that is concrete? 20:41
jnthn Yes, iter always will returna concrete MVMIter 20:42
timotimo OK
jnthn Uh
But you don't know the type
MVMIter is a repr
You need to look at the RHS to know the type
But I guess you are already :)
timotimo yes, i am
strange. i have a FACT_CONCRETE guarding my iffy opt, but i still get an "cannot unbox type object" error in many, many spec tests 20:43
but maybe it just means i'm accidentally letting a branch happen that shouldn't 20:48
like ... an isconcrete was guarding an unbox and i'm accidentally blowing that up
but an isconcrete that is guarded by FACT_CONCRETE should turn into a const and then into a goto 20:51
hmm.
if the spec tests are clean for boolify_iter, i'll push and you can have a little look 20:54
20:59 tgt joined
timotimo does t/spec/S32-list/uniq.t fail usually? 20:59
it segfaults here
#0 0x00007fcacf9dc146 in scan_registers (frame=0x6ae1fd0, worklist=0x677bdb0, tc=0x19af650) at src/gc/roots.c:373 21:01
maybe i'm doing dumb things with the registers i'm throwing around?
SPESH_DISABLE=1 makes it pass >_> 21:05
er, whaaaaat 21:06
#25 0x0000000000000004 in ?? ()
No symbol table info available.
that can't be right
at least with disable_jit, the stack doesn't explode as hard 21:09
21:14 brrt joined
timotimo oh! 21:15
it also crashes without my changes!
thta's
that's fine, then
dalek arVM: c89d083 | (Timo Paulssen)++ | / (6 files):
we can have a sp_boolify_iter op to boolify iters quickly
 21:18
arVM: 586e4ce | (Timo Paulssen)++ | src/spesh/ (2 files):
facts for iter, spesh iffy into boolify_iter
timotimo jnthn: if you could have a look at the other modifications in iffy...
brrt timotimo: that's not ifne :-) 21:33
timotimo uh? ifne? 21:34
oh
fine. yeah, i get it
jnthn timotimo: Still working hard on my talk at the moment... :/ 21:37
timotimo OK
that's a bit more important
now i have brrt to bother! :D
jnthn Well, more urgent at least :)
brrt will probably be at my talk, so will be quite bothered if it sucks :P
brrt i very much intend to be, yes :-) 21:38
jnthn Did you work something out for not missing your plane? :)
timotimo heh :) 21:39
brrt yeah, we're staying at my in-laws
which live quite a bit closer
jnthn Ah, cool
japhb "we"? Who else is going with you? 21:40
brrt but anyway, i haven't seen uniq.t fail
my gf :-) 21:41
japhb Ah! Also a hacker?
timotimo brrt: did you see my problem? i guard tha iffy changes with FACT_CONCRETE, but i get lots and lots of spectests failing with "cannot unbox type object" 21:42
but the op that'd try to unbox would be unboxing the thing that's FACT_CONCRETE
brrt no hacker (yet) :-)
japhb Let the immersion training commence! ;-) 21:43
brrt timotimo: i don't really understand what you do yet in your code
maybe a hacker in non computer related senses, though :-) 21:45
timotimo brrt: if we know the type of the flag used for the if_o/unless_o, we can have a look at what its boolification spec's mode is
brrt i see
timotimo so i'm trying to turn, for example, unless_o on an MVMIter into a sp_boolify_iter that generates an int64 and then unless_i
japhb Oh, brrt, I forgot to say way back when you mentioned you were getting a degree in energy and environmental science, and someone said that gets used by anyone who has a datacenter ... they're not only right, that's not the half of it. At the scale of e.g. Google, there's a LOT of work going on to deal with the externalities of vast energy and equipment usage in concentrated areas. So please apply here when you get your degree. :-) 21:46
timotimo in the spectests i get lots and lots of "cannot unbox type object"
brrt nods and thinks that is the right approach
timotimo but i'm already checking the flag for FACT_CONCRETE 21:47
so no type object should land in my unbox_i (for example) operation
so i have to guess i'm causing a branch to be evaluated that shouldn't have been evaluated 21:48
:\
brrt japhb: yeah, it's something i'm actually very excited about
21:48 Ven joined
brrt part of my motive for making a JIT compiler is that compiled code is more efficient = more energy efficient as well 21:49
i'm looking at the spesh diff you posted, it looks quite different
timotimo oh, yeah
that was before i added the usages++ to the temporary register
so the dead code eliminator killed the inserted instruction immediately :)
brrt nice 21:50
[Coke] uniq.t fails all the time.
brrt hmm
timotimo OK, that's good to know
i was worried i had screwed something up there
brrt basically, do you know what out_facts->flags held before you did anything with it?
[Coke] github.com/coke/perl6-roast-data/b....out#L2381
it's been segfaulting for some time. 21:51
timotimo you mean in the facts discovery for the iter op?
brrt yeah 21:52
brrt hadn't seen that yet (uniq.t bustage)
timotimo i don't, actually
why should that asplode?
oh, i forgot to say:
the "can't unbox type ojbect" only occurs if you remove the return in front of, for example, MODE_UNBOX_INT 21:53
so it's nothing to do with the iter facts i'd think
brrt: the out_facts flags are 0 before the iter_facts runs through 21:56
brrt hmm ok 21:58
brrt is trying to understand what's going on and not quite succeeding yet
timotimo what's going on or what's going wrong? :)
21:59 klaas-janstol joined
brrt both :-) 21:59
timotimo i thought the code ended up somewhat straight-forward %) 22:03
but i can explain it point for point if you'd like 22:04
maybe that'll help us stumble over the mistake
brrt lets say it in another way 22:07
timotimo at least "uncommenting" a few more boolification specs doesn't seem to break spectests
brrt i have no idea what the code does with the changes you made :-) 22:09
dalek arVM: 50edccc | (Timo Paulssen)++ | src/spesh/optimize.c:
these speshes don't break spec tests
 22:11
timotimo here's more changes to make it easier!
please ask more specific questions?
brrt is reading :-) 22:16
dalek arVM: d27d560 | jnthn++ | src/math/bigintops.c:
Fix nqp::isbig_I to not consider so much big.

This should fix the weird drop-offs in the native benchmarks on native int loops, where we prematurely switched to bigints even though we were well within a 64-bit register.		 22:26
timotimo er, huh, what.
now the spec tests seem much, much cleaner even after enabling UNBOX_INT again 22:27
brrt uhm, it seems many many more need isconcrete first 22:30
but that's just me
timotimo yes. that's why i guarded against FACT_CONCRETE
well ... it works now ... for some reason ... 22:31
not sure how often it still triggers for ints now ...
brrt yeah, mode unbox_int requires to check for concretishness
timotimo yes.
so ... if i want to put an isconcrete check in, i'd need to emit a jump directly to the BB that's the successor after the isconcrete and then the check for the unboxed int 22:32
will that be terribly, tèrribly bad for consumers of the SpeshGraph datastructure?
i.e. having a goto that's not at the exact end of the BB?
brrt worst case we add a manipulate api to split bbs
but i'm not sure what effect this has on the SSA computation? 22:33
timotimo soudns very finnicky
22:33 klaas-janstol joined
brrt yeah, i agree 22:34
timotimo i have a pretty good-looking spectest run right now with more modes activated 22:36
dalek arVM: d5045ec | (Timo Paulssen)++ | src/spesh/optimize.c:
MODE_UNBOX_INT and MODE_BIGINT seem to be safe according to the spec tests
 22:39
timotimo can you test this? spec tests are clean with it on my machine
brrt tell you something strange. on this laptop i can actually hear the CPU working :-o 22:41
timotimo it's probably the powersaving jumping between frequencies 22:42
brrt hmm i imagine so
timotimo and now i should implement sp_boolify_iter 22:44
brrt yeah :-) 22:45
actually, can't we do sp_boolify_iterhash and sp_boolify_interarray directly
timotimo we could. do you suggest i do that? 22:46
brrt i.e. look at the structure as if encapsulation doesn't exist
timotimo well, in that case it could turn into a sp_get_i
brrt hmm... i suggest that i myself won't do it tonight, yet
timotimo :)
brrt i'm going to sleep in a few minutes
timotimo oh 22:47
sadly, the calculation isn't quite as simple
brrt let me see how MVM_iter_istrue is done
timotimo for hash, it's a check for a null in the iter_state.next
but for the array it's a index + 1 < array_state.limit
brrt uhuh 22:48
which is why you have the different ops for them :-)
timotimo it'd seem like we could want to do loop hoisting if we pull the array_state.limit out in one spot and check against the index in another
if we can prove the length of the array we're iterating over doesn't change
which we probably can't do very often
brrt hmm
no, wouldn't bother with that yet 22:49
timotimo right; but at some point we could
maybe next year ;)
oh damn it 22:51
it seems like i'm getting worse spec test results on my desktop machine as compared to my laptop
brrt yeah, i get not-entirely-clean spectest either 22:53
timotimo socket-async and lock on my laptop 22:54
quite a few more on my desktop
damn it :(
i think the boolify_iterarray vs boolify_iterhash won't be worth as much as the if_o -> boolify_iter + if_i transformation 22:55
the body.mode is probably so close to body.array_state.index and hash_state.next that it'll all be fetched at once
brrt i do think it will, because it completely erases a function call
which means pipeline luv
and code cache hapinness
happiness 22:56
timotimo oh
i hadn't considered that
brrt well, i had, and it was my main motivation :-)
but you spesh the actual type as a fact, right?
i.e. the facts thingy already differentiates between hash iterator and array iterator 22:57
timotimo yes 22:58
gist.github.com/timo/d2968def5690342270d1 - this is on my desktop >_<
MVMArray: Can't resize to negative elements - what. 22:59
in xx, apparently?!
that happens when you xx -1 23:00
brrt yeah, that happens when you bug
timotimo but it also happens with MVM_SPESH_DISABLE=1
so ... wth. 23:01
brrt compiler failure effect?
timotimo oh
brrt i dunno, just suggesting :-) 23:02
timotimo i actually didn't get some changes of rakudo on my laptop
brrt ah 23:04
timotimo i didn't break stuff! 23:05
TimToady did! :)
brrt well then 23:06
everything is just fine isn't it :-)
timotimo \o/
oh, actually ... do i know the type of the iter at that point? 23:18
i'd have to actually look at the type of the thing that gets thrown into the iter
brrt well 23:19
yeah
timotimo i could be mean and put the type into the decont_type
that's *kind of* correct even :P
brrt hmm
jnthn There's flag bits; you could have flag for IS_ARRAY_ITER and IS_HASH_ITER 23:20
In facts
Please don't dual-purpose decont_type :)
timotimo hmm, seems wasteful, no?
jnthn I think we've plenty of bits free in the bit field.
timotimo OK 23:21
jnthn Just out of padding reasons I don't think it makes sense for it to be smaller than 32 bits, iirc.
brrt is testing that suggestion right now 23:24
timotimo ah, of course
chat suggestion?
what* 23:25
i'm already compiling the boolify_iter_{arr,hash} change
brrt oh really? :-)
then hopefully yours works a little better than mine
timotimo heh. hopefully.
building nqp with it right now
you know what 23:26
i'll push it directly and you can implement the jit version of that
brrt ehm, test if it also works with rakudo
but yeah, i'll do that
dalek arVM/split_iter_boolification: ca7615e | (Timo Paulssen)++ | / (9 files):
split boolify_iter into two ops, for hash and array.
 23:27
timotimo ^- hence the branch
brrt not trying to be rude, but aren't iterating over a hash and iterating over an array mutually exclusive? :-) 23:28
timotimo looking good so far
yeah, well ...
what if we have an iter that's neither? :D
we can just define the HASH_ITER as 0 instead %) 23:29
brrt hmm yeah either of them
timotimo spec tests look good at the moment
well, ideally the bigger one :) 23:30
brrt i'm really going to sleep now 23:32
:-)
TimToady o/
brrt see you tomorrow (and on friday :-))
o/
23:32 brrt left
timotimo oh 23:32
in that case, i'll have to implement these ops in the jit apparently :(
jnthn timotimo: Do you have that link to all the Rakudos over time benchmark you did? And do you mind if I use one or two of the graphs in my talk? 23:34
timotimo no problem 23:35
FROGGS www.reddit.com/r/perl6/comments/2co...at/cjs4rpv
timotimo i'll make another addition to that graph as soon as we release, sound good?
oh, yeah, there, too
oh 23:36
i have even more benchmarks, jnthn
t.h8.lv/p6bench/2014-08-18-longterm...story.html / t.h8.lv/p6bench/2014-08-18-longterm...-moar.html / t.h8.lv/p6bench/2014-08-18-longterm...-moar.html 23:37
those have a moar-jit in them, too
jnthn Thanks 23:42
japhb Hmmm, those scores look really nice ... when comparing with rakudo 2014.01 instead of perl5. 23:47
jnthn japhb: jnthn.net/perl6/bench/2014-08-20.html is my run on a latest Moar built on MSVC, and with JIT 23:49
japhb: See the natvie ones :)
*native
japhb woah 23:55
Hmmm, while_int2str_concat* is unhappy 23:57
jnthn Yeah. That graph is the wrong shape.
timotimo also we regressed, didn't we? 23:58
japhb wonders why perl5 doesn't scale as flatly as rakudo in the hash tests, despite being faster overall still.
jnthn timotimo: Regressed on what? 23:59
japhb Wondering if the perl5 version of reduce_int_comb_range is incorrect, since it's scaling particularly badly on that test.

Powered by Cro and the Raku® Programming Language.

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

Thank you!