|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:11
nativecallable6 left,
bloatable6 left,
statisfiable6 left,
benchable6 left,
committable6 left,
evalable6 left,
releasable6 left,
coverable6 left,
notable6 left,
shareable6 left,
linkable6 left,
quotable6 left,
unicodable6 left,
tellable6 left,
squashable6 left,
sourceable6 left,
greppable6 left,
bisectable6 left
00:12
greppable6 joined,
bloatable6 joined,
tellable6 joined,
committable6 joined,
shareable6 joined,
evalable6 joined,
sourceable6 joined,
releasable6 joined,
notable6 joined,
coverable6 joined
00:13
benchable6 joined,
unicodable6 joined,
statisfiable6 joined
00:14
linkable6 joined,
bisectable6 joined,
quotable6 joined,
squashable6 joined,
nativecallable6 joined
01:49
leont left
|
|||
| nine | moon-child: those errors are hard and a single core dump most likely won't be enough. Can you post code somewhere that reproduces this issue (even if only sometimes)? | 05:48 | |
| moon-child | nine: github.com/moon-chilled/SEProxy/bl...seproxy.p6 | 06:23 | |
| it's quite innocuous (though not very well written) | |||
| another thing: I was using mvm from a few months ago; just updated it. Might that be the issue? | 06:24 | ||
| another thing: I'm on freebsd | |||
|
06:30
Altai-man joined
|
|||
| nine | Yes, a newer MoarVM may already have a fix (as well as new bugs...) | 09:10 | |
| nwc10 | good *, #moarvm | 09:11 | |
|
09:15
MasterDuke joined
09:30
domidumont joined
|
|||
| nine | good weekend! | 09:40 | |
|
09:42
sena_kun joined
09:43
Altai-man left
|
|||
| timotimo | good *9 | 09:53 | |
| MasterDuke | rainy weekend here | 10:09 | |
| nwc10 | currently sunny, but wind threatened | 10:10 | |
|
11:12
leont joined
13:35
raku-bridge left
13:36
raku-bridge joined,
raku-bridge left,
raku-bridge joined
13:41
Altai-man joined
13:43
sena_kun left
13:59
dogbert17 joined
|
|||
| dogbert17 | m: say "Hi #moarvm" | 14:03 | |
| camelia | Hi #moarvm | ||
| dogbert17 | does anyone know if the following debugserver function is in fact used? github.com/MoarVM/MoarVM/blob/mast...ver.c#L146 | 14:04 | |
| timotimo ^^ | 14:05 | ||
| my reason for asking is that it seems as if the last parameter, i.e. 'MVMuint32 *file_idx' has not been properly initialized | 14:08 | ||
| see github.com/MoarVM/MoarVM/blob/mast...rage.c#L61 and line 22 in the same file | 14:09 | ||
| MasterDuke | how could i end up in this branch (assuming the `|| 1` wasn't in the if)? i.e., how can i call `%` with two bigints that have smallint values? | 14:24 | |
| dogbert17 | MasterDuke: what branch? | 14:39 | |
|
14:39
zakharyas joined
|
|||
| MasterDuke | oh, ha. github.com/MoarVM/MoarVM/blob/mast...#L543-L545 | 14:40 | |
| dogbert17 | I'm note sure I understand. Do you want to use the else branch if the two operands are small? | 14:47 | |
| MasterDuke | yeah. it's currently disabled by the `1 ||` because the standard c `%` operator doesn't work for us, but i want to try and create a working smallint version | 14:48 | |
| but i can't seem to get to the function at all without having actually big bigints | 14:49 | ||
| dogbert17 | is it the size of a number which makes a bigint big? | 14:54 | |
|
14:56
brrt joined
|
|||
| dogbert17 | hello brrt | 14:58 | |
| brrt | hi dogbert17 | ||
| dogbert17 | MasterDuke: does commit 8e9761efb3e give any clues? | 15:04 | |
| brrt: are local variable, which are not explicitly initializes, undefined in c? | 15:06 | ||
| *variables | 15:07 | ||
| nine | yes | ||
| dogbert17 | nine: any comment wrt to the stuff I wrote here an hour ago, have I misunderstood what's going on? | ||
|
15:10
zakharyas1 joined
15:12
zakharyas left
15:14
leont left
|
|||
| brrt | dogbert17: yes, undefined | 15:15 | |
| in practice, without optimization, garbage values; | |||
| under influence of optimization pretty unpredictable | |||
| I think some compilers default to setting to zero | 15:16 | ||
| but don't rely on it | |||
| dogbert17 | brrt and nine: thank you | 15:17 | |
| MasterDuke: seems as if MVM_bigint_mod is bypassed if the numbers are small | 15:31 | ||
| MasterDuke | yeah | ||
| but is that always going to be the case? if it's guaranteed never to happen, we can simplify. if it's just some combination of optimizations, codegen, etc that means we haven't been able to trigger it in practice, it has to stay | 15:35 | ||
| i tried stuff like `my Int $a = 2**66 + 5; my Int $b = 2**67 + 3; say ($a - 2**66) % ($b - 2**67)`, but no dice | 15:37 | ||
| i can if i call nqp::mod_I directly, but why isn't it being codegenned? | 15:38 | ||
| moritz | sounds like to be able to know for certain you don't need the bigint variant, you must know the value of the operands. If you know that at compile time, you can just constant-fold it away | 15:44 | |
| MasterDuke | github.com/rakudo/rakudo/blob/mast...#L375-L392 | 15:51 | |
| dogbert17 | mod_i vs mod_I | 15:52 | |
| MasterDuke | that can probably be simplified if i get a working small bigint version. might be faster then without all the extra hll code | 15:53 | |
| brrt | mind that mod_i is not a very fast opcode because the underlying idiv is a slow, slow, slow operation | 15:56 | |
| (presumably because of this, everybody optimizes it away; presumably because of that, intel/amd get away with not optimizing) | |||
| bbiab | 15:57 | ||
|
15:57
brrt left
16:38
codesections joined
17:12
colomon_ joined
17:13
raku-bridge left
17:24
domidumont left
17:42
sena_kun joined
17:44
Altai-man left
18:04
brrt joined
|
|||
| brrt | \o | 18:20 | |
| nwc10 | o/ | ||
| brrt | One of the things that stuck to me when I read the long javascript article that MasterDuke shared some time ago... | 19:19 | |
| Their interpreter is written in assembly (with macros, and 'machine independent', so far as possible) | |||
| luajit has the same thing | |||
| and ... truth be told it's really a good idea | 19:20 | ||
|
19:31
codesections left
19:32
brrt left
19:39
codesections joined
19:40
patrickb joined
20:04
patrickb left
20:12
patrickb joined,
patrickb left
21:38
sena_kun left
21:58
zakharyas1 left
|
|||
| timotimo | have you had any look at jitter? ageinghacker.net/git/cgit.cgi/jitter | 22:24 | |
| it looked like it has a few cool tricks up its sleeve | |||
| there was a presentation about it, i saw it on video, but i'm not sure where i found the link | 22:30 | ||
| ageinghacker.net/talks/jitter-slide...-08-25.pdf or perhaps i have really only seen the slides? | |||
| andhallucinated the video | 22:31 | ||
| moon-child | timotimo: I've heard of it. I hear it's not actually that fast, though. And (iirc) it wouldn't let you do type specialization or anything like that | 22:32 | |
| timotimo | oh,hm | 22:33 | |
| we get a lot of our speed even if jit fails from type specialization | |||
| the developer of gnu poke uses jitter, maybe that'sa good place to ask,if not where-ever jitterusershang out | 22:35 | ||
| MasterDuke | yep. github.com/rakudo/rakudo/blob/mast...#L375-L392 is now just `nqp::if(b, nqp::mod_I(nqp::decont(a),nqp::decont(b),Int),Failure.new(X::Numeric::DivideByZero.new(:using<%>, :numerator(a))))` and `my $a; for ^1_000_000 { $a = $_ % ($_ + 2) }; say now - INIT now; say $a` goes from 0.16s to 0.088s. passes a spectest | 23:12 | |
| timotimo | oh my | 23:16 | |
| that is from switching libtommath for gmp? | |||
| hum.does $_ % ($_ + 2) alwaysresult in $_? maybenot for negatives | 23:17 | ||
| oh, or is thatfrom putting a "no big integer needed" path in there by having it inside the implementation of mod_I? | 23:18 | ||
| could you look at numbers above 2 ** 32? | |||
| because those would be handle-able by mod_i,but will have a realbigint formod_I | |||