Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-03-14

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

All times shown according to UTC.

Time Nick Message
01:43 colomon joined #moarvm
02:09 colomon joined #moarvm
02:46 agentzh joined #moarvm
02:48 ilbot3 joined #moarvm
02:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:35 colomon joined #moarvm
03:46 colomon joined #moarvm
06:58 domidumont joined #moarvm
07:05 domidumont joined #moarvm
07:38 agentzh joined #moarvm
08:05 Geth ¦ MoarVM/even-moar-jit: 3a1470bb98 | (Bart Wiegmans)++ | 6 files
08:05 Geth ¦ MoarVM/even-moar-jit: Implement store and load instructions
08:05 Geth ¦ MoarVM/even-moar-jit:
08:05 Geth ¦ MoarVM/even-moar-jit: Generalize the load, copy and store pseudotiles to take multiple memory
08:05 Geth ¦ MoarVM/even-moar-jit: classes (i.e. base registers).
08:05 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/3a1470bb98
08:06 brrt joined #moarvm
08:08 vendethiel- joined #moarvm
08:12 brrt good * #moarvm
08:13 brrt left #moarvm
08:13 brrt joined #moarvm
08:22 samcv hello brrt
08:23 brrt hi samcv
08:23 brrt i think you've forgotten to update MOAR_REVISION in NQP
08:23 brrt because I've failing tests due to missing eqatic
08:23 samcv it has always been in moarvm
08:24 samcv didn't make any op changes for MVM
08:24 brrt oh, really
08:24 brrt then why is my test failing
08:24 samcv oh. you mean the fixes
08:24 brrt yeah
08:24 samcv hold on let me check
08:24 brrt :-)
08:25 samcv but interestingly the nqp::eqatic op wasn't added, but it just injected it like. using QAST or something
08:25 samcv i forget
08:25 samcv but the call wasn't accessible for me to test. also are we talking nqp tests or roast
08:25 brrt nqp tests
08:25 samcv ok thx
08:25 brrt :-)
08:25 samcv hmm i did bump moarvm
08:26 samcv what version of mvm do you have
08:27 samcv i'll go to that commit and check
08:28 samcv well i have it bumped i checked. bumped to commit 58457845
08:28 samcv and tests pass for me
08:28 brrt This is MoarVM version 2017.02-356-g326ac8c built with JIT support
08:28 brrt hmmm
08:29 samcv and it's passing on travis
08:29 samcv left #moarvm
08:29 samcv joined #moarvm
08:29 samcv oops accidently parted
08:30 nwc10 mmm, Travis. http://www.welovebob.com/characters/travis.htm
08:30 samcv travis is like that old rundown tractor. perpetually out of date. but still useful so you keep it around
08:31 samcv brrt, idk try deleting libmoar.so and */bin/moar
08:32 samcv sometimes things are weird. idk i've gotten times where i had to manually delete things to get a version bump to actually show up so i could build nqp
08:33 samcv ugh now i can't change branches on moarvm because i have untracked files
08:33 samcv in the 3rdparty directory. maybe resetting will save me
08:35 brrt hmm, i'm fairly sure I don't have your patches in even-moar-jit
08:35 brrt but the question is
08:35 brrt why does the version check not work
08:35 samcv not sure. but deleting the .so and binary and then installing fixed it
08:35 samcv this has happened at least 3+ times
08:36 samcv make clean make realclean and build no change.
08:36 brrt o.O
08:36 samcv also it sucks i can't checkout other branches now and it complains about libtommath would be overwritten
08:36 brrt that is really odd
08:36 brrt yeah
08:36 brrt what happened there
08:36 samcv yeah. happens a lot
08:37 brrt wasn't libtommath just a submodule
08:37 brrt and if so
08:37 samcv uhm i think it's a submodule now?
08:37 brrt why couldn't the submodule url not be changed
08:37 samcv and wasn't before?
08:37 brrt but it wasn't before..
08:37 brrt ouch
08:37 samcv probably something i can do to have it force remove them and not bother me
08:38 brrt git clean -xdf  will help
08:38 samcv what does that do?
08:38 samcv remove untracked files?
08:38 samcv ah but that won't help because it's a submodule
08:39 brrt yes
08:39 brrt well
08:39 brrt hmm
08:39 brrt not from master to other things
08:39 brrt but it helps me merging in master to even-moar-jit
08:39 samcv i can't seem to checkout that branch
08:39 samcv error: pathspec 'even-moar-jit' did not match any file(s) known to git.
08:40 brrt surprise
08:40 brrt well, that's odd
08:40 brrt anyway
08:40 samcv gonna try more things
08:40 brrt MAX and MIN are no longer defined
08:41 samcv well i get a conflict with libtommath :)
08:41 samcv fun fun fun
08:41 samcv almost wanna make a new git folder lol
08:44 samcv ugh well i found the answer `git show-ref` grepped it for the branch. so i can checkout refs/remotes/upstream/even-moar-jit
08:45 samcv and i try pulling and it doesn't know to put it in that branch.
08:46 samcv think i'll push all my changes to my repo and then start new
08:49 Geth ¦ MoarVM/even-moar-jit: 15 commits pushed by (Daniel Green)++, (Jonathan Worthington)++, (Timo Paulssen)++, (Samantha McVey)++, (Bart Wiegmans)++
08:49 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/compare/3a1470bb98...fb12eb1634
10:00 brrt joined #moarvm
10:06 vendethiel joined #moarvm
11:16 brrt joined #moarvm
11:17 brrt joined #moarvm
11:25 timotimo brrt: are you going to rebase the even-moar-jit branch, or will we just merge it and keep the amazing history with all the merge commits one way?
11:28 MasterDuke timotimo: re jnthn's comment in https://github.com/MoarVM/MoarVM/issues/545, do you know how to "influence the nursery size"?
11:29 timotimo ah yes
11:29 timotimo there's a nursery alloc limit in the threadcontext
11:29 timotimo just subtract from that
11:30 timotimo it'll be reset to what it "used to be" the next time a minor collection happens
11:30 MasterDuke so what about that has to be done "carefully"?
11:31 timotimo well, we don't want to cause regular code that uses bigints to suddenly do hundreds of thousands of collections per second
11:31 timotimo i read that sentence as being careful about the way we check bigints for their influence
11:31 timotimo i could be wrong
11:31 timotimo BBIAB
11:31 jnthn Well, the other thing is that you musn't move the limit behind the alloc
11:32 jnthn I think that doing that is liable to bust something
11:32 MasterDuke jnthn: but wouldn't that give us infinite ram?
11:32 jnthn May get away with it, but I wouldn't bet on it
11:33 jnthn I...don't understand the question
11:33 jnthn We're moving the limit back towards the start of the nursery, so we collect sooner
11:33 jnthn I'm saying we mustn't move it further back than the "where we should allocate the next object"
11:33 jnthn e.g. into the region we've already used
11:33 timotimo so always leave at least one byte? :)
11:33 MasterDuke just a bad joke. if the limit goes negative, perl6 creates more ram for your computer!
11:34 brrt i think rebasing the even-moar-jit branch will be highly brittle
11:34 timotimo hm. well, probably
11:34 brrt i can try…
11:34 timotimo i "fondly" remember how newio used to look in "gitk"
11:35 MasterDuke jnthn: re https://github.com/MoarVM/MoarVM/issues/513, i sort of have a fix, but it breaks some tests
11:35 MasterDuke m: use Test; todo('the values get accidentally sign-extended'); is class :: { has uint64 $.x; }.new( x => 2**64-1 ).x, 2**64-1
11:35 camelia rakudo-moar d232f3: OUTPUT: «not ok 1 -  # TODO the values get accidentally sign-extended␤␤# Failed test at <tmp> line 1␤# expected: '18446744073709551615'␤#      got: '-1'␤»
11:36 timotimo do we have a central issue somewhere that tracks progress on making perl6 installations relocatable?
11:36 MasterDuke that now actually fails because the assignment is done using signed ops
11:37 MasterDuke so it complains that the number is too big for a signed int
11:37 MasterDuke it's done via `decont_i -> MVM_6model_container_decont_i`, instead of `decont_u -> MVM_6model_container_decont_u`
11:38 jnthn Yeah, we don't really do uint64 properly yet
11:39 MasterDuke i started down a rabbit hole of adding *_u versions of a lot of ops
11:40 jnthn decont_u is a place where we could do with it
11:40 MasterDuke and got to the point where i think a src/6model/reprs/P6biguint.c is needed
11:40 jnthn Hm
11:40 agentzh joined #moarvm
11:40 jnthn I'm not sure about that
11:40 MasterDuke heh, neither am i
11:41 MasterDuke but there's a couple places with an array of native assign ops. `my @native_assign_ops := ['', 'assign_i', 'assign_n', 'assign_s'];`
11:42 jnthn Assignment is about containers
11:42 jnthn And nothing to do with bigint
11:43 MasterDuke and rakudo indexes into that to pick the right op, based on nqp::objprimspec()
11:44 MasterDuke and that op does REPR(type)->get_storage_spec(tc, STABLE(type))
11:46 MasterDuke and the storage_spec for p6bigint has MVM_STORAGE_SPEC_BP_INT, which is == 1, and is used as the index into that array of assign ops
11:50 MasterDuke backing up to decont_u, i added that, but couldn't find where the decont_i was being called/codegenned for `my uint64 $a = <foo>`
11:51 MasterDuke and then i found this: https://github.com/rakudo/rakudo/blob/nom/src/Perl6/Optimizer.nqp#L1262. `if $last_op eq 'assign_i' { $op.op('decont_i') }`
11:52 MasterDuke and added an else for assign_u, but that's where i ran into the storage_spec problem
11:52 jnthn lunch now; bbiab
11:53 MasterDuke k. i'm going to add a couple more comments while it's relatively fresh in my mind
11:55 MasterDuke i just had a thought. it may not be very "clean", but i guess i could check if the storage_spec has the is_unsigned flag set and return a different value then
11:55 MasterDuke in the objprimspec implementation here: https://github.com/MoarVM/MoarVM/blob/master/src/core/interp.c#L1819
11:58 MasterDuke `if (ss->boxed_primitive == MVM_STORAGE_SPEC_BP_INT && ss->is_unsigned == 1) { GET_REG(cur_op, 0).i64 = 4; } else { GET_REG(cur_op, 0).i64 = ss->boxed_primitive; }`
12:09 MasterDuke Bytecode validation error at offset 124, instruction 19: operand type 160 does not match register type 56
12:09 MasterDuke i broke something
12:13 samcv so should it be indexic_s for string index case insensitive
12:13 samcv index_s is the op name
12:13 samcv and eqatic is the op for case insensitive eqat
12:13 samcv indexic_s ?
12:15 samcv jnthn, let me know when you get back from lunch
12:17 MasterDuke timotimo: re making perl6 installations relocatable, did mst ever merge his work on cleaning up the build process? and is it related?
12:28 samcv MasterDuke, what are your thoughts on the op name
12:35 edehont joined #moarvm
12:44 brrt (rebase from hell :-o)
12:48 MasterDuke samcv: indexic_s seems consistent
12:48 samcv kk
12:59 MasterDuke oh, just found nqp::objprimunsigned, maybe can make do with that
13:05 samcv ok op is sorta done. i can make it faster eventually but atm relies on the other op
13:05 samcv good start point to continue work
13:19 jnthn samcv: indexic_s works for me
13:19 yoleaux2 12:32Z <IOninja> jnthn: would you mind taking a look at this code? I read your response on some ticket that using values to parameterize roles can lead to memory leaks: https://github.com/rakudo/rakudo/blob/nom/src/core/operators.pm#L761-L766
13:19 samcv kk
13:23 brrt joined #moarvm
13:24 Geth ¦ MoarVM: samcv++ created pull request #550: Add case insensitive string index op indexic_s
13:24 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/550
13:25 samcv jnthn, right now it just calls MVM_string_equal_at_ignore_case for the length of the string, which is a little wasteful, but i'm not 100% sure how i am going to proceed with trying to factor out code i need between both
13:26 jnthn samcv: Make it work, then make it fast :)
13:26 samcv yeah that's what i was thinking
13:26 samcv want to add it and then add some tests in for nqp then think really hard
13:26 jnthn +1
13:26 samcv and eventually the code will appear
13:26 jnthn I'll review it in a little bit ;)
13:26 jnthn *:)
13:27 samcv kk
13:27 brrt jnthn, the danger of that strategy is that it can lock you into something that will never, ever work fast :-)
13:28 samcv well depends what it is
13:28 brrt (and even if code doesn't lock you, then often economics will)
13:29 samcv if i don't respond i've headed to bed, but feel free to send me messages
13:30 brrt sleep well :-)
13:33 jnthn brrt: Maybe, but it's only in the good cases that you know both how to do something and how to do it fast up front. Sometimes it needs implementing something once to understand it well enough to be able to come up with a fast/correct design
13:34 brrt true, true
13:34 jnthn Or at least, that's how it works for me :P
13:37 MasterDuke jnthn: on my branch, `my uint64 $a = 2**63-1; say $a` now complains `getlexref_i: lexical is not an int`. i've added a getlexref_u, but not sure how to get it called instead
13:39 brrt you're absolutely right for any technical question; but with regards to systems-in-social-context, the lock-in to an inefficient system is very, very real, and rather problematic, and often avoided easily enough
13:41 jnthn MasterDuke: Probably need to look through the QAST::Var compilation code
13:41 jnthn There's a codepath in there that emits getlexref ops
13:41 MasterDuke yeah, looking at src/vm/moar/QAST/QASTCompilerMAST.nqp:1651 now
13:50 IRCFrEAK joined #moarvm
13:52 MasterDuke ugh, all these arrays of ops
13:53 jnthn You'd prefer lots of if nests? :)
13:55 brrt timotimo: it's basically impossible to do
13:55 MasterDuke probably not. but figuring out what change to make here `my @kind_to_op_slot := [ 0, 0, 0, 0, 0, 1, 1, 2, 3, -1, -1, -1, -1, -1, -1, -1, -1, 4, 4, 4, 4 ];` isn't perfectly easy when you've never looked at this code before
13:56 MasterDuke heh. and in the middle of @attrref_opnames, `# XXX Want a getattrref_u in the end`
13:56 MasterDuke guess that does tell me where it should go...
14:01 MasterDuke hm, looks like i'm in the `if $lex` branch, not the `if $lexref` branch.
14:07 brrt joined #moarvm
14:11 brrt1 joined #moarvm
14:12 brrt1 left #moarvm
14:14 timotimo we could squash the whole even-moar-jit into a singel commit :P
14:15 dogbert17 o/
14:15 dogbert17 there are several tests which make ASAN unhappy if MVM_SPESH_NODELAY=1, have found three so far
14:16 nwc10 cool - I'd not been trying that
14:16 nwc10 (I hope that jnthn doesn't hate me too much for encouraging pain)
14:16 nwc10 torturing implementors, right?
14:16 dogbert17 nwc10: you definitely should :)
14:16 dogbert17 that's what we do :)
14:17 nwc10 meanwhile, send money here: http://www.perlfoundation.org/perl_6_core_development_fund
14:17 dogbert17 try this to see if you can reproduce (am on a 32 bit vm myself) t/spec/S06-currying/named.t
14:18 nwc10 I don't think that "my" machine has 32 bit ASAN installed
14:18 nwc10 and "my" other machine which *is* 32 bit is painfully slow
14:18 nwc10 and "my" poor workdeskop is getting hammered by running a VM
14:19 nwc10 (I'm cruel to it)
14:19 nwc10 I'm actually root on my work desktop, so could easily install things there
14:19 dogbert17 my 'hope' is that the bug will show up on 64 bit as well
14:19 nwc10 ah OK
14:21 nwc10 dogbert17: score! http://paste.scsys.co.uk/557481
14:21 dogbert17 yay
14:22 dogbert17 wonder what is actually going wrong though, is it a spesh issue or something else
14:23 dogbert17 I haven't checked all spectests, only up to S06
15:51 zakharyas joined #moarvm
16:22 dogbert17 jnthn: should I write a MoarVM issue wrt the MVM_SPESH_NODELAY test problems?
16:31 brrt joined #moarvm
17:31 Geth ¦ MoarVM: MasterDuke17++ created pull request #551: Shorten the nursery when creating large bigints
17:31 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/551
17:32 ilmari MasterDuke: uh, that only adds commented-out code...
17:33 MasterDuke ilmari: ha, that's what i get for testing while committing
17:33 MasterDuke ilmari++ for catching that
17:34 MasterDuke fixed
17:35 agentzh joined #moarvm
17:36 * ilmari has no comments on the merits of the code itself, though
17:38 MasterDuke when to adjust, and by how much, need input from someone who knows moarvm and the gc much much better than i
18:12 jnthn dogbert17: Yes, please; I'll have time to look more later in the week :)
18:27 brrt joined #moarvm
18:50 MasterDuke dogbert17: have you had a failures with t/spec/S17-promise/nonblocking-await.t? it just flapped for me
18:53 dogbert17 jnthn: https://github.com/MoarVM/MoarVM/issues/552
18:54 dogbert17 MasterDuke: test 19?
18:54 MasterDuke 10 i think
18:55 MasterDuke well no, 10 was ok, but then it stopped after that
18:55 MasterDuke https://gist.github.com/MasterDuke17/c1620e8aebe05c51dfa85e3489223d70
18:56 MasterDuke took about 20 runs to get it
18:59 dogbert17 MasterDuke: interesting
19:01 MasterDuke gist updated with valgrind output
19:02 MasterDuke updated with some different valgrind output
19:39 MasterDuke gist updated again. i've never seen this before: `MoarVM panic: Corrupt multi dispatch cache: cur_node == 0`
19:59 jnthn That's a new one...
20:00 * jnthn never saw it before either, except when implementing said cache, and even then only once :)
20:07 MasterDuke i tried changing it to print what cur_node actually is, but it hasn't happened again after another ~20 runs
20:08 Geth ¦ MoarVM: perlpilot++ created pull request #553: Use HTTPS protocol for fetching libtommath
20:08 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/553
20:09 MasterDuke but that test i extracted out segfaults every single time with valgrind
20:12 dogbert17 MasterDuke: It bugs out for me as well
20:12 MasterDuke ah, got it again! `MoarVM panic: Corrupt multi dispatch cache: cur_node == -24`
20:13 MasterDuke dogbert17: it seemed to run fine with perl6-gdb-m though, maybe you can figure something out there
20:16 perlpilot joined #moarvm
20:16 perlpilot https://github.com/MoarVM/MoarVM/pull/553  (just in case)
20:17 perlpilot The gist is that where I'm at git protocol is blocked, but https is not.
20:17 nwc10 perlpilot: Geth announced it: https://irclog.perlgeek.de/moarvm/2017-03-14#i_14263917
20:17 perlpilot oh good
20:17 jnthn perlpilot: Do we do that for the other submodules?
20:17 perlpilot use https?  yes
20:18 nwc10 I *thought* that we had a way to run Configure.pl to chose git instead of https
20:18 Geth ¦ MoarVM: ea9a8e1480 | (Jonathan Scott Duff)++ | .gitmodules
20:18 Geth ¦ MoarVM: Use HTTPS protocol for fetching libtommath
20:18 Geth ¦ MoarVM:
20:18 Geth ¦ MoarVM: Some organizations won't allow the git protocol, but will allow https.
20:18 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ea9a8e1480
20:18 Geth ¦ MoarVM: b8aa33dfb9 | (Jonathan Worthington)++ | .gitmodules
20:18 nwc10 but I'm doing a proper Usenet thing here and not actually looking at any code :-)
20:18 Geth ¦ MoarVM: Merge pull request #553 from perlpilot/master
20:18 Geth ¦ MoarVM:
20:18 Geth ¦ MoarVM: Use HTTPS protocol for fetching libtommath
20:18 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b8aa33dfb9
20:18 jnthn Me too, but should keep the defaults straight
20:19 nwc10 One machine I'm using is firewalled for https but git is OK
20:19 perlpilot nwc10: yes, for the main module, I think there's a GIT_PROTOCOL env var, but for submodules, it's in the repo
20:19 nwc10 yes, I know that this is the less common way round
20:24 perlpilot nwc10: I wonder if we could make it so that there's are two branches just with the submodule configuration (one for git protocol, one for https protocol, and none in master), then the appropriate branch gets merged in based on your perferred protocol.
20:25 perlpilot There's probably some better way to do that but I don't know much about submodules to know what that would be.
20:25 nwc10 me neither
20:30 dogbert17 jnthn, MasterDuke: got it with gdb (finally): https://gist.github.com/dogbert17/0996beb9635200f468e192b1150a910c
20:32 MasterDuke dogbert17++
20:33 MasterDuke jnthn: got that `Corrupt multi dispatch cache` a couple more times, so far all the times where i printed out the actual cur_node it was  == -24
21:08 vendethiel- joined #moarvm
21:29 jnthn dogbert17: ooh, that's an interesting one
21:29 MasterDuke jnthn: you meant something like `tc->nursery_alloc_limit -= (USED(ic) * sizeof(mp_int)) & ~0x7;`?
21:29 jnthn I'm way too tired to go hunting SEGVs today, alas
21:29 jnthn MasterDuke: Without the sizeof(mp_int)
21:30 jnthn MasterDuke: USED(ic) should give the non-GC-managed bytes allocated
21:31 jnthn And then also a MAX(USED(ic), 32768) or so
21:31 jnthn So `MAX(USED(ic), 32768) & ~0x7` is pretty good
21:31 MasterDuke running that sample code and printing out used, it never goes above 10
21:32 jnthn Yeah, guess the numbers just ain't all that big :)
21:32 jnthn If it's not creating enough pressure we could USED(ic) + sizeof(mp_int)
21:33 MasterDuke ah, with a bigger number in that loop used goes over 2000
21:33 jnthn Yeah, I don't think if all the numbers had USED of 10 we'd be hitting 1GB..
21:34 ggoebel joined #moarvm
21:34 MasterDuke ok, then i'll just change to `MAX(USED(ic), 32768) & ~0x7`
21:34 jnthn That'd imply over a million numbers, but the nursery is only 4MB and the holding object is 32 bytes :)
21:36 MasterDuke there were only ~500k numbers when i saw used go over 2k
21:37 MasterDuke wait, shouldn't that be `MIN(USED(ic), 32768) & ~0x7`?
21:38 jnthn Uh, yes, it should
21:38 jnthn d'oh
21:38 * jnthn is tired
21:43 MasterDuke jnthn: hopefully one last question. `if (tc->nursery_alloc_limit - nursery_adjust) > (tc->nursery_alloc + nursery_adjust))`. do i need to check that the difference there is greater than some value, or will the masking take care of that?
22:01 jnthn We have the MIN which will avoid wrap-around issues
22:02 jnthn I think you can just do > tc->nursery_alloc also
22:02 jnthn That'd be more accurate, I think
22:05 MasterDuke ah, ok, i'll change that
22:05 samcv good *
22:06 MasterDuke PR updated
22:09 jnthn OK; I'll look in the morning when I can do a useful review :)
22:09 MasterDuke thanks
22:10 jnthn o/ samcv
22:12 MasterDuke jnthn: oh, btw, think i should add this to the other functions in src/math/bigintops.c?
22:26 jnthn MasterDuke: Yeah, maybe factor it out to an MVM_STATIC_INLINE
22:26 jnthn And then just call it
22:27 MasterDuke all the functions (that create bigints), or should i try to log the `->used` in them and see if i can get any of them large?
22:28 jnthn I think they probably all have potential :)
22:28 jnthn I mean, I think you could probably write programs that get a big number in all of the cases
22:29 jnthn Of course, some don't produce new bigints (is-prime, comparatives, etc.)
22:30 MasterDuke yeah, then i'll go ahead and try to factor the code out and then add it to any function that produces new bigints
22:30 jnthn Alrighty :)
22:30 * jnthn will go and get some much-needed rest
22:30 jnthn 'night
22:31 MasterDuke later...
22:35 MasterDuke samcv: is your indexic_s faster? or the same, just cleaner code?
22:35 samcv than what
22:36 MasterDuke than whatever used to be done if you wanted the same functionality
22:36 samcv well eventually it will be yeah. it could be faster already
22:37 samcv cause i think we do index with like uc or lc
22:37 samcv which doesn't work properly unless it's really close to the start of the string
22:37 samcv m: say 'aaaaaaaaaastaaaa' ~~ m:i/st/
22:37 camelia rakudo-moar b19df9: OUTPUT: «False␤»
22:37 MasterDuke e.g., is there some code that does a uc of a needle and a haystack and then an index of those?
22:37 samcv that's what i think happens. i'm not 100% sure what happens
22:38 samcv on nqp side but we will need a case insensitive index thing to replace our current index calls
22:38 MasterDuke ah, so at least more correctness, possibly more speed?
22:38 samcv so a) it won't be part broken and b) will be faster
22:38 samcv already made m:i 40% faster :)
22:38 samcv with my previous changes that were merged
22:40 samcv so not sure about the speed of it now compared to what we do now, becuase don't have any way to test nqp with the new index thing yet since that side of things isn't implemented
22:40 MasterDuke yup
22:41 MasterDuke btw, index_s is jitted, you might want to add indexic_s to the jit also
22:42 MasterDuke afk for a bit &
22:43 samcv MasterDuke, how does JIT improve speed of a C function
22:43 samcv when it's already in binary
23:05 MasterDuke samcv: in the case that it just calls a C function i think it only removes the overhead of the call itself
23:06 samcv ah ok
23:06 MasterDuke which is why when i added the non-bigint radix to the JIT it only made it a little faster
23:18 geekosaur joined #moarvm

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