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